Kyvvu secures AI agents so you can use them and still sleep at night. We do that by looking at the sequence of actions the harness takes, not any single action in isolation. For a while, as far as we could tell, we were the only ones thinking about it that way. We’re now seeing more interest in the same idea, from directions we didn’t expect.

There’s an old idea in computer security called a reference monitor: something that checks every action a process attempts, before it happens (complete mediation); that can’t itself be bypassed or altered by the thing it’s watching (tamper-resistant); and that’s simple enough to actually verify (verifiable). It’s not a new concept — it goes back to James Anderson’s 1972 report for the US Air Force on operating-system security — but it maps onto what an AI agent needs. An agent is a harness executing steps, driven by a model whose only channel of influence on the world is the tokens it emits. If you can’t fully trust the model, the check belongs in the harness, mediating what the model’s output actually gets to do.

That’s roughly what Kyvvu tries to be: a reference monitor for the harness. Every step the harness takes is evaluated against policy before it runs, against the ordered history of the task so far — policies on paths, not isolated decisions.

Recently, a few other projects have moved in a similar direction, each drawing the boundary of what gets checked in a different place.

OWASP’s Agent Control Standard (ACS). Originally an independent project from Zenity, launched in May, donated to the OWASP GenAI Security Project on September 2. As far as I can tell from the public spec, it’s a hook definition, not a monitor: it says where in an agent’s lifecycle a control point should exist — a tool call, a memory write, the shift from planning to execution, a sub-agent invocation — and how a policy should attach there. It doesn’t ship a decision engine, so whether an implementation is complete or tamper-resistant depends entirely on how the adopting harness wires it up.

Microsoft’s Agent Control Specification. Part of the Agent Governance Toolkit (AGT), announced in June, since rebuilt as a dedicated Rust core — stateless, deterministic, fail-closed, by their own description — vendored into AGT’s policy layer. It evaluates a snapshot the host hands it at defined points in the agent loop and returns one of five verdicts: allow, warn, deny, escalate, transform. That reads as closer to an actual monitor than the OWASP spec, since it’s a running decision engine rather than a hook definition — though how complete the mediation is still depends on the host supplying a snapshot at every point that matters, which isn’t something we can easily verify from outside. Also, it seems to be fully stateless, so no notion of a path here.

Microsoft named this component the Agent Control Specification (yes, another “ACS”) a few months after OWASP donated a standard with the same initials. Different organizations, unrelated documents, unfortunate overlap. I’ll call it MS-ACS below to keep the two apart.

SHADI, AGNTCY’s secure host runtime, comes at this from a different angle: it wraps the agent process in a kernel-enforced sandbox — Landlock on Linux, Seatbelt on macOS, AppContainer on Windows — plus identity, secrets, and encrypted memory. It has no notion of intent. A write is a write, whether the model asked for it, the harness generated it, or a bug caused it. Of the properties above, this is probably the strongest on tamper-resistance — an OS-level sandbox is hard to route around, model or no model — and the weakest on mediation in any semantic sense, by design: a syscall boundary doesn’t know what a step means. It seems like the necessary groundwork for a reference monitor to work in the sense that it provides the tamper resistance to something that does the monitoring.

For us, this is where SHADI is directly useful. We recently started running a coding agent under SHADI, governed by Kyvvu. Kyvvu governs the path — for example, whether a coding agent can execute code after human approval. SHADI separately enforces that even once that approval is given, the code the agent runs cannot alter the agent itself; it’s tamper resistant.

Here is a short overview of the recent approaches next to each other:

Project	What it is	Complete mediation	Tamper-resistant	Reasons over the task path
OWASP ACS	Hook-point spec, no bundled engine	Depends on the adopter	Depends on the adopter	No — the spec carries no task state
MS-ACS	Rust decision core inside AGT	As complete as the host’s snapshot	Reasonably, if wired in correctly	No — stateless by design
SHADI	Kernel sandbox around the process	Yes, at the syscall/filesystem level	Strong — enforced by the OS	No — no notion of intent
Kyvvu	In-process engine over every SDK-wrapped step	Yes, for the full declared action surface	Yes, for that same surface	Yes — evaluates the full task path

The three “yes” answers for Kyvvu carry the same condition: they hold for whatever our harness integration actually wraps. That’s true by construction, not a caveat particular to us: a reference monitor is only ever as complete as what’s brought under it, whoever builds it. Harness integrations need to be complete, and an open vocabulary is what lets someone other than us check whether a given integration actually is — which is why we opened up our semantic description layer: an Agent Action Grammar (AAG), the vocabulary our engine evaluates against, with RFC-0001 open for comment at github.com/kyvvu/aag. Most of the above is open too: OWASP’s standard is community-governed, AGT is MIT-licensed, SHADI ships open under AGNTCY.

If you want to see the harness-level layer directly in action using kyvvu:

pip install kyvvu
kyvvu try

Local, no account, first policy block in under a minute. Docs at docs.kyvvu.com. Enjoy.