Quis custodiet ipsos custodes? | NOFire

Try now

Blog/Engineering<br>Engineering04 Aug 20265 min read<br>Quis custodiet ipsos custodes?<br>Every agent platform ships guardrails. Almost nobody asks who watches them. We walk through the trust boundaries of observing an agent from outside its sandbox, why the strongest audit trail is written from a vantage point the agent cannot reach, and how we lift raw boundary events into operations a human can actually read.

Anastassios NanosCo-founder & Chief Scientist

Kostis PapazafeiropoulosMember of Technical Staff

Key takeaways<br>A guardrail is only as trustworthy as the vantage point it runs from. Anything executing inside the agent's blast radius, including the observer itself, is a witness, not a judge.<br>The hardware VM boundary is the one place the agent cannot rewrite its own history: every packet, every exit, every I/O request crosses it whether the guest cooperates or not.<br>Boundary evidence is semantically poor on its own, so we lift it into a taxonomy of operations agents actually perform. The audit trail reads like a story, but every line is backed by evidence the agent could not have forged.<br>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...