NIST AI agent identity Pillars 2 and 3: authorization and audit at the request layer

The NIST AI agent identity and authorization framework organizes the problem around three pillars. Pillar 1 is identification: every AI request must carry a resolvable identity at the boundary. Pillar 2 is authorization: the resolved identity must be evaluated against a policy that governs what it can do, with what data, under what context. Pillar 3 is audit and accountability: the request, the decision, and the outcome must produce a record that survives independent review. The public comment window closed April 2, 2026. The framework is moving toward published guidance. Federal contractors and critical infrastructure operators will be measured against it.

Pillar 1 is the entry point that most discussions cover. Identity at the boundary is the foundation. Pillars 2 and 3 are where the architecture either holds up or collapses. I want to walk through what they require, where the gap is, and the shape of the implementation that satisfies them.

Pillar 2: authorization tied to identity

Pillar 2's requirement reads as obvious at the policy level. The resolved identity (user, agent, service account) must be evaluated against an authorization policy. The policy decides what the identity can do.

The implementation is where it gets specific. Three properties separate a real Pillar 2 implementation from a check-box one.

Identity-bound policy, not role-bound. Many enterprise systems evaluate policy against a role assigned to the identity (e.g., "underwriter"). The role is a coarse-grained shortcut. Pillar 2 expects the policy to be evaluated against the identity itself with context attributes: the identity's organizational unit, the data classification of the request, the destination model, the time of day, the device posture. Role-based access control alone fails to satisfy Pillar 2 because the role abstracts away the context the policy needs.

Decision context includes the request payload. Authorization is not just "is this identity allowed to call this model." Authorization is "is this identity allowed to send this content to this model under this policy version." The policy needs to see the data classification of the prompt before it can decide. A decision made without seeing the payload is not a Pillar 2 decision; it is a Pillar 0 access list.

Tool-use authorization for agents. Agents that call tools (CRM updates, refund APIs, database writes) need authorization on each tool call separately. The OWASP Top 10 for Agentic Applications 2026 calls the agentic-skills layer a distinct vulnerable component. Pillar 2 expects authorization on every tool call, not just on the initial agent invocation.

Where Pillar 2 breaks in current deployments

Three failure modes are common.

The first is application-layer authorization. The application checks "did this user log in" and then makes the model call with a service credential. The model call has no identity context. The audit record cannot show what the resolved identity was at the model boundary because the resolution never happened there.

The second is over-broad service accounts. The application's service account has permission to call any model with any data. The policy lives in the application. The application is the system that the policy is supposed to govern. The system under audit cannot be its own enforcement layer.

The third is missing tool-call authorization. The agent has permission to call the LLM. The LLM decides to call the refund tool. The refund tool authorizes the agent's service account. No policy evaluation happens between the LLM's decision and the tool call. Pillar 2 fails at the agentic-skills boundary.

Pillar 3: audit and accountability across the lifecycle

Pillar 3's requirement is the artifact that survives independent review. The audit record has to identify the principal, the request, the policy state, the decision, and the outcome. The record has to be tamper-evident. The record has to be retained for the regulatory period that applies to the deployment.

Three properties separate a Pillar 3 record from an operational log.

Per-decision granularity. One record per AI decision, not one record per user session. The session is a useful aggregation. The audit unit is the decision.

Append-only and signed. The record must be immutable from the perspective of the system that wrote it. A log file in an S3 bucket the application can write to is mutable from the application's perspective. The system under audit cannot also be the writer of the audit record without an architectural guarantee that the application cannot rewrite history.

Independent retention. The record's retention is independent of the application's lifecycle. If the application is decommissioned, the record persists. If the model provider is changed, the record persists. If the deployer is acquired, the record persists for the regulatory period.

Where Pillar 3 breaks

Three common failure modes.

The first is the application-controlled log. The application writes the audit record. The application controls the log. Selective logging, suppression, loss-on-crash, and the failure modes I walked through in detail at singhspeak all collapse Pillar 3.

The second is the vendor-side log. The model provider logs the call from the vendor's perspective. The deployer's principal, the deployer's data classification, the deployer's policy state are not on the vendor's record. The vendor's log is corroborating, not authoritative.

The third is the session-level aggregation. The product analytics records "user X had a 20-minute session, called the model 47 times." The aggregate fails Pillar 3 because the per-decision granularity is gone.

The architecture that satisfies Pillars 2 and 3

The implementation that satisfies both pillars at the same time is the policy gateway at the AI request boundary.

The gateway resolves identity at the boundary (Pillar 1). The gateway evaluates the authorization policy against the resolved identity, the request payload, the destination model, and the policy version (Pillar 2). The gateway writes the per-decision record to an append-only signed store before returning the response to the application (Pillar 3). The application never controls the audit record because the gateway writes it.

For agentic workflows, the gateway sits on the tool-call boundary too. Every tool call the agent makes is a separately authorized and audited decision. The agentic-skills layer the OWASP framework identifies becomes a first-class enforcement and audit surface.

End-to-end overhead for this pattern measures under 50ms in production tests. The latency budget is well inside the 500ms-to-5-second LLM inference baseline. The gateway is operationally viable.

How this maps to other frameworks

Pillars 2 and 3 are not unique to NIST. The same structural requirements show up in:

• EU AI Act Article 12 + 19: automatic recording of events across the lifetime of the system, including identification of natural persons. Article 26 places the obligation on the deployer.
• HIPAA: covered entity must produce records of who accessed PHI in what context with what authorization.
• DORA: ICT third-party register and audit trail requirements for AI vendors.
• Fannie Mae LL-2026-04: per-decision record of AI-influenced loan decisions.

An architecture that satisfies NIST Pillars 2 and 3 satisfies the request-layer obligations of all four. The mapping is structural, not coincidental.

DeepInspect

DeepInspect is the policy gateway at the AI request boundary. Identity resolves at the gateway. Policy evaluates at the gateway with full request context. The per-decision audit record writes to an append-only signed store. End-to-end overhead measures under 50ms in production tests.

For a federal contractor or critical infrastructure operator preparing for NIST guidance becoming the measurement standard, DeepInspect is the architecture Pillars 2 and 3 expect.

If you are mapping your AI deployment against the NIST framework and want a concrete walk-through of the gateway pattern, let's talk today.