The model never decides what you can see.

Osmos works out who is asking and what they are allowed to read before it answers. An assistant cannot receive knowledge its user isn't entitled to, because that knowledge is never put in front of it.

Enforced today

What Osmos actually does

Everything on this page is implemented and running. Where something is designed but not yet enforced, it is in the next section instead.

Nothing is sent to a third party Your project memory never leaves Osmos to make Osmos work. There is no embedding model, no summarising model, and no outside service involved in finding what's relevant to a task — that happens in the same database your memory already lives in. Nothing here is used to train anything.
Private notes never reach the model A teammate's private notes are not filtered out of an answer after the fact — they are never put in front of the assistant in the first place. Privacy does not depend on a model choosing to keep a secret, which is not something any model can promise.
Verified identity People sign in with Google, GitHub, or an email address and password. Each assistant you connect authorises separately and carries its own identity, so Osmos always knows which person, and which assistant, is asking.
Disconnect one assistant, keep the rest Every assistant you have connected is listed on its own, and any one of them can be cut off without disturbing the others. The next thing a disconnected one tries to read fails.
Sharing is a human action There is nothing an assistant can do to grant anyone access. Every grant is made by a person, in the app, and is recorded. An assistant cannot be talked into widening access it has no way to change.
Re-sharing stays with people A share link can grant view or edit, never manage — and neither can organisation access. Manage carries the right to re-share, and a link or a group membership that could pass that on would propagate access no human chose.
Groups grant nothing by default Creating an organisation, adding people to it, and moving a context into it all grant nothing on their own; access begins only when someone sets that control. An individual invitation outranks it, so removing a person from the group revokes only what the group gave them.
Address ownership is proven Until an address is verified, that account cannot accept an invitation, join by a share link, send an invitation, or create an organisation — otherwise anyone could register someone else's address and quietly collect the contexts shared to it, or use us to send mail in our name. Making a context of your own is not gated, because it hands the maker nothing that was not already theirs. Federated sign-in that cannot prove the address is refused rather than linked.
Where every claim came from Durable knowledge carries what it was based on, who wrote it, which assistant published it, what kind of thing it is, and when. Something an assistant worked out is distinguishable from a decision a person made.
History, and the ability to retract New knowledge can explicitly replace older knowledge. The history is kept, so you can see what the project used to believe and when that changed — and anything wrong can be retracted, after which assistants stop receiving it.
A record of what each assistant saw Every time an assistant picks up project knowledge it is recorded: what it was working on, what it was told, and how much was held back and why. Withheld items are counted, never named. The record belongs to the person whose assistant made the call — not even a context's owner can read someone else's, because it lists their private notes.
Access history Who shared what with whom, every access change, and every archive or restore are kept for as long as the context exists. "When did this become visible to them" is a question asked months later, so the answer is not something retention removes.
Archiving keeps the memory Archiving a context removes it from every listing and stops assistants seeing it immediately, but deletes nothing. Restoring it brings everything back exactly as it was.
Nothing is removed for a billing reason Downgrading, cancelling, or a card that expires never deletes anything. A workspace over the Free limits keeps everything it has and simply cannot add more. See pricing.
Retention

How long things are kept

Retention never touches the product's actual content. It expires the by-products that would otherwise become an asset of their own.

Memory — indefinitely

Shared and private memory is the project brain. It is kept until you retract it or delete the context.

Access history — indefinitely

Small, append-only, and the record you need to answer a question about who could see what, and when.

What AI saw — 90 days

Each record lists what one person's assistant was told, including their own private notes. Long enough to answer "what did it know", short enough not to accumulate a history of everything each assistant ever saw.

Limits

What it does not do yet

Stated plainly, because a product about inspectable knowledge cannot be vague about its own.

You cannot cap one assistant below another

Knowledge marked as a secret is refused outright. But limiting a specific assistant to less than its user can see — "this one never gets anything sensitive" — is designed and not built yet.

No compliance certifications

Osmos holds no SOC 2, ISO 27001, or HIPAA attestation, and this page will not claim otherwise. If your procurement needs one, say so before you depend on us.

Matching is by words, not meaning

Osmos finds what's relevant by matching what you're working on against what the project knows, weighted by kind, importance, and recency. It will miss a memory that means the same thing in different words. That is the price of the paragraph above it: nothing is sent to an outside model to understand it.

No two-factor authentication yet

Signing in with Google or GitHub inherits whatever second factor you have there, which is the stronger option today. An Osmos password on its own is a password on its own.

The two rules underneath

Connecting an assistant is not consent to share everything

Authorising one gives it an identity, not the project's entire contents. What it can read depends on who is using it and what they were given access to, worked out fresh every time it asks.

What Osmos returns is evidence, not orders

Project knowledge is given to an assistant as something to reason over, never as instructions ranking above yours. That is what stops a poisoned memory from becoming a command.

Check it yourself.

Every claim above is visible from inside your own account — who can read a context, what each assistant was shown, and what was held back.

Start free See how it connects