ARCHITECTURE EATS POLICY FOR BREAKFAST

Prompt injection spent two years as the risk at the back of most AI security discussions. In 2026 it became operational, with three separate disclosures against Claude that shared one property: the enforcement lived inside the thing being attacked.

All three were reproducible against default or near-default configurations.

Hidden instructions embedded in a claude.ai URL parameter executed silently when the user pressed Enter. No MCP servers, no integrations, no special configuration. Conversation history, business strategy, and personal data were all reachable from a default session. Anthropic patched the prompt injection flaw.

A malicious .claude/settings.json in a cloned repository ran arbitrary shell commands through hooks, before any trust dialog appeared. Disclosed by Check Point Research, fixed in Claude Code 1.0.111.

A single environment variable, ANTHROPIC_BASE_URL, overridden in a repository's config, redirected all Claude Code traffic, including API keys, to an attacker-controlled server before the consent prompt appeared. Also Check Point, fixed in 2.0.65.

The first targets the model's context window. The other two target the configuration files that govern how the agent runs, one layer upstream. In every case the agent followed its instructions correctly. The instructions had been quietly replaced.

The OWASP Top 10 for Agentic Applications 2026, released in December 2025, ranks Agent Goal Hijacking (ASI01) as the number one risk. The security community has converged on a specific conclusion about how to address it: defences that depend on recognising the attack will eventually fail. Defences that structurally prevent harm, regardless of attack pattern, are the ones that hold.

The underlying problem is that AI agents process untrusted content with trusted privileges. A prompt injection attack does not need to compromise a credential or exploit a network.

It needs the agent to read something the attacker controls, then act on it. When the enforcement layer lives inside the model, the model is both the target and the defence.

AstridOS is an open-source Rust microkernel agent runtime. It does not sit inside the model. It owns the process at the kernel level, beneath the model, and governs what the agent's runtime environment is permitted to do. Configuration changes are tracked and verified.

If something attempts to modify agent settings, whether a malicious repository, a tampered environment variable, or an injected instruction, AstridOS detects the change and blocks it, because the process itself is governed rather than monitored.

Most agent runtimes treat configuration files as passive metadata. That assumption is what the CVE-class attacks rely on. AstridOS treats configuration as a governed surface, and the enforcement happens below the layer a prompt can reach.

This is the distinction the security community draws between kernel-level enforcement and trust-based enforcement. A trust-based approach asks the model to recognise an attack. A kernel-level approach makes the attack irrelevant, because the action cannot complete regardless of what the model is instructed to do.

Agent security is often framed as a constraint: accept some capability limit in exchange for reduced risk.

The inverse is closer to the truth.

Enterprise AI deployments stall not because the technology does not work, but because the risk surface cannot be governed. Agents with full shell access, MCP connections to production databases, and write access to repositories need a security model that does not depend on the model's judgement. Without one, the deployment profile is either heavily sandboxed and low-capability, or high-capability and ungoverned.

AstridOS resolves that trade-off. When the enforcement layer sits below the model, agents can be given expanded access, because the boundaries of that access are structural rather than advisory. Budget enforcement, per-principal isolation, and cryptographic action authorisation are architecture, not policy. They do not degrade under adversarial input.

The same infrastructure that makes agents safer makes them more capable at scale. Capsule architecture lets multiple agents share verified context without exposing one agent's state to another. Per-principal provisioning gives each agent instance isolated storage and capabilities, enforced at the kernel boundary. Audit trails are immutable by construction.

That is what moves a deployment from single-agent to multi-agent production: infrastructure that governs what agents can do independently of what they are told, rather than another layer of prompt engineering.

AstridOS is an open-source Rust microkernel. The agent you already run sits on top of it unchanged, and AstridOS owns the process beneath. Four primitives do the work:

• Capsules: capabilities are packaged as portable sandboxed units, each isolated in its own WASM sandbox, so one tool cannot reach another's state.
• Signed authorisation: actions are authorised by Ed25519 signature, not by prompt. An instruction the model was talked into does not carry a valid signature.
• Per-principal provisioning: each agent instance gets isolated storage, capabilities, and a spend budget, enforced at the kernel boundary rather than by container convention.
• Immutable audit: every action produces a tamper-evident record the agent itself did not generate.

None of this requires rearchitecting what you run today. AstridOS slots beneath Claude Code, Hermes, or a custom harness and adds the enforcement layer they cannot provide from inside the model.

AstridOS is open-source and available now. If you are running Claude Code, Hermes, or any other agent setup, it runs underneath without migration or modification. The core is open source and on GitHub:

AstridOS runtime: github.com/unicity-astrid/astrid

The quickstart in the runtime README takes you from install to a running agent on AstridOS, and shows the wrap-underneath path if you already have an agent in production. If you would rather not stand up your own infrastructure, early access to the hosted runtime and the supported service is open now, with a direct line to the engineers building it: [add early-access link].

Questions and build logs are welcome in the Discord.

What next?

Start at github.com/unicity-astrid/astrid, or join the conversation on Discord.