The missing layer between model risk and application security

I installed an autonomous agent on a personal Linux box this morning and the first thing it told me, before it would run a single command, was that its terminal security scanner was misconfigured. A single open-source binary that intercepts pipe-to-shell attacks, homograph URLs, ANSI injection, and obfuscated payloads before any of them reach a process. The warning was small, the implication was not. What it surfaced is that a category of control belongs in enterprise AI governance that almost nobody has yet named.

Enterprise AI governance has done a competent job of maturing the model-lifecycle layer. There are inventories, owners, approval gates, validation regimes, monitoring expectations, retraining policies, data-lineage records, and a slowly-converging treatment of analytic tools that are not strictly models. The vocabulary is mostly settled. What an institution needs to say about a model before it goes into production has been argued over for long enough that the disagreements are now about depth and proportionality rather than about premise.

The agent-execution layer is naked by comparison. A reasoning system that produces text cannot, on its own, delete a row, send an email, transfer a file, or hit an external API. An agent can. The blast radius shifts the moment the system gains the ability to act. And the layer that governs what the system actually does once running — the actual sequence of shell commands, tool invocations, network calls, and file operations the agent emits in response to a prompt — is not really anywhere in the standard institutional stack. Model risk reviews the model. Application security reviews the application. Neither sits behind the agent at execution time, watching the verbs as they go out, and deciding which to allow, which to require approval for, and which to refuse.

The closest analogues exist but in adjacent disciplines. A web application firewall watches HTTP traffic. An EDR agent watches process behaviour. A privileged-access management system gates production commands behind approvals. None of these were built for the case where the actor is an autonomous reasoning system whose intent is reconstructed from a natural-language prompt rather than declared as a programmatic action. An agent runtime guardrail needs to do something none of those tools do: read the agent’s command stream as evidence of intent, understand which patterns indicate legitimate autonomy and which indicate prompt-injection-driven coercion, and intercept before harm.

A few open-source projects have started circling this. Tirith, Lakera, Spectre, and a handful of internal tools at large vendors all reach toward the same shape from different angles, but no settled language has emerged. There is no equivalent to the model-risk literature that an enterprise architect can pick up and structure a policy around. The category is real, the threat is real, and the products that exist are early. That is roughly the position prompt-engineering tooling occupied two years ago, and the position model-risk tooling occupied a decade ago, before institutional language hardened around it.

The institutions that will govern agentic AI seriously will need this layer before the agents they deploy go past read-only. Not after. The question worth asking now is not whether agent runtime guardrails should exist, but where in the existing controls hierarchy they sit, what the adjacencies are, and what naming convention will let policy reference the category without collapsing it into either model-lifecycle or application-security-by-another-name. Sitting too long with the question is what produces a control gap that only gets named once an incident has already used it.