What is agentic AI runtime security?

It is the set of controls that operate while an agent is executing, as opposed to controls applied during design, code review, or model selection. Runtime security exists because an agent's next action is chosen from content that arrives during the run: a retrieved document, a tool response, a web page. Static review cannot anticipate that content, so it cannot anticipate the behavior. The runtime control points are the planning step, the tool call, context assembly, and the model call. The model call is the only one that sits outside the agent's own process and therefore survives the agent's compromise.

Why isn't scoping the agent's tools enough?

Tool scoping is a strong control and it belongs in every agent deployment, because it sits directly in front of the side effect. Its limitation is that it is enforced by the agent framework, which is code inside the process an attacker may already control. A scope check that the attacker can patch out is not a boundary. Tool scoping also has no visibility into what the agent is sending to the model, so it cannot see regulated data leaving in a prompt or an unauthorized identity making inference calls. Scope the tools and enforce identity policy on the AI traffic; the two cover different failures.

Can model guardrails serve as an agent runtime control?

No. Guardrails are probabilistic behaviors trained into the model through RLHF, constitutional AI, and fine-tuning on refusal examples. They influence output rather than enforce policy, they are controlled by the provider rather than the enterprise, they degrade under adversarial pressure and targeted fine-tuning, and they produce no independent record of what was decided. They are a useful layer in defense in depth. They cannot be the layer an enterprise's compliance evidence rests on, because there is no evidence to point at.

How does runtime enforcement handle indirect prompt injection?

Partly at context assembly and partly at the model call. At assembly, content is marked by provenance so instructions arriving inside a retrieved document are not treated as instructions from the principal. At the model call, the enforcement point evaluates what is actually in the assembled prompt: if injected content has caused the agent to pull regulated data into the context window, or to target a model endpoint outside its authority, policy denies the call regardless of what the agent believes it is doing. That second layer is what holds when the first is bypassed, which is why injection defense is a defense-in-depth problem rather than a filter problem.

Does inline enforcement slow an agent down?

The overhead is small relative to what an agent already waits for. Internal DeepInspect testing measures enforcement overhead under 50 ms per call, against LLM inference of 500 ms to 5 seconds. Across a forty-step run the accumulated enforcement cost stays in the low seconds while the model calls themselves account for the overwhelming majority of wall-clock time. The number that matters operationally is p95 with classification enabled, because a control with unpredictable tail latency is a control that gets disabled after the first performance incident.

Agentic AI Runtime Security: The Controls That Only Exist While the Agent Is Running

A conventional application's behavior is fixed at build time. You can read the code, enumerate the paths, and reason about what it will do before it does it. An agent's behavior is assembled at runtime from content it did not have when it started: a document it retrieved, a tool response it received, an instruction embedded in a web page it was asked to summarize.

That property moves the entire security decision into the running loop. Threat modeling an agent from its source code tells you what it is capable of. It tells you nothing about what it will choose, because the choice is made from data that arrives after the review is finished.

The four control points in an agent loop

Every agent framework, whatever the vocabulary, executes some version of the same cycle. There are four moments in it where a control can intervene.

The planning step. The agent decomposes an objective into a sequence of intended actions. A control here can constrain the plan space: this agent may draft a purchase order, it may not approve one. The limitation is that the plan is advisory. Agents revise plans mid-run, and a constraint applied only to the initial plan is a constraint on the agent's stated intent rather than on its behavior.

The tool call. The agent invokes a function: a database query, an HTTP request, a file write. A control here is the strongest available in terms of blast radius, because it sits directly in front of the side effect. Scoped tool permissions, per-tool authorization, and argument validation all live at this point. I covered the permission model in AI agent tool permissions.

Context assembly. The agent builds the next prompt from the tool return, the conversation so far, and retrieved documents. This is where untrusted content enters the reasoning path. A control here can strip, quarantine, or mark content by provenance, which is the core mitigation for indirect prompt injection.

The model call. The assembled prompt goes to the LLM over HTTP. Every step in the loop passes through this point, which makes it the only control point that sees the whole run.

Why the model call is the enforceable one

The first three control points are inside the agent's own process. Whoever writes the agent implements them, and whoever compromises the agent removes them. A tool-permission check enforced by the agent framework is enforced by code the attacker now controls.

The model call is different in one structural way: it leaves the process. It is an HTTP request to an external endpoint, and an enforcement point placed in that path is outside the agent's blast radius. It sees every step of every run, it evaluates policy that the agent cannot edit, and it renders a decision the agent cannot appeal.

That gives it three properties the in-process controls lack.

Determinism. The decision is a policy evaluation, not a model judgment. The same identity, the same prompt classification, and the same policy produce the same outcome every time. Model-side guardrails are probabilistic behaviors trained into the model, and they degrade under fine-tuning and adversarial pressure. Stanford Trustworthy AI research summarized in the AIUC-1 Consortium briefing found refusal behaviors significantly degraded under targeted fine-tuning and adversarial pressure (Help Net Security). Anything that depends on the model refusing is a gap, which is the argument in model guardrails are not a security control.

Independence. The record of what was decided is written by the enforcement point, not by the agent. A compromised agent can lie about what it did. It cannot lie about what it sent, because the proxy holds that.

Coverage. A forty-step run makes forty model calls. Every one of them transits the same point. There is no path through the loop that avoids it.

The runtime threats this actually addresses

Be specific about what moves and what does not.

Addressed at the model call: an agent whose context has been poisoned attempting to send exfiltrated data out in a prompt; an agent whose scope has been escalated calling a model endpoint it has no authority to reach; an unrecognized in-environment identity making inference requests, which is the signature of an attacker's agent operating inside the estate; regulated data entering a prompt bound for a public model.

Not addressed at the model call: an agent executing a local shell command; an agent reading a file it should not have had filesystem access to; theft of the credentials the agent uses. Those are process-isolation and IAM problems, and they need sandboxing and least-privilege credentials. An HTTP proxy in front of the model cannot see them and should not claim to.

The honest architecture is layered. Sandbox the process, scope the tools, and enforce identity policy on the AI traffic. The third layer is the one that survives compromise of the first two, which is why it carries the audit record.

The tempo argument

Runtime controls exist because response controls have run out of time. Google Mandiant's M-Trends 2026 report, drawing on over 500,000 hours of frontline incident response, found the median interval between initial access and handoff to a secondary threat group collapsed from over eight hours in 2022 to 22 seconds in 2025 (Help Net Security). An agent loop iterates faster than that. By the time an alert reaches an analyst, the run has completed and the side effects are in the world.

Enforcement in the request path is the only posture whose latency is bounded by the request itself. Internal DeepInspect testing measures enforcement overhead under 50 ms, against LLM inference of 500 ms to 5 seconds, so the decision costs a fraction of the wait the agent already accepts.

DeepInspect

This is the problem DeepInspect was built to solve. DeepInspect is a stateless proxy at the AI request boundary. Every model call an agent makes, at every step of a run, transits the proxy carrying the agent's identity, the principal it acts for, and the scopes delegated to it.

DeepInspect evaluates policy on each call against that identity, the role it holds, and the classification of the content in the assembled prompt, then permits, redacts, or denies inline, with a fail-closed default. The decision is deterministic and the policy lives outside the agent, so compromising the agent does not compromise the control. Every decision writes a signed record carrying the chain identifier, the policy version, and the outcome, committed before the response returns to the agent.

If you are running agents in production and want to see what enforcement in the loop looks like, book an AI readiness assessment.