Quis custodiet ipsos custodes? Who guards the guards themselves?
The problem is old. Plato raised it in the Republic: once you appoint guardians to protect the city, who keeps the guardians in check? The Latin tag we remember it by came later, from the Roman poet Juvenal.
For AI agents in production, the question is not rhetorical anymore. Every platform ships guardrails now: policy prompts, moderation layers, allowlists, "safety" sidecars. All of them are software. Software runs somewhere. And where a guardrail runs decides whether you can believe what it tells you.
We have written before about why the agent is untrusted by default and what a sandbox has to mean for that to be a real control rather than a vibe. Those posts were mostly about enforcement: hardware-isolated microVMs, one per task, via urunc. This post is about the other half of the problem, the one that gets far less attention.
Not stopping the agent. Knowing what it did.
Guardrails are software, and software runs somewhere
Here is the failure mode we care about. An agent holds credentials to your production environment. Something goes wrong, or an auditor simply asks: what exactly did this agent do last Tuesday?
The obvious answer is to read the agent's own transcript: its tool calls, its logs, its narration of the session. That record is rich and readable, and it is worth exactly nothing as evidence. It is written by the thing you are auditing, in the same context an attacker can inject into. If the agent was compromised, or just wrong, the transcript is the first casualty.
The next answer is to put a monitor next to the agent, in the same container or on the same kernel. Better, but the monitor now shares fate with the workload it polices. A guard that lives inside the blast radius can be disabled, deceived, or raced by the thing it guards. We said it in the manifesto and it holds here: a guardrail running in the same kernel as the agent it polices is a suggestion, not a boundary.
Which inevitably leads us to the question: is there a vantage point the agent cannot reach?
Three vantage points, three levels of trust
The way we think about it, there are essentially three places you can observe an agent from, and they form a ladder.
Inside the agent's context. Self-reporting: transcripts, tool logs, the agent's own account of the session. Richest semantics, zero trust. Anything the agent can read or write, an attacker can too.
Inside the guest. Our execution layer deliberately keeps the guest minimal: no control channel from the guest back into the host, nothing running that the task did not ask for. When we do place an observer inside the microVM for richer telemetry, it goes in under a strict rule: it talks one way, outward, and we treat it as a witness rather than a judge. It sees the OS-level truth (processes, files, connections) with good semantics, but it lives inside the blast radius. A fully compromised guest can, in principle, lie to it or about it.
At the VM boundary. This is the interesting one. Every packet the agent sends, every block it writes, every exit it takes crosses a boundary the CPU enforces, and we record it from the host side, outside anything the guest can touch. The guest cannot suppress this record, cannot rewrite it, and (this is the part we like) cannot even tell how closely it is being watched. Observation is passive and out-of-band; there is no probe inside the guest to find.
Notice the trade: as you move down the ladder, trust goes up and semantic richness goes down. The transcript tells you a story. The boundary tells you the truth, in a language nobody wants to read.
So the design is not "pick a layer". It is: use every layer, trust each one only as far as its vantage point warrants, and corroborate downward. The agent's story is a hypothesis. The in-guest view either supports it or it does not. The boundary record settles it.
This layered problem is starting to get a name. Uber recently formalized Agentic Detection and Response (ADR) as a discipline: sensor-based telemetry that captures prompts, reasoning chains, and tool calls from the agent's own local stores. It is genuine progress, and the category will grow. But notice where their sensor sits on the ladder: it parses the agent's caches, which means it reads what the agent chose to write. That is Level 1. The vantage point we care about, the one the agent cannot narrate its way out of, is still below.
And that is the honest answer to Juvenal. The in-guest observer guards the agent. The hardware boundary guards the observer. The last guard is not software anyone can talk to; it is the isolation mechanism itself.
The most useful signal is disagreement
Once you have the same session observed from multiple vantage points, something nice falls out for free: divergence detection.
If the agent claims it ran a test suite, the boundary should show the file and network activity a test suite produces. If the transcript says "I only read the config", but the boundary shows an outbound connection nobody mentioned, you do not need to decide whether the agent is lying or confused. Either way, you have a session that should not be trusted, flagged by evidence the agent had no way to forge.
In a corroborated audit trail, a gap between the story and the boundary reality is not noise. It is the strongest signal you have.
Closing the semantic gap
Of course, nobody wants to audit an agent by reading raw boundary events. A TCP connection to some address and a burst of block I/O is the truth, but it is not an answer to "what did the agent do?".
This is the classic semantic gap of VM introspection, and it is where most out-of-band approaches historically gave up. Our take: agents are actually a friendly case for closing it. Unlike arbitrary software, an agent works through a surprisingly regular set of operations (fetch a dependency, clone a repo, run a build, call an API, and so on), and each of those leaves a characteristic shape at the boundary.
So we built a taxonomy of the operations real agents actually perform, learned from real agent sessions, and we lift boundary evidence into it. We call this intent lifting: turning "this pattern of connections and I/O" into "the agent installed a package from this registry", with the confidence tracked per operation. The result is an audit trail that reads like the transcript, except every line is backed by boundary evidence, and the lines that cannot be backed are marked as such.
How well does boundary-only evidence recover intent? Better than we expected when we started, honestly. We are writing up the methodology and numbers properly, and they deserve their own post, so we will leave it at that for now.
What it costs
The usual objection to all of this is overhead, and it is the objection we have the most fun answering, because the vantage point does the work for us.
Observation at the boundary is passive. The agent does not wait for the observer; there is no interposition on the hot path, no code changes in the workload, no instrumentation for the guest to fight with. The microVM itself cold-starts in milliseconds (we have covered that ground before), and the introspection tax on top is small enough that we simply run it on every task, by default, in production. Full measurements are part of the write-up above; the short version is that if you can afford the sandbox, you can afford to watch it.
Audit first, enforcement second
We are deliberately leading with observability here, not enforcement, and that is not a dodge. It is an ordering.
Enforcement decides what an agent may do, and we have written about where those controls have to live, from the isolation model down to the runtime that enforces it. But enforcement is only as good as the ground truth it acts on, and after the fact, the audit trail is your ground truth. When the auditor, the incident review, or your own postmortem asks what the agent did, "here is what it told us" is not an answer. "Here is what crossed the hardware boundary, lifted into operations, cross-checked against what it told us" is.
Essentially, we want the postmortem of an agent session to be held to the same standard as the postmortem of an outage: evidence first, narrative second.
There is more to say about every piece of this (the taxonomy, the lifting accuracy, what happens when the layers disagree in the wild), and we will say it in the coming weeks. If you want the full picture now (the threat model, the isolation scorecard, and the evidence behind each claim), it is all in the whitepaper below.
Quis custodiet ipsos custodes? The boundary does. That is rather the point of having one.
