How is agentic AI security different from securing an LLM application?

A single-prompt LLM application runs at the cadence of human interaction. The reviewer has time to look. An autonomous agent runs at machine speed and chains decisions without human review. The same architectural problems (identity, classification, policy, audit) appear in both, but agentic deployments fail faster because the negative outcomes compound across many calls before anyone notices. The architecture has to operate inline and produce per-decision records that satisfy disclosure on demand.

Where should the enforcement layer sit in an agent deployment?

At the HTTP AI request boundary, in the path between the agent process and the LLM endpoint. The proxy intercepts every call to OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, or self-hosted inference, applies the policy, and returns the decision before the model is reached. Sidecar deployment, service-mesh integration, and gateway integration all support this position.

Can we satisfy agent governance with model guardrails alone?

Model guardrails are probabilistic. They degrade under fine-tuning, adversarial prompting, jailbreaks, and role-play framing. The Stanford Trustworthy AI and AIUC-1 research demonstrates this empirically. Defense in depth combines model safety, good prompting, and external enforcement. Only the external layer produces deterministic policy decisions and identity-bound audit records.

Do we need a separate identity for each agent?

NIST Pillar 1 requires verified identity context for every AI request. In 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. Per-agent identities support per-agent policies, which is what most regulated environments require for action lineage purposes. Shared service credentials produce shared roles and undermine the delegated-authority model.

What happens if the agent operates against an on-prem model rather than a vendor API?

The same architecture applies. Self-hosted Llama, Mistral, or other open-weight models still serve HTTP requests over the network. The enforcement proxy sits in front of the inference endpoint and evaluates each request the same way. The model location does not change the agent's identity, the prompt's classification, or the deployer's audit obligation.

Agentic AI Security: Why Autonomous Agents Need a Policy Layer

Google Mandiant's M-Trends 2026 report, based on 500,000+ hours of frontline incident response, found that the median time between initial access and handoff to a secondary threat group collapsed from over 8 hours in 2022 to 22 seconds in 2025. Agentic AI runs on the same clock. An autonomous agent decides, calls a model, applies the response, and chains the next decision in a loop. Anything that depends on a human reviewing logs after the fact has lost the race.

I want to walk through what agentic AI actually does at the request layer, where the existing security stack is unable to see those requests, and what an enforcement architecture has to do to keep the agent's actions inside policy.

Agent traffic as a first-class data channel

An autonomous agent runs as a process that issues HTTPS calls to an LLM endpoint, applies the response, and frequently calls another endpoint based on what came back. The traffic looks like normal API traffic at the network layer. The substance is different. The prompt may include credentials, customer records, regulated data, or instructions the agent inferred from a tool call. The response may include a directive that another process then acts on.

Three properties make this traffic different from human-driven traffic. The cadence runs at machine speed: thousands of requests per minute from a single agent are routine. The identity context can be ambiguous: the request often runs under a service credential, a delegated user identity, or a synthesized agent identity. The data classification varies request to request: the same agent that summarizes a meeting at one moment may produce a credit decision at the next.

Where the existing stack fails

Static credentials violate least privilege

Most agent deployments use static service credentials issued to the application. The credential grants permanent access to the full model API for any caller, any prompt, and any data context. That violates least privilege by design. NIST's AI agent identity and authorization framework codifies the alternative under Pillar 2, delegated authority: per-request, per-role, under-this-policy evaluation.

Model guardrails are probabilistic

Model providers ship safety training into their models. Refusal patterns, RLHF, constitutional AI. These behaviors live inside the inference process. They are not enforceable controls. 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. An agent's safety cannot rest on the model's own refusal.

Application logs fail the self-attestation test

If the application that runs the agent also writes the audit log, the system under audit is the system generating the audit record. The log fails under three conditions: selective logging where the application records successes and omits edge-case failures; suppression where the application can wipe or modify its own log; and loss on crash where the agent acted but the application crashed before the log committed.

DLP is blind to prompt content

Network-layer DLP runs underneath TLS encryption. The HTTPS POST to api.openai.com or to a Bedrock 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.

What an agent enforcement layer requires

The architecture that keeps agentic AI inside policy has six properties.

Identity context attached at the request layer

The enforcement layer needs the verified identity of the natural person on whose behalf the agent acts, the agent's identity itself, the role and authorization scope in effect, and the policy context the application supplies. This is the NIST Pillar 1 requirement. Pillar 1 is the application's job; the enforcement layer evaluates what the application supplies.

Per-request policy evaluation

Every agent call is evaluated against the policies in effect at that moment. Per-route policies attach to API destinations. Per-role policies attach to user and agent roles. Per-decision policies attach to the data classification of the prompt. The evaluation is deterministic and fails closed: ambiguity or error defaults to deny.

Prompt-level classification

The classifier reads the prompt body before the request reaches the model. PII, regulated data, source code, and pre-announcement financials are detected at the field level. The classifier feeds into the policy decision point, which selects pass, redact, or block.

Inline enforcement, not log-and-alert

A blocked request never reaches the model. A blocked response never reaches the application. Enforcement overhead in production tests measures under 50 ms, well inside the 500 ms to 5 second window LLM inference takes. The overhead is invisible relative to the model's response time, which means there is no architectural cost to making enforcement inline.

Action lineage as a structured record

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 response returns to the application. This is what NIST Pillar 3 calls action lineage.

Write-path independence

The application never has custody of the write path for the audit record. The enforcement proxy commits the record to its own log store, on its own retention schedule, with cryptographic integrity. The system under audit is not the system writing the audit record.

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. Penalties under Article 99 reach €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 agent identity and authorization framework, with the comment window closed April 2, 2026, splits the work across three pillars and locates Pillars 2 and 3 explicitly at the AI request layer.

Different vocabularies, same architectural requirements.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between users or agents and the LLM APIs they call. For every request and response, it evaluates identity, data classification, model authorization, and organizational policy, and makes a pass, redact, or block decision before the traffic reaches the model.

Per-decision records are signed at the moment of evaluation and committed before the model response returns to the application. The application never has custody of the audit write path, which closes the self-attestation gap. 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.