Why does Pillar 1 live in the application instead of in the enforcement layer?

The identity system is the source of truth for identity, and the application is the system that originates each request. The enforcement layer evaluates what the application supplies. It cannot synthesize identity that the application omitted. NIST's architectural division reflects this: the application owns identity provisioning and propagation; the enforcement layer owns policy and audit.

Can we satisfy Pillar 1 with our existing IAM system?

Yes. Workload identity in AWS IAM, GCP service accounts, Azure managed identities, and Kubernetes OIDC federation all provide the underlying mechanism. The work is in provisioning a per-agent identity, integrating it with the deployer's identity provider for delegation, and propagating the identity object with every model request. The IAM system is the source; the application's request middleware is the pipe.

What is the difference between agent identity and the agent's API key?

The API key identifies the application as a tenant of the model provider. It says "this app is allowed to call OpenAI's API." Agent identity identifies the agent as an actor within the deployer's environment. It says "this is the agent acting on behalf of this user, with this delegated authority, under this policy." The API key is a billing and tenancy primitive. Agent identity is an authorization primitive.

How do we rotate agent identities without breaking running agents?

Standard credential rotation patterns apply. Issue a new workload identity, propagate it to the agent's runtime, run the old and new identities in parallel during the rotation window, and revoke the old identity once propagation completes. Short-lived delegation tokens make the rotation simpler because the token's natural expiry handles most of the rotation. Long-lived agent processes that hold credentials in memory benefit from token-based credentials over key-based credentials.

Does Pillar 1 apply to single-agent deployments or only to multi-agent crews?

Pillar 1 applies to every agent deployment. A single agent still requires a distinct identity from the authorizing user. The combination of agent identity plus user identity is what supports per-decision policy evaluation and action lineage. Multi-agent crews add the requirement of distinct identities per crew member, but the foundational requirement is the same.

AI Agent Identity: NIST Pillar 1 in Production Deployments

NIST's AI agent identity and authorization framework, with the comment window closed April 2, 2026, codifies three pillars. Pillar 1, agent identity, is the foundation: every AI request carries verified identity context for both the natural person on whose behalf the agent acts and the agent's own identity scoped to its delegated authority. The framing matters because Pillars 2 and 3 cannot be satisfied without it. I want to walk through what Pillar 1 actually requires at the request layer and where production deployments fall short.

The most common failure is the static service credential. The credential identifies the application, not the human or agent acting through it. Authorization at the AI call layer reduces to "does this app have the API key," which is the wrong question for a system that issues thousands of prompts per minute at machine speed.

What Pillar 1 requires

Verified identity for the natural person

Every agent action originates from a human who authorized the agent to act. The identity of that human travels with the request. Verified means the identity is bound to the deployer's identity system, not asserted by the agent process and not inferred from a session cookie. OAuth tokens, SAML assertions, OIDC claims are all acceptable mechanisms. The proof is in the binding to a known identity provider.

Distinct identity for the agent itself

The agent has its own identifier separate from the authorizing user. The agent identifier is provisioned by the deployer's identity system, scoped to the delegated authority granted by the authorizing user, and rotated on the same cadence as user credentials. Per-agent identifiers support per-agent policies, which is what NIST Pillar 2 requires for delegated authority.

Structured propagation

The identity object travels with every model API call. The structure includes the authorizing user identifier, the agent identifier, the role the agent holds, the delegation scope, the policy context the application supplies, and a timestamp. The enforcement layer reads the object and applies policy against it. The object is not a free-form blob; it conforms to a schema the proxy can validate.

Where production deployments fall short

Static service credentials

Most early agent deployments use a static API key issued to the application. The key grants permanent access to the full model API for any caller, any prompt, and any data context. The credential identifies the application as a tenant of the model provider, not the agent as an actor within the deployer's environment.

The problem is structural: a single credential cannot carry two identities (the authorizing user and the agent). Pillar 1 requires both. A static credential collapses both to a single role and undermines the per-role policy evaluation in Pillar 2 and the action lineage in Pillar 3.

Inferred identity from session metadata

A second failure mode is to infer the user identity from a session cookie or a heuristic at runtime. The agent process reads the user identifier from the application's session store and includes it in the prompt or in a custom header. The inferred identity is not verified by an identity provider. Auditors reject this approach because the identity assertion is generated by the system under audit.

Shared agent identifiers across deployments

A third failure mode is to use a single agent identifier for an entire crew of agents. The planner, the executor, and the critic all share the same role from the policy decision point's perspective. Per-role policies collapse to a single policy. Action lineage records show a single agent acting, even though several agents contributed to the workflow.

Production patterns that satisfy Pillar 1

Workload identity for the agent process

The agent runs as a workload with its own identity in the deployer's identity system. AWS IAM roles, GCP service accounts, Azure managed identities, Kubernetes service accounts with OIDC federation are all production-grade mechanisms. The workload identity is the agent's identifier in Pillar 1 terms.

Delegation tokens from the authorizing user

The authorizing user issues a delegation token bound to the agent's workload identity. The token specifies what the agent may do on the user's behalf and for how long. OAuth 2.0 token exchange (RFC 8693) and macaroons are working patterns. The delegation token is what carries the authorizing user's identity with each request.

Structured request headers

The model API call carries the identity object in a structured header. The header includes the workload identity, the delegation token, the role identifier, and the policy context. The proxy validates the header against the identity provider's public keys, the token issuer's signature, and the policy decision point's expected schema. Validation fails closed: a malformed header rejects the request.

Rotation and revocation

Workload identities rotate on the deployer's standard credential rotation schedule. Delegation tokens have short lifetimes (minutes to hours). Revocation propagates within the rotation window. A compromised agent identity is invalidated by the identity system the same way a compromised user credential is.

Why Pillar 1 has to live in the application

NIST's framework deliberately locates Pillar 1 in the application architecture, not at the enforcement layer. The reason is structural: the identity system is the source of truth for identity, and the application is the system that originates each request. The enforcement layer evaluates what the application supplies. It does not synthesize identity context the application omitted.

This architectural division has practical consequences. The application team owns Pillar 1 work: provisioning workload identities, integrating with the identity provider, propagating delegation tokens. The security team owns Pillar 2 and 3 work: configuring per-route and per-role policies, validating the audit record set, and producing evidence for regulatory review.

The two teams have to agree on the identity object schema. The proxy expects a specific format. The application has to emit that format. Misalignment is the most common source of integration friction in early deployments, and the most common fix is to formalize the schema in a shared document before the first agent ships.

Compliance lens

EU AI Act Article 19 requires that automatically generated logs for high-risk AI systems include the identification of natural persons involved in result verification. For agentic deployments, that identification has to bind back to the authorizing user, not just to a service credential. Pillar 1 produces the identity context that satisfies Article 19's natural-person identification requirement.

Fannie Mae LL-2026-04, effective August 6, 2026, requires disclosure on demand of AI tools, providers, and safeguards. Identifying which natural person authorized which AI-assisted decision is part of that disclosure. The framework is silent on the architectural mechanism; the deployer chooses the implementation. Workload identity plus delegation tokens is the production pattern.

NIST AI RMF and ISO 42001 reach the same conclusion through different language. Verified identity for AI actors is the foundation. The vocabulary differs across the frameworks; the architectural requirement does not.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits at the AI request boundary as an external enforcement layer. The proxy reads the identity object the application supplies, validates the signature against the identity provider, and applies per-route and per-role policies. The per-decision audit record captures the identity object verbatim, which is what NIST Pillar 3 action lineage requires.

The proxy is model-agnostic and identity-system-agnostic. Workload identities from AWS IAM, GCP service accounts, Azure managed identities, and Kubernetes OIDC all flow through the same proxy. Delegation tokens from OAuth 2.0 token exchange, macaroons, or custom schemes all validate against the identity provider's public keys.

If you are building an agent deployment and want to ship Pillar 2 and Pillar 3 on top of the Pillar 1 work your application team is doing, that is the integration point.