Aegis: The Runtime That Doesn't Trust the Model

What problem does this solve?

The safety community has been arguing about prompt injection, jailbreaks, and alignment tax for two years. The argument assumes a framing that's already outdated: that the risk is harmful text generation. But agents don't generate text — they execute actions. They modify files, send messages, launch jobs, change workflow state. The harm isn't what the model says; it's what the tool does.

Prompt-level governance — system prompts, constitutional AI, refusal training — can shape what a model proposes, but it creates no execution boundary. A jailbreak that bypasses the refusals bypasses the safety entirely, because the safety lives in the same layer as the instruction. There is no second line of defense. Adam Mazzocchetti's Aegis paper asks what happens when you build one.

What's the method?

Aegis treats every model output as an action proposal — not a command, not an instruction, a proposal. Before anything reaches a tool, it passes through a trusted runtime layer that decides whether to execute, modify, or block it. The architecture has four pillars:

• Active policy state: the runtime holds a live policy — not a static document, but rules that can be updated, versioned, and audited independently of the model
• Server-side provenance: every action's origin is resolved on the runtime side, not from model claims (no trusting the model to honestly report what it's about to do)
• Fail-closed: under uncertainty — when the runtime can't determine whether an action is permitted — the default is block, not allow
• Senate-style settlement: for borderline or high-stakes actions, a quorum-based non-unilateral authorization path: multiple trusted actors must sign off

graph LR
    subgraph "Standard Architecture"
        A[User Prompt] --> B[LLM]
        B -->|"act()"| C[Tool]
    end
    subgraph "Aegis Architecture"
        D[User Prompt] --> E[LLM]
        E -->|"action proposal"| F[Aegis Runtime]
        F -->|"evaluate policy"| G{Policy OK?}
        G -->|"yes"| H[Tool]
        G -->|"uncertain"| I[Fail Closed]
        G -->|"borderline"| J[Senate Settlement]
        J -->|"quorum"| H
    end

The critical design choice: the model proposes; the trusted runtime decides. This is a hardware root of trust model applied to agent orchestration. The model can be compromised, jailbroken, or straight-up malicious — as long as the runtime holds, the system doesn't execute unauthorized actions.

What are the results?

Mazzocchetti evaluated Aegis on a sandbox corpus spanning five run families, 42 tasks, three conditions, and ten repeats per family — 8,400 total rows across two control arms:

• Prompt-policy conditioning alone (6,300 rows): 79 risky comparator-path leakage rows — actions that bypassed the prompt-level guardrails and got through to the tool layer
• Aegis-governed (2,100 rows): zero governed mock-tool applications, zero governed risky side-effect completions — every risky proposal was caught at the runtime boundary
• 1,832 Aegis-attempted governed rows: all preserved trusted provenance resolved server-side
• 1,019 Senate-settled rows: all had quorum and final signed tally evidence — no failures in the multi-party authorization path

The contrast between the two arms makes the argument: prompt-level conditioning leaks risky actions even with careful engineering. The Aegis runtime caught every single one.

What are the limitations?

The paper is unusually honest about its scope, and the limitations are worth taking seriously:

1. Sandbox corpus. This is not a production deployment. The tasks are scripted, the risks are known in advance, and the policy is authored by the same researcher who built the system. Real-world deployment will surface edge cases this evaluation can't reach.
2. Single policy author. The policy state is hand-authored. Scaling to diverse organizational policies — with conflicting rules, ambiguous permissions, and legacy workflows — is an open problem.
3. Does not prove general autonomous-agent safety. Mazzocchetti is explicit about this. The claim is narrower: runtime action-boundary governance prevented observed risky proposals from becoming governed side effects in this evaluated corpus. That's a systems claim, not an alignment claim.
4. Senate settlement latency. Quorum-based authorization introduces human-in-the-loop delay. For high-frequency agent operations this may be impractical — the paper doesn't measure the latency cost.

Why should someone building things care?

Because every agent framework shipping today — every single one — treats the model's tool call as authoritative. The safety layer is a system prompt. A system prompt. If you're deploying a coding agent that can write to your filesystem, or a customer-facing agent that can send emails, or an infra agent that can spin down instances, your safety boundary is the same text that tells it to be helpful. One injection away from compromise.

Aegis isn't proposing alignment. It's proposing access control. The insight is boring in hindsight: we solved this problem in operating systems fifty years ago. You don't trust userland programs to enforce their own security policies — you have a kernel that mediates system calls. Why do we trust LLMs to enforce theirs?

The architecture is portable. The paper doesn't depend on a specific model provider, framework, or tool interface. Any agent builder could implement a runtime governance layer. The question is whether they will — or whether we collectively wait for the first high-profile agent incident before the industry takes execution boundaries seriously.