Runtime governance: the model proposes, the runtime decides

Out of 6,300 rows recorded in an agent testbed, 79 ended with a risky action slipping through when the only barrier was the prompt. Across the 2,100 rows that went through a runtime control layer, that figure was zero. That contrast is the heart of Aegis, a paper published on arXiv on 19 August that tackles a problem that stopped being theoretical a while ago.

The framing deserves attention because it redefines what safety means in agentic systems. An agent that only generates text can say something inappropriate. An agent with tools writes files, sends messages, launches jobs and changes workflow state. The harm stops being semantic and becomes operational. And there, the authors argue, prompt level governance has a structural limit: it can shape model behaviour, but it does not create an execution boundary. A system prompt is not a permission.

The model proposes, the runtime decides

Aegis inverts the usual order. It treats every model output as an action proposal rather than a command, and routes it through a trusted decision layer before the tool ever executes. That layer does four things:

1. Evaluates the proposal against active policy state, not against a policy frozen inside the prompt.
2. Resolves provenance server side, so the origin of an action does not depend on what the model says about itself.
3. Fails closed under uncertainty: if it cannot decide, it does not execute.
4. Routes selected cases through what they call Senate style settlement, a quorum based authorisation path designed so that no sensitive action is unilateral.

The first three points are classic systems engineering applied to a new context. The fourth is the most interesting and also the most debatable: it adds cost and latency in exchange for no critical action depending on a single judgement.

What it measures and what it does not

The experimental setup is a repeated sandbox corpus: five run families, 42 tasks, three conditions and ten repeats per family. That yields the 6,300 total rows and the 2,100 governed by Aegis, with zero governed mock tool applications and zero governed risky side effect completions. The public abstract cuts off right as it details the 1,832 governed attempts, so that stretch has to be looked up in the PDF.

That zero should not be read as a guarantee. It is a sandbox, with tasks defined by the authors themselves, and a system that fails closed tends to score well on safety by construction. The question the abstract does not answer is how much legitimate work it over blocks and how much latency the quorum adds. Without the false positive figure, the zero is half the story.

Why this matters here

If you build agents with Claude Code, this describes something you already half have. PreToolUse hooks are exactly the point where a decision can be interposed before a tool runs, and the CLI permission system is a real policy, not a suggestion written into the context. What the paper adds is rigour on three details we tend to skip: that policy should live outside the model's context, that provenance should be resolved server side, and that the default behaviour under doubt should be not to execute.

Our experience building MCP servers and integrations for clients points the same way. The typical failure is not a model behaving badly, it is a well behaved agent holding a permission that is too wide. Aegis does not solve that on its own, but it puts numbers on something that until now was argued from intuition: instruction and permission are separate layers, and confusing them is expensive.