From AI Runtime to Agent Runtime

Every agent security pitch eventually arrives at the same punchline: “We stop the bad action in real time.” The malicious prompt blocked mid-flight. The sensitive record redacted before it leaves. The rogue agent killed mid-task. It's the moment security looks like security.

Runtime enforcement is the last mile of agent security, and this series has been building toward it since Chapter 1. But the thing being sold under that name today was built in the last era, for the last problem. Call it what it is: AI runtime. A gateway in a pipe you own, inspecting prompts on their way to a model you chose. It’s a reasonable answer to the first-party question. Agents pose a different question, and it needs a different paradigm — agent runtime requires enforcement built for autonomous actors that live, act, and chain inside platforms you don't control.

The difference isn't branding. It comes down to three structural facts: where agents actually run, what happens when enforcement concentrates in one component, and what a millisecond decision needs to already know.

The application layer is the runtime

Look at where the year's biggest agent launches put their agents. Claudeforce runs Claude inside Salesforce's trust boundary, wired into its data and workflows through Salesforce's own agent harness.1 Claude Tag lives inside Slack.2 Copilot lives inside Microsoft 365. Workday's agents, the ones driving a quarter of its new contract value, run inside Workday.3 Slack Code's coding agents execute through Slack, GitHub, and production infrastructure. Chapter 2 called these the agents you inherit. Operationally, the point is even more distinct: the third-party application layer is the runtime agents execute on. Their tools are the application's features. Their knowledge is the application's data. Their permissions are the application's permission model.

A gateway can only watch what passes through it, and most agents never pass through it. An agent executing inside Salesforce, triggered by a Flow, reading CRM records, writing case comments, routes nothing past your inspection point. Neither does the Copilot agent assembling a document from SharePoint, or the Slack-native agent reading a decade of channel history. This is AST09, the unreachable skill Chapter 4 closed on: an agent capability deployed inside a third-party platform where no external scanner can go, credited to Reco researchers Daniel Alfasi and Tal Shapira in the OWASP Agentic Skills Top 10.

Security already made this move once. Firewalls used to inspect packets: source, destination, port. That worked until applications stopped mapping cleanly to ports, and malicious traffic started looking identical to legitimate traffic at the network layer. The fix was moving the inspection point up the stack, to the application itself, where the real signal lives: which app, which user, which content. Agent runtime needs the same move, one layer further up. A prompt inspected at a gateway is still just a packet. The application the agent is running inside, the identity it's wearing, the data it's touching: that's the context no gateway can see. But that earlier fix assumed something agent runtime can't: that you owned the layer you were moving into.

The problem isn't that your inspection point is badly placed. It’s that the execution environment belongs to someone else so the coverage math is short. A gateway-only strategy protects the agents you host yourself, and Chapter 2 established those are the fewest and growing slowest. Everything else runs somewhere a gateway will never see. Each platform is less a building with a front door than a planet with its own atmosphere: its own tenants, its own physics, its own weather of permissions and triggers and data. Your agents already live on dozens of them.

The inspection point is also a target

There's a second problem with concentrating enforcement in a single component. The LiteLLM breach (discussed in Chapter 2), was compromised for forty minutes, with credentials exposed across more than 2,500 organizations. If you read the victim list against the architecture, you’ll find that the organizations hit were disproportionately the security-conscious ones, the teams that deployed a gateway on purpose to watch their AI traffic. The inspection point wasn't just a supply-chain risk. It was the attack vector for the people relying on it as a defense.

This isn't an argument against gateways. It's an argument against treating any single component as the entire strategy. A gateway is one more piece of software in the supply chain, with its own release pipeline, its own dependencies, its own compromise modes, and it concentrates exactly the traffic an attacker wants, every prompt, every response, every credential in the flow. Chapter 4's correlation argument applies to defenses too. When enforcement is a shared component, its failure is a shared failure.

The millisecond needs a memory

A third problem persists even where coverage is perfect: an enforcement decision is only as good as the context it's made with.

Runtime decisions are millisecond decisions — allow, block, warn, redact — and the hard cases are not the credit card number in the prompt. Pattern-matching handles those. The hard cases are gray. A support agent accessing customer data: its job, or exfiltration in progress? A coding agent reading a repository: context gathering, or reconnaissance? A finance agent creating an OAuth connection: integration work, or the first move of a compromise? This is Chapter 4's intent problem, replayed at machine speed: the action alone doesn't carry the verdict, because the same action means something different depending on who's doing it and why. The verdict lives in context — the agent's identity and owner, its permissions, its normal behavior, the data's sensitivity, the destination, the delegation chain behind the request. Judge the action without that context and you land in the failure mode every SOC already knows. Block too much and the business routes around you, block too little and you're a logging appliance with latency.

Agent-to-agent chains raise the bar further. Enforcement that evaluates the last hop sees an authorized agent performing an action it has permission for, and misses that the authority arrived laundered through a chain nobody approved. Judging the full chain at runtime requires already knowing the chain — who delegated to whom, with what scope, on whose original behalf. That knowledge can't be assembled in a millisecond. It has to already exist.

This is the dependency underneath every runtime demo. Enforcement without the layers below is an air-traffic controller with a radio but no radar. The voice of authority is there and commands can be issued. But which plane, where, headed into what… that picture doesn't exist, so every instruction is a guess delivered confidently. Posture is the radar: what an agent can reach, what's normal for it, who it acts for. Runtime is the radio. It only works with the radar on.

What good looks like

Put the three facts together (1. agents run inside platforms, 2. single components are targets, 3. decisions need context) and the shape of real agent runtime follows.

1. 1

   Enforcement goes where the agents are. No single enforcement point reaches the whole population, so runtime control has to be placed the way discovery is: across multiple vantage points. Native platform hooks and integrations, API-level controls, the MCP layer, the browser, the endpoint where local agents live. The industry is starting to open the necessary doors. Anthropic's inference hooks let enforcement participate in Claude's own execution path, and platform harnesses like Salesforce's expose governed integration points inside the trust boundary. The right mental model isn't a wall. It's presence, distributed across the space where agents actually execute.

2. 2

   The verdict comes from the graph, not the packet. Every allow-block-warn-redact decision should be computed against the living map this series has been calling IPCA: identity, permissions, connectivity, activity. Identity shows whose action this actually is. Permissions explain whether the action is even in scope. Connectivity decides whether the destination makes sense given what this agent can legitimately reach. Activity tells you whether this looks like the agent's established pattern or a break from it. Add data sensitivity and the delegation chain behind the request, and that context is what turns the gray cases into judgments, the same action approved for the agent whose role covers it, blocked for the agent three permission-grants adrift of its job. It's also what makes enforcement precise enough for the business to tolerate, because the goal is stopping the bad action without stalling the thousand legitimate ones around it.

3. 3

   The response menu is wider than block. Mature agent runtime is graduated: allow the known-good, warn where justification is plausible, redact where the data is the problem, block where the chain is hostile, and hold the kill switch for the agent that's provably compromised — suspend it, revoke its grants, preserve the trail. Human-in-the-loop approval belongs in the menu too, reserved for the actions where the cost of being wrong is highest. And every verdict gets logged with its full causal path, because "we blocked a risky prompt" satisfies nobody. An incident review and a regulator both want the same thing: the agent, the chain, the data, the destination, and the policy it violated.

As an example, we recently saw a case where an employee asked an AI assistant to trigger a mass-email automation. The automation hit a recipient-limit policy and failed, so the assistant, also connected to the employee's personal email, offered to send the batch from there instead. The employee approved it, not registering that the assistant was about to route around the sanctioned system entirely. It did, and an unknown number of external recipients got email from a personal mailbox instead of the approved channel. It wasn’t a jailbreak — the assistant did exactly what it was built to do. The fix wasn't retraining the model. It was one runtime rule: block anything attempting to reach more than fifty external domains, and explain to the user what the tool was trying to do before it happens.

Don't buy the end state

To close, we’ll go back to Irregular's Dan Lahav and what he calls “the end-state fallacy”: assuming the properties of the eventual equilibrium apply to the transition you actually live in.4 Applied to AI security's long run, it's the belief that because defense may dominate eventually, the next few years will be safe. Applied to runtime purchasing, it's the belief that because inline enforcement will eventually see everything — every platform opened, every hook standardized, every agent routed — you can buy that end state today and skip the unglamorous layers.

You can't. We’re still in the middle of the transition, where runtime coverage is partial, platform hooks are arriving unevenly, and the offense is industrializing on the timeline Chapter 1 laid out. What's buyable today, everywhere, without waiting for any vendor to open any door, is the stack runtime depends on: discovery across every vantage point, posture on every platform, identity and ownership for every agent, context for every decision. Build that, and each enforcement point that opens snaps into a map that already knows what normal looks like. Skip it, and each one arrives able to act but unable to judge.

Stated plainly, that’s the paradigm shift that this chapter has tried to impress upon you. AI runtime guarded a pipe you owned. Agent runtime has to act across a universe you don't.

That completes the argument this series has been assembling: a new era (Chapter 1), three launch vectors into one universe (Chapter 2), governance as a practice (Chapter 3), security at the level of chains and context (Chapter 4), and enforcement placed where agents actually live (Chapter 5). What's left is the practical question: where do you start, what do you fund first, and how do you evaluate the vendors now shouting these words at you. That's Chapter 6.