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, with no stricter or looser variant per model.

Authorization on Context is evaluated per action, not per session. A preset decides which actions wait for the requester's yes, from read-only to never asking. A yes lasts once, for the task, or always; an "always" approval expires after 90 days and covers only the exact tool and target it was given for.

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.

Every request resolves its key again, so a revoked key or a removed member is refused on the next call. Credential storage and rotation 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.

Settings > Audit log records each request and decision with its actor, its outcome (Asked, Allowed, Blocked, Granted, Recorded, Expired, or Revoked), and the person the agent acted for. It shows what an agent asked to do and was refused, not only what it did. Filter by event, actor, and date, and export up to 1,000 rows at a time as CSV.

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.