You Have to Be in the Execution Path
Every generation of security governance eventually learned the same lesson. The AI agent industry hasn't learned it yet.
In the first three pieces, I built a case. Agents are unattested. The entity that acts cannot attest. And the record you actually need — a decision trace — can only be produced from a specific architectural position.
Now I want to talk about that position. Because the industry is converging on an approach to AI agent governance that is architecturally incapable of delivering what it promises. And the people promoting it aren’t wrong about the problem. They’re wrong about where you have to stand to solve it.
Here is the framing you’ll hear at every conference, in every analyst briefing, and in every vendor pitch this year:
“Runtime security for AI agents.”
It sounds right. Agents operate at runtime. You need to monitor them at runtime. Therefore: runtime security.
But listen to what’s actually being proposed. Better logging. Threat graphs. Endpoint telemetry. Behavioral detection. Trace-back analysis. SIEM correlation.
Every one of these approaches shares a single architectural property: they observe after the action has occurred.
The agent makes a tool call. The tool executes. The result is delivered. And then — afterward — a detection system notices something suspicious, raises an alert, and an analyst begins an investigation.
This is the observe-and-detect model. It’s the same model the security industry has used for decades. And for a specific category of threat — human adversaries moving at human speed through systems designed for human interaction — it worked well enough.
For autonomous agents operating at machine speed, it is structurally insufficient.
I want to be precise about why, because this isn’t a philosophical objection. It’s an architectural one.
When a human employee does something suspicious — accesses a file they shouldn’t, sends data to a personal email, runs an unusual query — the security stack has time. The action takes seconds or minutes. The detection pipeline processes the telemetry. An alert fires. An analyst investigates. If it’s serious, the employee’s access is revoked. The damage is contained, because humans are slow and the response can usually catch up to the threat.
An AI agent doesn’t work like that.
An agent can chain ten tool calls in two seconds. It can read a sensitive database table, extract PII, format it as a summary, and post it to an external API — all before a detection pipeline has finished processing the first event. By the time your threat graph has traced the connection, the data is gone. By the time your analyst reviews the alert, the session may already be over.
Observe-and-detect assumes there’s a meaningful window between action and consequence. For human actors, that window exists. For autonomous agents, it often doesn’t.
This isn’t a speed problem you can solve by making detection faster. It’s a sequencing problem. If your governance model evaluates an action after it executes, you are always behind. You are governing the past. The agent is operating in the present.
Recent industry coverage has framed runtime security as “the new frontier” of AI agent governance. The framing is thoughtful. The problem identification is accurate. And the proposed solutions are, almost without exception, observe-and-detect.
Endpoint detection tools that build threat graphs after actions occur. Behavioral monitoring that flags anomalies for human review. Platform logging improvements. SIEM aggregation.
The claim from one major endpoint vendor is that existing EDR tools already handle AI agent monitoring — that because EDR instruments the operating system, it can see everything an agent does and trace it back through a threat graph.
This is technically true and architecturally misleading.
EDR sees process spawns, file system operations, and network connections. It can tell you that application X made a connection to IP Y. It cannot tell you that the connection was an MCP tool call requesting customer records from a CRM database, that the agent’s role didn’t authorize CRM access, that the response contained 4,000 Social Security numbers, or that this was the third hop in a multi-agent delegation chain initiated by an unverified requester.
EDR instruments the operating system. Agent governance requires instrumenting the decision. These are different layers, and conflating them creates a dangerous illusion of coverage.
The same coverage noted — correctly — that some agents can overwrite their own session logs. But instead of recognizing this as a structural failure that requires architectural separation between actor and attestor, the recommendation was to improve logging practices. Get better logs. Capture them earlier. Store them immutably.
That advice secures the warehouse. It doesn’t verify what was put into the truck. We covered this in Article 2. Immutable storage of a self-reported record is still a self-reported record. You’re still storing the testimony of an untrusted witness — just more reliably.
The mistake the industry is making right now is not a new one. We’ve made it before with every prior generation of security technology. And every time, we eventually learned the same lesson.
Network security. In the early days of enterprise networking, security was passive. Network monitoring tools captured packets, analyzed traffic patterns, and flagged anomalies. IDS — Intrusion Detection Systems — would observe traffic and raise alerts. Security teams would investigate after the fact.
It didn’t work. By the time an alert fired, the malicious traffic had already reached its destination. The detection was accurate. The response was too late.
So the industry evolved. IDS became IPS — Intrusion Prevention Systems. Passive monitoring became inline enforcement. The security device moved from beside the network path to inside the network path. It didn’t just observe traffic. It blocked traffic. In real time. Before it reached the destination.
That architectural shift — from observation to inline enforcement — is what made network security functional. Not faster detection. Not better dashboards. A change in position.
Web application security. Same pattern. Early web security was observational — log analysis, periodic vulnerability scans, post-incident forensics. Then SQL injection, cross-site scripting, and remote code execution made observation insufficient. The response: the Web Application Firewall. Inline. In the request path. Evaluating every HTTP request against a policy before it reaches the application.
API security. Same pattern again. Early API security was perimeter-based — rate limiting at the gateway, API key validation, post-hoc log analysis. Then API sprawl, broken authorization, and data leakage made perimeter controls insufficient. The response: inline API gateways with per-request policy evaluation, payload inspection, and real-time enforcement.
In every case, the industry started with observe-and-detect. In every case, it was insufficient. In every case, the solution was the same: move the security control from beside the path to inside the path. From passive to inline. From after the action to before it.
AI agent governance is following the same arc. The industry is in the observe-and-detect phase right now. The architectural endpoint is inline enforcement. The only real question is whether organizations get there before or after a preventable incident forces the shift.
What does inline actually mean in the context of AI agents?
It means every action an agent takes — every tool call, every API request, every database query, every file operation — passes through an independent enforcement point before it reaches the target system. Not after. Before.
At that enforcement point, the action is evaluated against policy. The agent’s identity is verified. The agent’s permissions are checked against the specific action being requested. The payload is inspected for sensitive data. The action is assessed against the agent’s behavioral baseline. And based on all of that — in real time, before execution — the action is allowed, denied, or escalated to a human for review.
If the action is allowed, it passes through to the target system. If it’s denied, the agent receives an error and the target system never sees the request. If it’s escalated, the action is held until a human approver makes a decision.
This is not a new concept. It’s how firewalls, WAFs, and API gateways already work. The only thing that’s new is the protocol and the actor.
For AI agents communicating through MCP — the Model Context Protocol, which is rapidly becoming the standard for agent-to-tool communication — inline enforcement means an MCP proxy. The agent points its configuration at the proxy instead of directly at the target MCP server. Every tool call passes through the proxy. The proxy authenticates, evaluates policy, inspects data, and makes an enforcement decision — all before the target system is ever contacted.
The agent doesn’t need to be rewritten. The target system doesn’t need to be modified. The enforcement layer sits between them, independently, in the execution path.
There’s a reason inline enforcement matters beyond speed, and it connects directly to everything I’ve written in this series.
Inline is the only position from which a decision trace is producible.
Remember the six elements from the last piece: identity context, policy evaluation, data classification, causal linkage, requester provenance, integrity chain. Every one of them requires the attestation layer to be present at the moment of action. Not before the agent was deployed. Not after the action completed. At the moment the tool call is made.
An observer that sits beside the execution path — a SIEM, an EDR, a log aggregator — can only record what it receives from the acting system. It’s downstream. It sees what the platform chose to emit.
An observer that sits in the execution path sees everything. It sees the request before it reaches the target. It sees the response before it reaches the agent. It evaluates policy at the moment of decision. It classifies data in transit. It links causal chains in real time. It produces a record that the agent cannot influence, because the agent’s request must pass through the observer to reach its destination.
Inline enforcement and independent attestation are not two separate capabilities. They are the same architectural position delivering two outcomes: governance and evidence.
You cannot have a decision trace without being inline. You cannot enforce policy before execution without being inline. You cannot classify data in transit without being inline. You cannot stop a bad action before it happens without being inline.
Every other position is a compromise. Useful, perhaps. Necessary for defense in depth, certainly. But structurally incapable of delivering the primary governance function: ensuring that autonomous agents operate within policy, with independent evidence that they did.
I want to address the “defense in depth” argument, because it’s the reasonable objection.
Experienced security leaders will say: “We don’t pick one layer. We build multiple layers. EDR at the endpoint. SIEM for aggregation. Inline enforcement at the proxy. Build all of them.”
They’re right. Defense in depth is sound doctrine. Nobody should stop using their SIEM or decommission their EDR because they’ve deployed an inline enforcement layer.
But defense in depth has a hierarchy. Not all layers are equal. Some layers are supplementary. Some layers are foundational.
For AI agent governance, inline enforcement is the foundational layer. It’s the only layer that can produce a decision trace. It’s the only layer that can stop an action before execution. It’s the only layer that can enforce policy at machine speed. It’s the only layer that satisfies the attestation separation principle — because it’s structurally independent from the agent and positioned to observe every action.
Everything else is supplementary. EDR adds OS-level visibility. SIEM adds correlation and long-term storage. Platform logging adds developer observability. All valuable. None sufficient.
The industry’s mistake is not in building supplementary layers. It’s in treating supplementary layers as if they were foundational. Telling CISOs that EDR already handles AI agent monitoring is like telling them a security camera already handles access control. It records what happened. It doesn’t prevent what shouldn’t.
There’s a reason the industry keeps defaulting to observe-and-detect despite the architectural limitations. It’s familiar. It fits existing toolchains. It doesn’t require anyone to change how agents are deployed. It lets vendors say “you’re already covered” and lets CISOs check a box without deploying new infrastructure.
Inline enforcement is harder. It requires an architectural change. It requires agents to route through a new layer. It requires policy to be written and maintained. It requires an independent identity service for agents. It requires someone to take responsibility for a new piece of infrastructure in the execution path.
But “harder” and “wrong” are different things. Network security was harder after the shift from IDS to IPS. Web security was harder after WAFs became standard. API security was harder after inline gateways became the norm. In every case, the harder approach was the one that actually worked.
Every enterprise security architecture eventually reaches the same conclusion: if you want to govern behavior, you have to be in the path where behavior occurs.
Not beside it. Not downstream of it. Not reading reports about it after the fact.
In it.
The entity that acts cannot attest. A decision trace can only be produced from the execution path. And policy can only be enforced before the action — not after.
The principle is straightforward. The implementation is work.
If you want to govern autonomous behavior, you have to stand where the behavior happens. In the execution path. Before the action. Not after.
Next in this series: why agent governance isn’t a security product — it’s deployment infrastructure. The real buyer isn’t the person who says no. It’s the person who needs to say yes.