A Reference Architecture for Runtime Agent Security

How to deploy inspection, enforcement, and proof at the point where agents act.

1. The gap this architecture fills

The three-layer model — identity, runtime, governance — is now widely shared. The difficulty is that the middle layer is the least standardized and the hardest to place. Where does it intercept — at the model API, the tool call, the network egress, or all three? Does it run in the cloud or locally? What does it capture, and where does that capture go? What can an operator change, and what must remain fixed even against a valid administrative command?

The documented incidents of 2025 and 2026 are, read closely, an argument about exactly these questions. EchoLeak succeeded against a system whose identity and permissions were never violated — the failure was the absence of enforcement on the action. The Replit database deletion happened because a capable agent had standing power and no enforced boundary at the point of the destructive operation. MCP tool poisoning works because tool trust is assumed rather than inspected at the moment of use. Each points to the same conclusion: the enforcement point has to be as close as possible to where the agent actually acts, and it has to be structurally incapable of the failure modes it exists to prevent.

2. Principle one — inspect on the wire, at the point of action

An agent's intent is not observable. Its actions are. Every meaningful thing an agent does — call a model, invoke a tool, read a resource, reach the network, move data — eventually becomes a request that crosses a boundary. That boundary is where the action is both real and still reversible. It is the right place to inspect.

Concretely, this means placing the enforcement point in the request path between the agent and the services it calls, as a transparent-proxy pattern applied to agent traffic: to the agent, nothing changes except the address it talks to; to the operator, every action becomes visible and governable at the moment it happens. Inspecting on the wire has three properties inspection elsewhere lacks. It is complete for the actions that matter — anything reaching an external system passes through it, including the tool calls and egress that carry exfiltration. It is timely — the request can be held or blocked before the action completes. And it is agent-agnostic — it does not depend on cooperation from the agent framework, the model, or the tool. MCP tool traffic passes through the same request path, so the enforcement point sees tool invocation and tool response as the concrete actions they are, rather than trusting a description that may have been poisoned.

3. Principle two — enforce locally, on the device

Here is the principle that most sharply distinguishes a runtime architecture that can be trusted from one that cannot: to protect an agent, the enforcement point has to see everything the agent does — so it must be structurally incapable of becoming the thing that leaks it.

The naive approach routes agent traffic through a cloud inspection service. By construction, that service receives the full content of every request — prompts, data, file contents, tool arguments — centralizing off the customer's machine the most sensitive material in the environment. The control becomes a breach waiting to happen. The architecture this paper recommends inverts that: inspection happens locally, on the device where the agent runs. The raw content of an agent's requests never leaves the machine as a condition of being inspected. What may leave — if the operator enables it — is metadata about the decision: the category, the severity, the verdict, the identity of the agent. Never the prompt, the data, or the file.

This should be an architectural guarantee, not a policy promise. A promise is a sentence in a data-processing agreement; a guarantee is a property of the system — an egress path structurally constructed so raw content cannot be placed on it, and an elevated-disclosure mode that, if it exists, requires explicit multi-party consent and is off by default. Local enforcement also positions the control exactly where privileged actions occur — the same developer machines the 2026 MCP research showed running agents with developer-level OS privileges and no process isolation.

4. Principle three — make policy legible and testable

A control that cannot be read cannot be trusted, and a control that cannot be tested cannot be governed. The architecture treats policy as a first-class, legible artifact: enforcement decisions expressed as explicit rules over agent actions — at minimum a graduated set of dispositions such as allow, ask (hold for human decision), deny, and terminate. A security engineer should be able to open the policy and see, in plain terms, that reading the source tree is allowed, that reading a credentials file is denied, that a destructive system command is terminated outright.

Legibility enables the property that actually builds trust: testability before the fact. An operator should be able to pose a hypothetical action — “what happens if an agent tries to read the cloud credentials file?” — and get the decision the live policy would make, before any agent attempts it.

There is a corollary about floors. Some protections should not be reducible even by a valid administrative action — a destructive-command block, a credential-exfiltration block. In a well-designed architecture these exist as hard floors that neither a routine policy change nor a cryptographically valid remote command from a management console can lower. The Replit incident is the argument for this. Finally, the direction of change should be asymmetric: strengthening protection should be frictionless; reducing it should require a deliberate, confirmed, auditable ceremony.

5. Principle four — write a record that holds up

The fourth principle is the one regulation is now making non-negotiable. The EU AI Act's high-risk obligations, in force from August 2026, include automatic recording of events over a system's lifetime. Incident response has the same requirement from a different direction. The architecture writes every enforcement decision into a tamper-evident record: each entry cryptographically linked to the one before it, so any change breaks the chain detectably, and each entry signed so the record's origin is provable. Two properties matter. First, the record must be independently verifiable — an auditor can check the entire chain themselves, offline, using standard cryptography, without trusting the vendor. Second, verification must be honest about failure — when a record has been altered, the system reports the break rather than papering over it. Policy defines what should happen; the tamper-evident chain proves what did.

6. Deployment topology one — the single workload

The simplest deployment protects a single machine: a developer running coding agents, or a server running an autonomous workload. The enforcement point installs locally as a lightweight, hardened gateway; routing an agent's traffic through it is a single configuration step. Two operational choices make it safe to adopt. First, the layer should start in an observe-only posture — inspecting and recording, showing the operator exactly what it would enforce, without yet blocking. Second, moving from observe to enforce should be a deliberate, reversible action the operator takes when ready. The result is a control a single engineer can adopt in minutes and arm on their own timeline, with the raw content of their work never leaving the device.

7. Deployment topology two — the managed fleet

The second topology matters at organizational scale and for managed service providers: one control point per machine, many machines under one management plane. The shape is a two-plane architecture. On each device, the local enforcement point does the work above. Above them, a management console provides centralized policy, visibility, and response — without ever pulling raw content off the individual machines. What flows up is decision metadata; what flows down is policy.

Three properties keep the fleet plane trustworthy: actions that reduce protection across many machines carry a confirmation ceremony that states the blast radius; protection floors defined centrally are ones the console itself cannot lower; and management commands are signed and verified at each device, so the device enforces its floors even against an otherwise-valid command. The console governs the fleet; it does not get to override the safety guarantees the architecture makes at each edge.

8. Fitting beside identity, tooling, and compliance

• Beside identity. This layer does not replace agent identity. Identity answers what an agent may reach and remains the necessary first control. The runtime layer answers the question identity structurally cannot: given what an agent is allowed to reach, is what it is doing right now actually safe? The two compose.
• Beside existing security tooling. The enforcement point runs alongside endpoint protection, DLP, and network controls, not instead of them. Adoption should be additive and reversible, not rip-and-replace.
• Beside compliance. The tamper-evident record is designed to be the artifact an audit needs — producing exactly the evidence the EU AI Act, the Colorado AI Act, the NIST AI RMF, and ISO/IEC 42001 increasingly require, as a byproduct of doing its job.

9. Summary: the shape of a runtime layer that works

• On the wire. Inspect where an agent's action becomes a request — where it is real, complete, and still stoppable, and where poisoned tools and exfiltration are visible.
• On the device. Enforce locally so raw content never has to leave the machine to be inspected.
• Legible and testable. Express policy as rules a human can read and simulate, with hard floors neither a routine change nor a valid remote command can lower.
• Provable. Write every decision to a tamper-evident, independently verifiable record that is honest about tampering.

The agent will act. The only question this architecture answers — and the one identity and governance cannot — is whether the action itself is inspected, enforced, and provable at the moment it happens.

Read next