Identity

Identity, authorization, and audit

On Context, people and agents are both principals anchored to your identity provider. Every action an agent proposes is authorized against policy before it runs, credentials are brokered at runtime rather than stored in prompts, and the whole sequence lands in an append-only audit trail.

Identity for people and agents

People sign in to Context through your identity provider — the platform integrates with Okta and Entra ID — so joiners, movers, and leavers are governed where you already govern them. Agents work the same way. Every agent carries its own identity as a first-class principal: no shared service accounts, no standing secrets.

When a run starts, Context binds it to three things: the agent, the requester, and the policy. An agent's permissions derive from the humans and teams it acts for.

The agent: A principal of its own — never a shared service account
The requester: The person or team whose work the run carries out
The policy: Inherited from your IdP — Okta or Entra ID

Context runs in production at Qualcomm inside a full VPC deployment with SSO-scoped permissions.

Per-action authorization

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.

Credential brokering

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.

Minted: Per task, at run time — scoped to the action
Expires: At completion — no standing secrets
Recorded: Grants and denials stay attached to the run

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.

Audit trail

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.

Developer devices: pairing and revocation

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.

Request documentation

The document library covers audit reports, assessments, and procurement paperwork. Request what your review needs; anything that requires an NDA is shared once it is in place.

security@context.ai

Also documented: Deployment models · Data handling · Compliance program