Security and governance

Tokens

Access is a bearer token, issued per organization from the portal. AiAx shows the plaintext once at creation and stores only a hash of it, so a copy of our database does not yield a working token. A token can be revoked instantly and can carry an expiry.

• One token belongs to exactly one organization. No token spans two.
• Revocation and expiry are enforced at lookup, not filtered out afterwards.
• A token looks like brain_xxxxxxxxxxxxxxxxxxxxxxxx. Treat it as a password: put it in secure storage, never in a repository.
• The endpoint applies per address rate limiting before it even looks a token up, so probing costs an attacker more than it costs us.

Viewer tiers decide what is visible

Each token carries a viewer tier. The tier decides which knowledge the token may see, on every read, and matches above it are never returned. A search that reaches knowledge above the tier reports only how many matches were hidden.

Nodes are classified with one of these access levels: public, department, project, manager, hr, executive, restricted. A relation is visible only when both of the nodes it joins are visible, so the shape of the graph cannot leak what its contents hide.

Scopes decide what may be called

A token also carries scopes, independently of its tier. Scopes decide which classes of tools the token may call, and they fail closed: a stored capability that does not parse cleanly is refused outright rather than falling back to a default.

brain:read

Required by every reading tool. Present on every token, because a token that can read nothing is not useful.

brain:propose

Required in addition by every knowledge proposal tool. Granted explicitly, never by default. Without it, a proposal call is refused and registers nothing.

outreach:propose

Required by propose_draft_email, and by nothing else. Granted on top of the proposal scope and never by it, so a token that may propose knowledge cannot propose customer facing email unless it was given this scope as well. It permits proposing an email draft for a manager to approve. It never sends, and it never reads mail.

Reading tools are annotated as read-only in the protocol itself, so a well behaved client knows before it calls that they cannot change anything. They never write to the knowledge graph.

Forbidden: this token is missing the required brain:propose scope. The proposal was NOT registered.

The approval inbox

Nothing external writes to the graph. A proposal from an agent becomes an inbox item in the portal, carrying its kind, its title, its body and the node ids it concerns. A manager reads it and decides.

• The decision binds to the stored proposal. A tampered client cannot smuggle different content past the approval.
• Proposal content is validated on arrival like any other untrusted payload.
• Write volume is rate limited per token and per organization. A refusal states plainly that nothing was registered.
• Approving is what re-derives the graph. Until then, the brain is unchanged.

Write rate limit reached for this token or organization. The proposal was NOT registered. Try again later.

Freshness lifecycle

Knowledge decays. Every verified source records when a person last confirmed it and how long that confirmation is good for. Once the review window passes, the source is stale, and the system says so rather than quietly serving old answers.

1. A person verifies a source. That records a verification time and starts a review window.
2. When the window elapses, the source reports as stale everywhere it appears, including in the gap list agents read.
3. A review proposal is raised into the approval inbox, asking a person to confirm the knowledge again.
4. Approving it records a fresh verification time and restarts the window.

Rejecting a review snoozes it, it does not silence it. The source keeps reporting as stale for the whole snooze, so the interface never hides the truth. Only the reminder rests, and it comes back when the snooze ends.

Erasure

Deletion has to reach derived copies, or it is not deletion. Two guarantees matter to a customer.

Disconnecting a source

Stored credentials for that source are deleted immediately. Harvesting stops at once, and reconnecting requires a fresh authorization.

Removing a person

Removing a person from the organization chart, or changing the fields that shape the graph, erases that organization's derived artifacts in the same database transaction: the search embeddings, the cached summaries and the complete history of compiled skill packs. No derived copy of the person survives the change, including their name inside a retained skill pack revision.

Derived stores rebuild from the live graph on the next authorized read, so erasure costs freshness rather than availability. A formal erasure request also runs the documented privacy process across both of our databases: a preview of the exact scope before anything changes, and a verification pass afterwards that proves the identifiers return zero from every erased store.

Credentials for connected sources are held encrypted. Audit records retain identifiers, hashes, states and counts, never message bodies or knowledge content.