Security and privacy
What is private by default, what a token can do, and what publishing actually means.
Contextaco holds working entities, which are often the most sensitive thing a team writes down — the decisions, the constraints, the things that did not work. This page states plainly what is protected and what is not.
Private by default
Everything you create is private. Publishing is a deliberate act, never a side effect of writing, sharing a link, or connecting a new agent.
A private taco returns not found to anyone else — not forbidden. Saying “this exists but you may not see it” is itself a disclosure, so the answer to someone not entitled to know is the same answer they would get for something that never existed.
What a published taco means
Anyone can read it and fork it, with no account. Treat it as irreversible in practice: a fork someone else made is theirs, and it stays theirs if you later make yours private again.
Connecting: two paths, and one is better
Your client registers itself, sends you through a sign-in, and you approve the connection once. Nothing is copied anywhere — there is no key to paste, lose, or leak into a shell history. Use this whenever the client supports it.
For CI, a headless machine, or a client with no connector support. A token is shown once, when created; if you lose it, revoke it and make another. There is no way to read it back, which is the property that makes revoking it meaningful.
What a token can and cannot do
A token acts as you. Be deliberate about which agent gets one.
| It can | It cannot |
|---|---|
| Read everything you own, including private work | Create or revoke credentials — that happens on the web only |
| Write, edit and delete entities | Delete a taco. It can only hand you a link; you finish it in the browser |
| Attach and delete files | Set or change your handle, which is chosen once, by you |
| Fork, and change a taco’s visibility — including making a private one public | Read anything you cannot read yourself |
| Act after you revoke it |
One token per agent. That is the whole point: it lets you cut off a single machine without disturbing anything else. A shared token turns every revocation into an outage.
History, deletion and what survives
- Removing an entity takes it out of the current state and keeps its history. Every version a checkpoint recorded stays readable, so the record of how the work developed is not rewritten by someone tidying up. An entity that was never checkpointed has no history to keep and goes entirely. What makes the record trustworthy is that removal is explicit, per-entity and yours — and that it cannot quietly erase what was already recorded.
- Files do not follow that rule, and the difference is what you should plan around. A file has no history to keep, so deleting one always gives back its bytes. Removing an entity takes its files with it and returns their bytes too — that is where the space actually comes from, since the entity’s own writing stays in its checkpoints. What frees nothing is shortening an entity: the longer version stays in the checkpoint that recorded it. If your storage is tight, files are where to look first.
- A whole taco can only be deleted by you, in the browser. It is the one action an agent cannot take — deleting a taco removes its entities, its files, its types and all of their checkpointed history at once, and there is no undo. An agent asked to clean up hands you a link to the taco’s page; you confirm there by typing its name.
- Deleting a file that an entity still shows is refused, and the refusal names the entities, so you are never one command away from leaving a body pointing at nothing.
Where the data lives
Contextaco stores and serves. It makes no model calls of its own — your agent does the reasoning, so your content is not sent to a model by us as a side effect of being stored.
Full detail, including the operating entity and how to reach us: