AI Agent Security: From Identity to Action Lineage

NIST's AI agent identity and authorization framework, with the comment window closed April 2, 2026, codifies three pillars: agent identity (Pillar 1), delegated authority (Pillar 2), and action lineage (Pillar 3). Pillar 1 is an application architecture concern. Pillars 2 and 3 require an enforcement layer that operates at the AI API call layer, separate from the model.

I want to walk through what each pillar requires at the request level, where the existing security stack is unable to satisfy the requirement, and what an enforcement architecture has to do to produce evidence that survives a regulatory review.

The Mandiant M-Trends 2026 report measured median attack handoff at 22 seconds. Agentic AI runs on the same clock. The enforcement decision has to fire inline, before damage compounds across the agent's next call.

Pillar 1: agent identity

What it requires

Every AI request carries verified identity context. For an agent deployment, the identity has two parts: the natural person on whose behalf the agent acts, and the agent's own identity scoped to its delegated authority. The application's identity system issues, rotates, and revokes agent identities. The model API call carries both.

Where most deployments fall short

Static service credentials issued to the application are the default in early agent deployments. The credential grants permanent access to the full model API for any caller, any prompt, and any data context. The credential identifies the application, not the human or agent acting through it. NIST Pillar 1 cannot be satisfied with a shared static credential.

The architectural answer is per-agent identity with delegation. The agent has its own identifier. The authorizing user has a separate identifier. The combination flows with every model request as a structured identity object. The enforcement layer reads the identity object and applies policy against it.

Pillar 2: delegated authority

What it requires

Per-request, per-role, under-this-policy evaluation. The agent's authority is scoped to what the authorizing user permitted, the policy in effect at the moment of the request, and the data classification of the prompt itself. The same agent may be permitted to summarize a meeting at one moment and rejected for issuing a credit decision at the next, depending on the policy and the data.

Where most deployments fall short

Application-level access control evaluates whether a user can call an API endpoint. It does not evaluate whether this specific request, with this specific prompt content, is permitted under the policy in effect right now. The post-authentication gap covers exactly this distinction.

Authentication answers "who is calling." Authorization at the AI call layer answers "what is this caller permitted to do with this prompt content right now." Most deployments answer the first and leave the second unaddressed. Meta's March 18 Sev-1, where an internal AI agent exposed sensitive data to engineers who were fully authenticated but not authorized for that data, is the canonical example.

What the enforcement layer does

The enforcement proxy reads the identity object, the policy in effect, and the prompt content. The policy decision point evaluates the request against per-route, per-role, and per-decision rules. The decision is deterministic and fails closed: ambiguity or error defaults to deny.

Pillar 3: action lineage

What it requires

A structured record of who authorized this, under which policy, at what moment, with what outcome. The record must reconstruct the agent's full traversal: which user authorized the agent, which goal did the agent receive, which prompt did the agent issue, what classification applied, what policy governed the decision, what outcome resulted, and what the agent did next.

Where most deployments fall short

Application-controlled logs fail the self-attestation test. The system that makes the AI decision is the system that writes the audit log. Three failure modes apply: selective logging where the application records successes and omits edge-case failures; suppression where logs can be wiped or modified by the same system that failed; loss on crash where the agent acted but the application crashed before the log committed.

In every other regulated industry, the system under audit is not the system generating the audit record. The CFO does not sign the audit of financial statements they prepared. The architectural answer for AI is the same: an external proxy commits the audit record before the model response returns to the application.

What the enforcement layer does

Every decision produces a per-decision audit record containing identity, role, policy version, data sensitivity, decision outcome, and timestamp. The record is signed and tamper-evident. The record is committed before the model response returns to the application, which means the application has no opportunity to suppress it. The record store has its own retention schedule and its own access controls, separate from the application's log infrastructure.

Why model guardrails do not substitute

Model providers ship safety training into their models. Refusal patterns, RLHF, constitutional AI. These behaviors live inside the inference process. They are probabilistic, not enforceable. Stanford Trustworthy AI research, alongside the AIUC-1 Consortium briefing developed with CISOs from Confluent, Elastic, UiPath, and Deutsche Börse, found that refusal behaviors of model-level guardrails are significantly degraded under targeted fine-tuning and adversarial pressure.

Defense in depth combines model safety, good prompting, and external enforcement. Pillars 2 and 3 of the NIST framework cannot be satisfied by guardrails alone because guardrails do not produce identity-bound, deterministic, externally auditable records.

Why DLP does not substitute

Network-layer DLP runs underneath TLS encryption. The HTTPS POST from the agent process to the LLM endpoint is encrypted at the network layer. The prompt payload is invisible to DLP unless TLS inspection is configured for AI provider domains and the API payload is parsed for prompt fields. Even with that configuration, document-level classification produces false negatives across most prompt traffic because prompt context windows are unstructured natural-language text composed of fragments.

Identity correlation also fails at the DLP layer. The DLP system sees an outbound HTTPS request from an agent process. It does not see "this user, at this role, sent this prompt." That correlation requires the proxy layer to be in the path with the identity object attached.

Compliance lens

The same architecture satisfies multiple regulatory regimes at once.

EU AI Act Article 12 mandates automatic recording of events over the system lifetime for high-risk AI systems, effective August 2, 2026. Article 19 specifies that logs include the period of use, the input data, the reference databases checked, and the identification of natural persons involved. Article 99 sets penalties at €15 million or 3% of global annual turnover.

Fannie Mae Lender Letter LL-2026-04, effective August 6, 2026, requires governance, inventory, audit trails, and disclosure on demand for AI-assisted decisions in mortgage origination and servicing. The lender is liable for AI mistakes by subcontractors and vendors.

NIST AI RMF and ISO 42001 reach the same architectural conclusion through different language. Per-decision evaluation, identity-bound records, independent audit trails. Each regime uses different vocabulary for the same infrastructure requirements.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits at the AI request boundary as an external enforcement layer between the agent and the LLM API. The proxy reads the identity object the application supplies, evaluates per-route and per-role policies, and applies prompt-level classification. The decision is deterministic and fails closed.

Per-decision records are signed at the moment of evaluation and committed before the model response returns to the application. The audit record set is the action lineage NIST Pillar 3 requires. The proxy is model-agnostic and works in front of OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, and on-prem inference endpoints.

If you are running autonomous agents in a regulated environment and your current evidence depends on application logs that the application controls, that evidence is incomplete.