Identity, authorization, and audit

Isolation between tenants is enforced where the data is read, not after. Your organization is a predicate bound into the query itself, so a row from another tenant is never fetched and then filtered away — it is never a candidate result in the first place. The distinction matters: a post-filter is one forgotten clause away from leaking; an in-query predicate has to be defeated at the source to fail.

Membership resolves the same way for projects and channels: through one group closure rather than a patchwork of per-surface checks. Access to a project and access to a channel are answered by the same resolution, so there is a single place to reason about who can see what.

Workspaces are public, private, or personal, and the visibility is the boundary: an administrator role confers nothing inside a personal workspace. Admin is not a skeleton key. All of this is identical across the four deployment topologies — managed, your VPC, on-premises, and air-gapped run the same isolation, not a stricter or looser variant per model.

Authorization on Context is evaluated per action, not per session. Before a credential is issued for any tool call, policy checks the resource, the action, the purpose, and the approval state. The rules are declarative and evaluated on every call — deny by default, approve by exception — rather than reviewed after the fact in a log.

Read access, write access, and human approval are configured separately. A workflow can read broadly and still require a named person to approve every change it proposes; the approval step is part of the authorization state.

Each decision runs in one order: deny, then allow, then refuse. The default is denial; an explicit rule allows; and a refusal can still override an allow. The specific resource is bound into the decision, not just its type — the check is "may this principal take this action on this object", never "may this principal act on objects like this".

The bug class we actively hunt is the confused deputy: every check passes, and the wrong tenant's object comes back anyway. Binding the resource into the decision is what closes it, because the object itself is part of what was authorized. And the same code path runs whether or not a control is shared — a shared resource is not a second, looser branch to get wrong, it is the same decision with a different membership answer.

Agents do not hold credentials. A runbook never contains a password, an API key, or a token; credentials are brokered to the connector at runtime, used for the action, and never written into the prompt. Depending on the target system and your deployment, the connector uses delegated user identity or a scoped service identity.

Credential storage, rotation, and revocation are reviewed as part of the deployment design.

Context narrows and brokers access; the destination system remains the final enforcement point. Your database's permissions still apply to every query an agent makes.

Every run produces a record of the task, the model and tool calls it made, the sources it referenced, the actions it took, the approvals it received, and the result. A reviewer can inspect the sequence and compare the output with the rubric it was scored against.

The trail is append-only, and it includes the authorization layer itself: every grant and every denial is logged with the identity, the task, and the rule that decided it. The record shows not only what an agent did but what it asked to do and was refused.

Export and retention requirements differ by regulator and by customer, so both are configured for your deployment.

The same identity discipline extends to the terminal. When a developer runs context-code, login prints a pairing code and an approval link; approving it in the workspace provisions the CLI's agent and mints a key named after the device. Nothing is pasted into the terminal.

Each device holds its own named key, and each key can be revoked on its own — a lost laptop is a single revocation.