Security and access control

How Agent Stream distinguishes independent identity concerns, and how RBAC, secrets management, and SSRF protection secure the appliance’s own control plane.

Collapsing authentication, identity correlation, upstream credentials, and administrative access into one generic “security” concept makes it hard to trace which credential authorised a request, or who is allowed to change what on the appliance itself. Agent Stream keeps these concerns distinct rather than collapsing them into one. Authenticated principals, caller-match sources, central OAuth identifiers, upstream credentials, and identity hashes establish who a caller is; a separate role ladder, an encrypted secrets store, and SSRF validation govern who can administer the appliance and how it protects itself. Providers and Models →

Authenticated Identity

Authenticated identity is the runtime result of source authentication for one inbound request. It is not a configuration object but a per-request artefact: it carries the authenticated principal (the credential that was successfully verified) plus any auth-specific metadata.

Each surface authenticates its caller using a JWT bearer token, an API key, or mutual TLS (mTLS). See Pipeline and stages → for how source authentication operates in the inbound stage order.

How source authentication finds a caller’s stable identity

The Caller-Match Source is the configured place source authentication looks for a presented credential and derives the Member’s stable identity: a request header, a JWT claim, a body path, an mTLS attribute, or an API-key binding. See Cost and attribution → for how derived identities map to Members and Teams.

How OAuth sign-in identifiers are shared across surfaces

An OAuth Identifier is a reusable, central store of public OAuth 2.0 / OIDC sign-in identifiers (authority, client ID, and scopes, never secrets) for Microsoft Entra, Okta, or generic OIDC issuers. Identifiers are referenced by ID from IDE front-door sign-in, per-member upstream sign-in, and the dashboard sandbox, so the same identifiers are entered once and every Surface follows an edit.

How front-door and upstream identities can differ

Dual-Token is the pattern where the front-door identity (the caller signing in to the IDE Surface) and the upstream identity (the credential the member Surface presents to its provider) are different identities. The client forwards the upstream credential separately in the X-Agent-Stream-Upstream-Authorization header, and the front-door OPA input carries that fact so a policy can require the extra credential for specific models. See IDE Surface →.

How the Identity Hash Pepper keeps identity hashes private

The Identity Hash Pepper is a process-wide secret used to HMAC-SHA256 caller, member, and delegation correlation hashes, so a hash cannot be reversed or correlated without it. It is loaded at process startup and must be kept secret; rotating it deliberately changes future identity hashes.

What a Signed Governance Record proves about an interaction

A Signed Governance Record is an optional, tamper-evident transcript of one interaction (prompt, completion, per-stage verdicts, identity, metrics, trace ID), signed by the appliance and chained to the prior record for the same Surface via a content hash. Records can be exported through any integration channel and verified against the appliance’s DID document. See Governance records →.

How RBAC, secrets, and SSRF protection guard the control plane

Administering the appliance itself is governed separately from caller identity resolution:

  • Role-based access control (RBAC) governs appliance management through the dashboard using an ordered role ladder (administrator, poweruser, user).
  • Secrets management resolves provider API keys and credentials from an encrypted secrets store by ID, so raw credentials are never embedded directly in Surface configuration.
  • SSRF protection validates operator-supplied endpoints against cloud-metadata addresses and unsafe internal targets.
The account role dropdown, open to show User, Power User, and Administrator