Runtime Policy Enforcement for Agent Actions

An AI agent doesn't hesitate. It doesn't read the fine print, doesn't second-guess a permission handed to it six months ago by someone who's since left the company, and doesn't pause before deleting a record because deleting records is, technically, in its job description. That's the whole problem in one sentence, and most of the industry is still building governance for the version of this that involves a human blinking first.

Runtime policy enforcement is the discipline of catching the agent at the exact moment it tries to act, before the action takes effect, and deciding in milliseconds whether it's allowed to proceed. Writing a strict system prompt happens long before that moment. Reviewing logs on Monday morning happens long after it. Neither one is standing at the door when the agent actually reaches for the handle, and that gap, small as it sounds, is where most of the damage lives.

Access models built for people assume friction. A human reads a request, feels a flicker of doubt, maybe asks a coworker before hitting send on something irreversible. That friction was never a formal control, but it worked like one anyway, quietly catching a huge share of mistakes before they became incidents. Most employees also never touch the majority of permissions sitting on their account; access accumulates like junk mail, a dormant risk nobody worries about because nobody opens it. Agents don't accumulate anything. An agent with broad permissions uses them, immediately and completely, because using permissions is what agents do when a task calls for it. The average organization now runs around three dozen deployed agents, and industry forecasts point to a sharp jump in enterprise applications shipping with agents built in over the next couple of years, up from a small fraction today. Individual teams spin these up on their own, inheriting service credentials, skipping central review, leaving nothing resembling an audit trail behind. Human-shaped governance pointed at that produces the illusion of control. It carries assumptions about hesitation and friction that don't hold for something acting at machine speed, and no amount of policy documentation changes that fact.

What runtime enforcement actually means at the moment an agent acts

Runtime enforcement means catching the agent at the exact instant it tries to call a tool, touch a database, or kick off a workflow, and evaluating that attempt before it happens. The intercept sits right at execution. The agent reaches for an action; the enforcement layer decides whether that reach connects.

What gets checked in that instant stacks up fast. Which agent, exactly, including version and session. What that agent is permitted to do given its current role, not some inherited blanket of access from whoever set it up. What the action actually is, down to the tool call and the data it touches. What the surrounding context looks like: time of day, rate limits, whatever the agent already did earlier in the same session. And whether any regulatory or internal rule applies to this specific combination of agent, action, and moment.

The output is a decision: allow, block, throttle, sandbox, or escalate to a human. All of it runs in milliseconds, and every decision writes to a log nobody can quietly edit afterward. The shift here is worth sitting with. Governance moves from a standing instruction the agent was told to follow toward a structural limit on what the agent is able to do at all. A suggestion can be ignored. A structural limit can't.

The failure mode that makes pre-execution interception necessary: policy-invisible violations

A 2026 paper out of Atlassian gives this failure a name: policy-invisible violations. It's an uncomfortable idea because it breaks the assumption most people carry into agent design, which is that a well-formed, user-approved, sensible-looking action is a safe one.

Turns out an action can be syntactically correct, explicitly requested, and reasonable on its face, and still break policy anyway. The reason is simple: the facts needed to judge it correctly aren't visible at the moment the decision gets made. The agent doesn't have them. Neither does any filter reading only the text of the request.

The researchers ran 600 model traces, 120 cases across five frontier models, and found violation rates between 90 and 98 percent in the risky cases, across every single model tested. That's not an edge case, that's the baseline. The finding that actually matters for enforcement design is what happened when the system could see world-state, meaning what the action would change if it ran: detection accuracy jumped to roughly 93 percent, against under 69 percent for a content-only check reading the request text alone. That gap is the entire argument. A system that watches what an agent says it will do catches far less than a system that watches what the action actually changes.

A companion paper from July 2026 names the sharper version of this: silent policy-violating writes. The agent finishes, reports success, throws no error, and the violation sits invisible in a log that looks completely clean. Nothing catches that except a check running before the write lands, which happens to be exactly the layer prompt-based defenses never reach.

Why prompt instructions and output filters cannot substitute for enforcement at the action boundary

Telling an agent what it shouldn't do is a request. Making an action unavailable is a fact. Prompt injection is the clearest possible proof of why those aren't the same category of control.

OWASP lists prompt injection as the top critical vulnerability in its 2025 Top 10 for LLM Applications, and the numbers back that ranking up hard: attack success rates against agentic systems have been recorded at around 84 percent, meaning an attacker overriding an agent's instructions is closer to the expected outcome than the exception. Prompt injection appeared in over 73 percent of production AI deployments assessed during security audits, according to OWASP. The indirect version, where the malicious instruction rides in through a document or webpage the agent already trusts rather than through the user's own prompt, now accounts for more than 55 percent of observed attacks in 2026 and succeeds 20 to 30 percent more often than direct attempts. It works precisely because it arrives disguised as content the system has no reason to question. Chains of these attacks moving agent-to-agent grew more than 70 percent year over year across 2025 and 2026.

The cleanest real-world case is EchoLeak, tracked as CVE-2025-32711 and disclosed in mid-2025: a zero-click data exfiltration attack against Microsoft 365 Copilot, requiring no user interaction to execute. Output filters check what the agent said, not what it did, so a silent write producing a perfectly normal-sounding response sails past every filter built to catch bad language. Fewer than 35 percent of organizations have even deployed dedicated defenses against prompt injection, and those defenses still sit above the action boundary, watching text rather than watching effect. Once an injected instruction lands inside the agent's reasoning loop, prompt-level defense has already lost the round. The tool-call boundary is the last checkpoint that still gets a vote.

How the MCP surface area changes what enforcement must cover

Model Context Protocol, released by Anthropic in late 2024, is now the standard way agents talk to tools and data. Wiz Research found MCP servers running in at least 80 percent of observed cloud environments by early 2026, which tells you this stopped being an experiment a while back and became plumbing.

The enforcement wrinkle MCP introduces is structural. The model itself decides at runtime which tool to call and what to hand it, and that decision point sits somewhere the perimeter defenses and threat feeds built for older architectures were never designed to look. Wiz also found roughly 5 percent of environments running at least one MCP server exposed directly to the internet, a publicly reachable tool surface with no consistent enforcement standing in front of it. Sit with that for a second.

A July 2026 paper studying MCP-based agents lays out exactly how this gets exploited. Data pulled in from an external source can redirect a tool call without ever touching the system prompt, sidestepping prompt-level defense by design rather than by accident. Three categories of harm go entirely uncaught by prompt-based approaches: path traversal, exfiltration guided by the user's own legitimate request, and rapid-fire abuse of a tool through repeated calls. The paper's authors tested a Policy Enforcement Point sitting at the tool-call boundary, tracking information flow across steps instead of judging each call in isolation, and it cut attack success from 40 percent down to 5 percent, against 35 percent for the best prompt-only defense in the same test. Turn off that cross-step tracking, and the false-negative rate jumps by more than 26 percentage points. Enforcement that checks one call at a time, in isolation, misses the violations that only show up as a pattern.

The architectures being used to enforce policy at the action boundary today

Nobody has settled on one dominant design. A handful of distinct approaches are competing for the same territory, and each fails differently, which is useful to know before you pick one.

Application-layer policy engines, including access-control platforms that have extended their permissions logic into agent governance, sit inside the agent's own process and check tool calls against active policy before they run. They work fine until the agent spawns a child process, runs generated code outside the instrumented path, or has its reasoning loop compromised. At that point the engine may still report that enforcement held, when it never actually saw the action.

AgentSpec, presented at ICSE 2026, takes a different approach: a domain-specific language for writing runtime constraints as triggers, predicates, and enforcement actions, kept entirely outside the model. Because the policy lives outside the LLM, it stays consistent across model versions and environments, which sounds like a small thing until your vendor ships a model update overnight. The reported numbers are strong: unsafe executions prevented in over 90 percent of code-agent test cases, with results showing consistent enforcement across the other task categories tested.

Microsoft released an open-source Agent Governance Toolkit targeting the risk categories in OWASP's agentic AI list. Each risk category maps to a specific enforcement mechanism, covering areas such as intent classification, capability sandboxing, identity verification, and human-approval gates for the riskiest actions.

Further out sit hardware-rooted approaches. Hardware-rooted approaches run the agent inside an isolated trusted execution environment, so enforcement holds even if the host machine itself gets compromised. Other proposed frameworks combine risk scoring, continuous authorization checks, conformance monitoring, and graduated containment that ramps up restrictions instead of flipping one kill switch. These buy a higher ceiling of assurance at real deployment cost, which makes sense for the agents touching your most sensitive systems and less sense for the one that reformats meeting notes.

Commercial guardrails platforms round out the field: checking agent input and output in real time with dedicated models and configurable policy, catching prompt injection, data leakage, and hallucinated content, with latency that must stay low enough to avoid being routed around in production. Several commercial products compete in this space. Anyone evaluating this category should ask whether the product enforces at the action boundary or only checks output after the fact, how expressive its policy language actually is, whether its audit log is genuinely tamper-proof, and how well it covers MCP and tool-call traffic specifically, since that's where the newer attacks live. Across every architecture on this list, the same weakness keeps showing up: enforcement that looks at one moment in isolation, with no memory of the session, misses the violations that only appear across a chain of steps.

What a runtime enforcement decision actually requires to work correctly

Four things have to be present at the moment of decision, or the decision isn't trustworthy no matter how fast it runs. Identity has to be specific: not "a user account" but which agent, which version, which session, and what that session already did. Permissions have to scope to the current task and role, not inherit wholesale from whatever human account originally set the agent up. The system needs real awareness of world-state, meaning what actually changes if the action runs, rather than parsing the words describing the action and hoping for the best. And policy has to exist as something the system evaluates live, not a paragraph the agent read once at startup and may or may not still be honoring.

Session memory matters more than it sounds like it should. An action that's completely fine in isolation can violate policy given what the agent already did three steps earlier in the same session. A system with no memory of the session cannot see that pattern forming, full stop.

Speed isn't a nice-to-have. If the enforcement check requires a slow synchronous call out to some external system, or forces tool calls to run one after another instead of in parallel, teams under latency pressure will route around it in production, and the control disappears quietly, without anyone deciding to remove it. The audit log has to be tamper-evident in a way the agent's own environment cannot touch; a log the thing under observation can edit isn't a log, it's a suggestion with a timestamp. Back to that Atlassian number: detection accuracy climbed from under 69 percent to roughly 93 percent once the system could simulate what the action would actually change. That's the strongest argument going for building enforcement with real depth, rather than checking a box that says "enforcement present" and moving on. And not everything should resolve to a flat allow or block. Some actions genuinely warrant a human taking a look, and the architecture needs a pause that doesn't just freeze the agent mid-task like a paused video call nobody can unmute.

Why logging and monitoring after the fact cannot replace enforcement before the action

A log tells you what happened. Enforcement decides what's allowed to happen. Treating those as interchangeable is a category error: one of them prevents damage, and the other only writes the eulogy.

Silent policy-violating writes make this concrete: the action finishes, the agent reports success, no error fires, and the log shows a clean, successful operation with the violation nowhere in sight. Only a check running before execution has any shot at catching that class of failure. IBM's 2025 Cost of a Data Breach report found organizations running extensive AI security controls saved an average of $1.9 million per breach compared to those without. Separate research from Deep Inspect found shadow AI incidents cost roughly $670,000 more than standard breaches and took 247 days to detect, against 241 days for an ordinary breach. Two hundred forty-seven days is how long a logging-only posture takes to notice something enforcement would have stopped instantly, and that comparison alone should end most budget arguments.

Gartner projects that by 2028, a quarter of enterprise security breaches will trace back to agent misuse, and forecasts that more than 40 percent of agentic AI projects get cancelled by 2027 over inadequate controls. Logging-only setups produce a very thorough paper trail explaining what went wrong, after it already went wrong; they have no mechanism for stopping anything beforehand. Monitoring spots a strange pattern building over time, which has genuine value, but it can't undo a write to a production database, an email that already went out, or a deletion that already happened. Most of what an agent does is irreversible by nature, and the only moment enforcement actually matters is the one before the action fires, not the retrospective afterward. Monitoring still earns its keep in detection and response; it simply arrives after the moment that mattered most.

What "enforced" actually looks like in a running agent

An agent that's actually enforced looks almost boring from the outside, and that's sort of the point. It attempts an action, a decision comes back in milliseconds, and the action proceeds, gets blocked, gets throttled, gets sandboxed, or gets bumped to a person, with every outcome landing in a log nobody involved can quietly edit. There's no drama to a blocked action. The drama is in everything the agent structurally couldn't attempt in the first place, and you'll never see that part, because it never happened.

The policy-invisible violation, the silent write, the injected instruction riding in through a trusted document: all three share one trait. They're invisible to anything watching from outside the exact moment of execution. Catch that moment, with identity, permission, world-state, and policy all in view at once, and the gap closes. Miss it, and you've got a very convincing paper description of a control that was never actually there.