Agent Identity Is the New Trust Boundary

Enterprise agents are crossing a line that old service-account patterns were not designed to hold.

They do not just call one API. They discover tools through MCP, delegate work through A2A, act on behalf of users, produce decisions, write memory, and sometimes trigger irreversible side effects. The identity question has moved from “which application connected?” to “which autonomous actor crossed this boundary with authority?”

If all of that traffic hides behind one app registration, one generic service account, or one user token passed down the chain, the audit question becomes impossible:

Which agent, under which authority, with which scope, caused this effect?

That question is the real agent-identity problem.

The answer is not one new identifier. It is a runtime contract that binds a named agent, an attested workload, a delegation chain, a short-lived scoped claim, a resource audience, and an audit trail.

That contract is the new trust boundary. The model may reason about the task, but identity decides whether the task is allowed to touch the world.

The standards landscape is converging, but not finished

The useful pattern across current standards is clear: keep authentication at deterministic boundaries, bind tokens to the intended resource, avoid long-lived credentials in agent code, and make the acting principal visible in audit.

NIST’s 2026 NCCoE concept paper on software and AI agent identity frames this as an adoption blocker for agentic systems: agents need identification and authorization controls because they receive access to diverse tools, applications, and data. The OpenID Foundation’s agentic identity work makes the same split: existing OAuth patterns work best inside a single trust domain, but cross-domain, asynchronous, multi-user agent workflows need clearer delegation and workload identity semantics.

The practical conclusion is not “wait for one standard.” It is “compose the stable pieces now, and keep the boundary explicit.”

This is why ContextOS should not treat MCP, A2A, OAuth, SPIFFE, or Entra Agent ID as “the” identity layer. Each solves a slice. ContextOS needs the runtime contract that joins those slices at execution time.

What breaks when identity is too coarse

The failure mode is not just “the wrong user got access.” Agent systems create new ways for authority to blur.

The common pattern is authority crossing a boundary without being re-bound. Fix that, and most “agent identity” bugs become ordinary authorization denials.

The five-part agent identity contract

A strong agent identity model answers five questions.

The important separation is this:

• Agent subject names the behavior contract.
• Workload identity proves the running process.
• Delegated user identity proves human authority.
• Run claim binds those facts to one bounded execution.
• Audit metadata lets an operator reconstruct the chain without seeing raw secrets.

In other words, “agent identity” is a tuple:

(agent_subject, workload_identity, delegated_principal, tenant, run_id, scopes, audience, expiry)

If any part is missing, the system can still authenticate something. It cannot safely authorize the action.

The boundary rule

Every external effect should cross the same boundary shape:

proposal + identity claim + workload proof + policy + resource audience -> scoped execution credential

The model provides the proposal. The runtime provides the identity facts. The Policy Engine decides. The Tool Gateway mints a credential only after the claim, workload, delegation, tenant, resource audience, manifest ceiling, and approval mode agree.

This is why token passthrough is a category error for agents. A token minted for the client, user, or upstream API is not automatically valid for a tool gateway, MCP server, A2A peer, or downstream service. Audience separation is what prevents one accepted credential from becoming a universal bearer secret.

The minimum viable run claim

The run claim should be small enough to attach everywhere and precise enough to deny unsafe work.

{
  "version": "ctxid/1",
  "iss": "contextos:identity",
  "sub": "agent:contextos/support-refund@1.2.0",
  "aud": "contextos:runtime",
  "run_id": "run_a1b2c3d4e5f60718",
  "session_id": "sess_42f1",
  "tenant_id": "tenant_acme_prod",
  "principal_chain": [
    { "kind": "user", "id": "usr_771", "tenant_id": "tenant_acme_prod" }
  ],
  "scopes": ["tools:read", "tools:write", "a2a:send"],
  "nbf": "2026-05-17T10:00:00Z",
  "exp": "2026-05-17T10:05:00Z",
  "kid": "kid_ctxos_support_2026_05",
  "claim_hash": "sha256:...",
  "sig": "..."
}

The runtime should reject the claim if:

• it is expired or not yet valid;
• the signature cannot be verified against the current or trusted historical key;
• the tenant does not match the RunContext;
• the audience does not match the boundary being crossed;
• the subject is revoked or deprecated beyond its migration window;
• a requested tool scope is outside the manifest ceiling;
• a child claim is broader than its parent claim.

This is boring by design. Identity should be deterministic enough to test.

The claim should not contain raw bearer tokens or long-lived secrets. Operators should see claim hashes, key ids, scopes, subjects, and principal-chain summaries. The Gateway can resolve vault references and exchange credentials; the model and trace viewer should not receive the secret material.

The ctxid/1 claim is not the downstream access token. Treat it as the ContextOS authorization assertion that the Gateway can verify before using OAuth 2.0 Token Exchange, STS, or an equivalent broker to mint a token for one audience and one reduced scope set. That keeps replay and audit facts stable while letting each deployment use Keycloak, Entra, cloud workload federation, or another issuer for the actual execution credential.

A2A changes the failure mode

MCP makes a tool boundary explicit. A2A makes a delegation boundary explicit.

That second boundary is where teams often leak authority. A parent agent calls a specialist agent. The specialist gets the original prompt and maybe the user’s token. It does useful work. Then nobody can answer whether the specialist was independently authorized to act.

The safer ContextOS rule is:

A child agent receives a fresh, narrower claim. It never inherits the parent’s bearer token.

The child claim should preserve the original principal chain and narrow the scope set. The A2A envelope and downstream DecisionRecord should record the parent claim hash, child claim hash, correlation id, and parent decision id. The receiving agent can reason over provenance, but it still has to earn execution authority at its own boundary.

For long-running A2A tasks, identity has to survive time as well as network hops. A task id is not authority. Resuming, polling, cancelling, subscribing, or pushing a notification for a task should re-check the caller’s authorization boundary and should fail if the relevant claim expired, the agent was revoked, or the task no longer belongs to the caller’s tenant scope.

The Tool Gateway should evaluate identity before policy

Policy cannot produce a meaningful allow/deny verdict if the identity facts are ambiguous. The Tool Gateway should run identity checks before executing JsonLogic, OPA, Cedar, or any other policy backend.

Minimum order:

1. Parse and validate the RunContext.
2. Verify the agent identity claim.
3. Resolve the agent manifest and lifecycle.
4. Check tenant match and principal-chain shape.
5. Intersect requested scopes with delegated-user scopes, manifest ceiling, adapter permissions, and approval-mode constraints.
6. Evaluate policy.
7. Mint the per-call execution credential.
8. Execute with idempotency and record the receipt.

This keeps “the model asked” separate from “the platform allowed.”

The same order applies to read-only work. Read-only does not mean identity-free. It only means the effective approval mode can skip a human gate. The Gateway should still know the agent subject, workload identity, tenant, user delegation if present, scopes, and trace id before returning data.

The lifecycle is part of authorization

An agent registry is not just inventory. It is the identity control plane.

Every agent registration needs:

• Subject: stable agent:contextos/<slug>@<version> used in claims and audit.
• Manifest: tool surface, prompt pack, model/runtime profile, policy ceiling, and approval-mode ceiling.
• Owner: team, sponsor, created-by, security reviewer, and escalation contact.
• Lifecycle: active, deprecated, or revoked, with migration and replay windows.
• Signing keys: active key id, previous trusted keys, deprecation windows, and revocation events.
• Workload bindings: allowed SPIFFE IDs, cloud workload identities, runtime profiles, and environment constraints.

If the platform auto-provisions agents or tools, onboarding still has to be policy-gated. The registry should admit only workload identities whose SPIFFE ID, mTLS identity, or cloud federation binding matches the manifest, and token-exchange permissions should come from that admitted binding rather than from a static client secret.

The important part is enforcement: a revoked agent should disappear from discovery, fail claim minting, fail A2A dispatch, fail Gateway execution, and remain replayable only as a historical subject.

A build sequence that works

Teams usually try to solve agent identity from the top down with an enterprise-wide naming taxonomy. That takes too long. A safer implementation sequence is:

1. Register every high-authority agent with a versioned subject and owner.
2. Split workload identity from user delegation in RunContext.
3. Add signed short-lived run claims with claim_hash in every trace.
4. Move credential exchange to the Tool Gateway and forbid token passthrough.
5. Require child claims for A2A instead of forwarding parent credentials.
6. Bind async task state to run_id, claim hash, tenant, and trace.
7. Add lifecycle enforcement: deprecated and revoked agents fail closed.
8. Add replay verification against historical keys and manifests.

This gives you useful control before the full federation story is mature.

A practical scorecard

Use this scorecard before letting an agent perform delegated, network, or destructive work.

If any row is missing, the system may still be useful for read-only work. It is not ready for high-authority automation.

Design review questions

Before a new agent crosses production boundaries, ask these out loud:

What ContextOS adds

ContextOS treats agent identity as a cross-plane primitive:

• Intelligence plane resolves business entities with CEIDs and keeps agent subjects distinct from source IDs.
• Context plane compiles only tools and evidence the current identity may see.
• Decision plane carries RunContext, principal chain, and signed claim through Planner / Executor / Critic.
• Action plane validates every toolCall at the Tool Gateway and mints per-call credentials.
• Trust plane owns lifecycle, scopes, revocation, rotation, policy decisions, replay, and audit.

That is the difference between identity as a login and identity as a runtime control.

Research base

• ContextOS spec: Identity Layer, Security and Compliance, Adapter Mesh, and API Contracts.
• NIST NCCoE concept paper on software and AI agent identity and authorization for the emerging public-sector framing.
• OpenID Foundation: Identity Management for Agentic AI for OAuth, delegation, and agentic identity design questions.
• MCP Authorization and MCP Security Best Practices for OAuth resource binding and token-passthrough risk.
• A2A Protocol specification for agent discovery, task operations, authentication schemes, and per-operation authorization responsibilities.
• SPIFFE/SPIRE concepts for workload attestation and runtime-issued workload identity.
• Kagenti: Identity in Agentic Platforms for a concrete Keycloak + OAuth Token Exchange + SPIRE implementation walkthrough.
• OWASP Top 10 for LLM Applications for excessive agency, prompt injection, and tool-risk vocabulary.

What to read next

• The Identity Layer: Agents Need Two Identities, Not One
• Security and Compliance
• API Contracts
• Agent2Agent and MCP in ContextOS