Workload Identity and Attestation
Per-agent-instance identity bound to verifiable runtime claims. Tool and Memory Gateways verify the identity and claims on every privileged request; revocation is instant.
Placement rationale
C01 sits in Layer 1 because it is the foundational identity primitive every other control assumes. The Tool Gateway in C05 needs to know who is calling. The Memory Gateway needs to know whose access rules apply. The audit ledger in C11 needs an immutable subject for each event. The signed-action chain in C12 needs a durable signer. Without C01, those controls run against a phantom: the workload identity in front of them may belong to a long-lived service account, a shared machine credential, or an unattested process. C01 makes the identity short-lived, instance-specific, and bound to verifiable runtime claims so the downstream controls have something real to attest against.
Why
Agents are autonomous callers of privileged functions. If agent identity is shared, long-lived, or unprovable, three things break at once. Attribution fails: you cannot tell which agent instance produced which side effect, which means you cannot reconstruct an incident or assign accountability. Containment fails: revocation does not stop in-flight or future tool calls because the identity being revoked is shared with other workloads or because no path exists to propagate revocation to the enforcement point. Integrity fails: you cannot prove the agent that acted was the approved build, with the approved config, calling the approved toolset. This is "anonymous autonomy," and it is incompatible with any enterprise risk model that requires per-action accountability.
The failure mode happens through several routes. An operator reuses a service account credential across multiple agent instances because the IAM model only supports one identity per workload class. An agent runtime mounts a long-lived API key as an environment variable that survives across deployments. An identity is issued at startup but the gateway only verifies it once, so a post-startup compromise that swaps the agent process is invisible. A model fine-tune ships without an updated ABOM, so the claim hash in the identity no longer matches what the model actually is. In each case the identity exists on paper; what fails is the binding between identity, integrity, and enforcement.
Prompt-based identity claims fail because the model is not a security boundary - the prompt is data the agent can rewrite. Traditional application logging fails because it records the service identity, not the agent instance behind it. RBAC alone fails because role assignment is coarse-grained and does not reflect the moment-to-moment integrity state of the process making the call. C01 reduces risk by replacing all of these with cryptographically verifiable per-instance identity, short-lived enough to limit blast radius and bound tightly enough to versioned artifacts that drift is detectable.
What
A per-agent-instance identity bound to verifiable runtime claims and enforced at every privileged boundary. The identity is the primary key; the claims are the proof of integrity; the verification at the boundary is what makes the binding operational.
- Identity
- Short-lived workload token or X.509 certificate, minted per agent instance. TTL measured in minutes, not days. Issued via OIDC federation or SPIFFE/SPIRE; the issuer is not the agent runtime itself. No static secrets in the agent's environment.
- Claims
- Image digest, config hash, policy bundle hash, toolset hash, tenant, autonomy tier, optional TEE attestation report. Claims are sealed inside the identity token at issuance; the agent cannot modify them. The set of required claims is documented in the ABOM for each agent class.
- Authorization
- Tool and Memory access permitted only when the identity is valid (signature, TTL, issuer) AND the claims match the expected ABOM. A valid identity with unexpected claims is denied. An expected claim profile with an invalid identity is denied. There is no partial-match path.
Invariants the control guarantees:
- Every privileged request reaching the Tool or Memory Gateway carries a valid identity token AND matching claims, or it is denied.
- Identity lifetime is bounded by TTL; no identity can be replayed past expiry.
- Revocation propagates to the gateways within a documented bound (recommended: less than 60 seconds at bounded tier, less than 10 seconds at high_privilege).
- Claim hashes recorded in the identity match the artifacts produced by the signed pipeline (C03) and the ABOM registered for the agent class (C04).
How
Identity issuance
Mint short-lived workload identities via OIDC federation, SPIFFE/SPIRE, or a cloud-native equivalent (AWS IAM Roles Anywhere, Azure Workload Identity, GCP Workload Identity Federation). The issuer runs outside the agent runtime and consumes a verified workload signal (Kubernetes ServiceAccount token, instance attestation document, TEE quote) to mint the identity. No static secrets in the agent's environment. TTL is measured in minutes; the gateway requires renewal.
Attestation at the boundary, not at startup
The Tool Gateway and Memory Gateway verify identity and claims on every privileged request - not only at agent startup. This is the failure that most often turns C01 into a paper control. A common misimplementation checks the identity once when the agent connects, then trusts the connection state; an attacker who compromises the process post-startup retains full access. The verification cost per call is small (signature check plus claim hash compare) and amortises against the latency of the policy decision in C05.
Claim binding via ABOM
The ABOM (managed by C04) contains the expected claim hashes for each agent class: image digest, config hash, prompt bundle hash, policy bundle hash, toolset hash. The gateway extracts the claim set from the incoming identity, looks up the expected ABOM for the agent_class field, and compares hash by hash. Any mismatch denies. The expected set is signed (C03) so the gateway can verify the ABOM has not been tampered with at lookup time.
Revocation that actually halts tool calls
Revocation is not just removing the identity from the issuer's database; it must propagate to the enforcement points fast enough to stop the next side effect. Implement a short-TTL token plus a revocation list (RFC 8959) or a CRL-style deny-list the gateway consults on every request. Test the propagation time as part of the conformance pass: revoke, then attempt a tool call from the revoked identity, measure the time until denial. Document the bound (recommended: under 60s at bounded tier, under 10s at high_privilege).
Safe rollout
Begin in observe-only mode: the gateway accepts the request even on identity mismatch but emits a violation event. Run for 14 days to baseline the false- positive rate (legitimate workloads with stale ABOMs, missing claim fields, unattested processes that should be attested). Promote to enforce per-agent-class as the ABOM coverage hits 100% for that class. Promote to enforce-all only after the violation rate is zero across a 7-day window.
Testing
Two automated tests per gateway:
- Positive. A test agent with a valid identity and matching ABOM claims completes a tool call and produces a verified-identity decision record.
- Negative. A test agent with a valid identity but mutated claims (one hash flipped) is denied at the gateway and produces a denied-by-attestation event.
Both run in CI on every gateway change. Add a revocation propagation test that measures actual time-to-stop and fails if it exceeds the documented tier bound.
Integration with adjacent controls
C01 is consumed by C03 (which signs the claim artifacts), C04 (which manages the ABOM that defines expected claim sets), C05 (which enforces identity and claims on tool calls), C11 (which records the verified identity as the subject of every ledger event), and C12 (which durably signs high-impact actions with a key bound to the identity at the moment of action).
Evidence
- Identity issuance and rotation events. TTL, issuer, subject, full claim set with hashes, requesting workload's attestation signal, time of issuance, time of next rotation. One event per mint and one per rotation.
- Attestation logs at every gateway boundary. Pass / fail for each privileged request with the specific claim that failed on a deny, correlated to the policy decision record in C05.
- Coverage metric. Percentage of privileged tool and memory requests with verified identity AND matching claims. Target 100% at bounded and high_privilege tiers; deviation triggers a P2 alert.
- Revocation propagation time. Per revocation event: time from issuer-side revocation to first denial at the gateway. Tracked as a histogram; the bound is documented per tier (under 60s bounded, under 10s high_privilege).
- Claim freshness diff. Count of identities currently active whose claim hashes do not match the latest ABOM for their agent class. Should be zero outside the active rotation window. Non-zero values surface drift between the deployed runtime and the registered specification.
- Identity reuse detection. Count of identities seen at more than one workload instance during their TTL. Should be zero. Non-zero indicates a shared-credential failure mode and triggers immediate investigation.
Failure modes
- Shared service accounts across agents. Operators reuse a machine credential because the IAM model only supports one identity per workload class. Defeats attribution; one identity now corresponds to many actors. Mitigation: per-instance identity issuance via federation, with the agent_instance_id baked into the subject claim.
- Attestation checked once at startup, not at tool / memory boundaries. A common shortcut: verify on connection, trust the connection state. Allows drift and post-startup compromise to pass undetected. Mitigation: verify identity AND claims on every privileged request; treat the cost as part of the policy decision path.
- Identity not bound to versioned artifacts. Prompt, policy, or toolset can drift without detection because the identity does not record their hashes. Mitigation: the claim set MUST include image digest, config hash, prompt bundle hash, policy bundle hash, and toolset hash, sealed at issuance.
- No revocation path that actually blocks tool calls. Revocation removes the identity from the issuer's database but the gateway never refreshes its trust set. Revocation becomes paper-only; the kill switch fails when invoked. Mitigation: short-TTL tokens plus a revocation list (RFC 8959) or a deny-list the gateway consults per request, with a measured propagation bound tested under conformance.
- Verification decay. Relying on ephemeral certificates for long-term non-repudiation. A signature produced by a 1-hour identity is unverifiable a year later without a trusted timestamping authority or transparency log. Mitigation: pair C01 with C12 signing infrastructure that binds the action signature to a long-lived organisational key chained from the ephemeral identity at sign time.
- Claim freshness gap. ABOM is updated but in-flight identities still carry old claim hashes through their TTL window, so old configurations keep executing. Mitigation: force re-issuance on ABOM change; treat TTL as a maximum, not a contract; emit a freshness diff metric so operators see drift.
NIST AI RMF alignment
C01 maps to GOVERN and MANAGE.
GOVERN: GV-1.4 (roles and responsibilities for AI accountability are clearly defined and documented) - per-instance identity makes accountability operationally enforceable; GV-1.6 (mechanisms exist to inventory and account for AI systems) - C01 is the runtime arm of the inventory; GV-4 (organisational structures support a culture of accountability) - the identity discipline cascades through C03, C04, C11, C12.
MANAGE: MG-2.3 (mechanisms are available and applied to supersede, disengage, or deactivate existing AI systems) - revocation propagation is the technical implementation of this requirement; MG-3.2 (responses to identified AI risks are documented and applied) - the revocation playbook is the response.
ISO/IEC alignment
C01 maps to ISO/IEC 27001 A.5.16 (identity management - per- instance identities, lifecycle, revocation), A.5.18 (access rights - claim-bound authorisation at the gateway), and A.8.2 (privileged access rights - the gateway enforces per-call rather than per-session).
C01 maps to ISO/IEC 42001 A.6.2.2 (AI system inventory - the identity catalogue is the runtime mirror of the registered inventory) and clause 8.1 (operational planning and control - identity verification is a designed operational control, not an after-the-fact check).
Typical evidence: identity issuance and rotation logs, per-request attestation records, revocation events with measured propagation timings, claim-freshness diff against the ABOM, identity-reuse detection metric.