Security and isolation

Two questions decide whether a context layer can be bought: can it leak between customers, and can it show somebody something they should not see. This page answers both, and then says what is not yet done — because a security page that only lists strengths is not one.

Isolation between customers is physical

Every customer runs their own container, with its own database file, its own index directory and its own storage prefix.

There is no shared table with a customer column, and no shared index with a customer dimension. The tenant API has no customer-id parameter at all — a request reaches one instance because of the hostname it arrived on and the token it carried.

The failure mode this removes is the common one: a multitenant index where a missing predicate in one query path returns another customer’s rows. That bug cannot be written here, because there is nothing in the index that belongs to anybody else.

Permission filtering is a pre-filter

What a person may see is enforced inside the index query, before ranking. Never as a filter applied to results that already came back.

This matters more than it sounds. Post-filtering leaks by inference: a result count, a gap in a ranked list, or a slower response all carry signal about what was removed. Pre-filtering means a resource a person may not see is indistinguishable, to them, from one that does not exist — which is the property compartmentalised environments actually require.

An agent sees exactly what the person it serves sees. Not a superset, not an administrative view.

No service accounts

Agents are issued tokens bound to a person. There is no service token to hand out and no shared machine identity to act under.

The consequence is that attribution survives automation. Every change in the history names the person responsible, so “who did this” has an answer even when the thing that did it was a program. A system that lets agents act under a shared identity produces an audit log that records the robot — which is not an audit log.

The record cannot be quietly rewritten

Nothing is edited in place. A change appends and produces a new revision, and no revision is removed. That is a storage property, not a policy: there is no update path that overwrites what a resource used to say, so there is no privileged operation to control.

Combined with the proposal loop — members propose, owners decide — it means the corpus your agents read from cannot be altered by an agent, or silently altered by anybody.

Browser and token handling

Your instance’s web app authenticates as an ordinary OAuth client: authorization code with PKCE, dynamic client registration, and refresh-token rotation where reuse of a rotated token kills the chain. Membership is re-checked on every refresh.

One recorded trade-off, stated rather than buried. The refresh token is held in web storage, so script running on your instance’s own origin could read it — meaning an XSS there is an account compromise. It is survivable because of rotation, reuse detection and the membership re-check, and the access token is held in memory only and never stored. What would close it properly is a backend-for-frontend holding the token in an HttpOnly cookie. That is a service the current design does not have, and we would rather write this paragraph than imply the question never came up.

What is not done yet

• Permissions derived from source permissions. Today access is managed in Xerum. Deriving it automatically from what a person can see in GitHub or Jira is the next phase, and finer scopes come with it.
• Custom roles. Owner and member are the roles. Who counts as an owner is enforced at the request boundary, so this is a roadmap item rather than a change to the data model.
• Formal certification. There is no SOC 2 report or equivalent to hand you today. If that is a gate for your organisation, say so early and we will tell you honestly where we are rather than where we intend to be.

Found something? Tell us before you tell anyone else, and we will work the fix with you. The architecture behind all of this is described on the architecture page.