Astrid: A Capability-Secure OS for Composable Software

The problem Astrid solves

Astrid addresses a specific failure mode in agent and automation software: the assumption that an LLM or a script can be trusted to follow instructions. The README states that agent frameworks put trust in the prompt, while Astrid puts it in the runtime. The project treats every component as an untrusted process, like an operating system treats a process. Each ability is a sealed WebAssembly capsule that can be composed with others, granted explicit authority, and replaced without expanding its reach. The target user is a developer building composable software, often with an agent loop, who wants an OS-grade boundary between components and the host. It is not for someone who wants a pre-packaged agent with tools included, because Astrid deliberately does not bundle a product distro.

The kernel is deliberately dumb

The architecture separates intelligence from enforcement. The kernel, implemented as astrid-daemon, routes events, enforces capabilities, runs the sandbox, and records the audit trail. It holds no model, tool schema, or business logic. The README calls it small and deliberately dumb. This is a design choice with a real benefit: a capsule bug cannot corrupt shared kernel state because the kernel has no conversation state and no tool registry. The kernel instantiates an event bus, loads capsules, and routes IPC bytes under a capability ACL. Capsules communicate exclusively through the bus, and the kernel resolves the dependency graph from Capsule.toml manifests using a topological sort. Tools are an IPC convention, not a kernel concept: a tool capsule intercepts tool.v1.execute.<name>, and the kernel never sees a tool schema. This means the kernel stays small, but it also means that all intelligence and policy live in capsules, which you must write or obtain.

Capabilities, not permissions

Astrid uses a cryptographic capability model. Every file path, network host, and tool is a signed ed25519 grant scoped to a resource pattern, principal-bound, expiry-checked, and globally revocable. The README says: no grant, no access. This is fundamentally different from a permission list checked against a user identity. A capability is a token that can be passed and subset-scoped. Per-device tokens can be subset-scoped, meaning you can grant a capsule access to a narrower resource pattern than the original token allows. The kernel enforces these capabilities at the boundary, not as a prompt instruction. The security model is decomposed: there is no single gate. The README lists five layers: the WASM sandbox, the manifest gate, the IPC ACL, the capability token, and approval. Each is enforced independently where the effect happens. This fail-closed design means that a jailbreak, poisoned tool, or plain bug cannot read a file, reach a network, or spawn a process outside its grant.

How to get it running

The quick start uses Homebrew on macOS and Linux. You run brew tap astrid-runtime/tap && brew install astrid, then astrid init --distro @yourorg/your-distro, astrid start, astrid status, and astrid capsule list. The init command fetches a distro, which is a curated capsule bundle. You must pass a distro explicitly with --distro, either by name, repository, local Distro.toml, or signed .shuttle archive. Astrid does not bundle a distro, so you must choose one you trust. If you run an uncomposed runtime, you can skip init and start the daemon directly. For non-macOS systems, you can install from crates.io with cargo install astrid (requires Rust 1.95+), or build from source with git clone and cargo build --release. The build produces a binary at ./target/release/astrid. Astrid installs four binaries: astrid (CLI uplink), astrid-daemon (kernel), astrid-build (capsule compiler), and astrid-emit (stdio-to-bus bridge). You only invoke astrid, which manages the others.

The host ABI and capsule lifecycle

Capsules run in Wasmtime with no syscalls, no file descriptors, and no host memory. Every external effect is a capability-checked host call over a WIT-typed ABI. The README lists the astrid:* WIT packages: fs, io, kv, ipc, net, http, sys, process, approval, identity, elicit, and uplink. Guests import only what their manifest allows. This is a strict boundary, but it also means you must write your capsule against these interfaces. The capsule lifecycle is live: you can install, upgrade, and remove capsules on a running daemon without a restart. This is a significant operational advantage for long-running systems. However, the README does not describe the upgrade semantics in detail, such as whether state is preserved or how capability tokens are re-issued. That is a gap you would need to verify before relying on it.

Where it is the wrong tool

Astrid is not a general-purpose OS. It is for composable software, likely agent-based, where components need isolation. If your software does not need cross-component isolation or if you trust all components equally, the overhead of writing Capsule.toml manifests and managing distro selection is not justified. The README explicitly says the kernel holds no business logic, so all intelligence lives in capsules. That means you must build or find capsules for file access, HTTP, process spawning, and other effects. The distro model pushes trust onto the user: you must choose a distro you trust, and the README warns that Astrid does not select or bundle one. This is a sharp contrast to a turnkey agent framework. Also, the security model depends on the correctness of the kernel and the WIT ABI implementations. The README says the mechanisms are independently tested, but it does not provide audit results or formal verification. You should treat the security claims as design assertions, not proven guarantees.

A real alternative: the prompt-trust approach

The direct alternative is a conventional agent framework that puts trust in the prompt, such as a typical LLM agent library where the model is given tools and instructions and is expected to follow them. These frameworks are easier to start with because they bundle tool schemas and agent loops, and they do not require a custom kernel or WebAssembly compilation. The difference in approach is fundamental: a prompt-trust system relies on the model's instruction-following as the security boundary, while Astrid enforces authority in the runtime. The trade-off is that prompt-trust systems are simpler to deploy but expose the host to any prompt injection or model error. Astrid is harder to adopt but contains the blast radius. If your threat model includes untrusted model output, Astrid's approach is stronger. If your threat model is limited to accidental bugs in your own code, a prompt-trust framework may be sufficient and far less work.

Maintenance, licensing, and what to verify

Astrid is licensed under Apache-2.0, which permits commercial use, modification, and distribution with attribution, and it does not impose copyleft obligations. That is a permissive license, so you can embed it in proprietary software. The project is under active development, with releases v0.10.1, v0.10.2, and v0.10.4 in July 2026, and the last push on 2026-07-20. The version numbers below 1.0 suggest that the API and WIT ABI may change between releases. The README does not provide a migration guide or a stability policy, so you should expect breaking changes. The Contributor Handbook is linked for those who want to contribute, but there is no explicit maintenance cost statement. Before adopting, you should verify the compatibility of your capsules with the current WIT ABI version, test the upgrade path from one release to the next, and confirm that the audit chain can be exported and verified with your tooling. The audit chain is signed and hash-linked, so you can verify tampering, but the README does not specify how to access or validate it in practice.

Editorial conclusion

Adopt Astrid if you build agent or automation systems where the failure mode of a compromised component must be contained to its grant, and you are willing to manage capsule manifests and distro selection yourself. Do not adopt it if you expect a turnkey runtime with bundled tools or if your team lacks Rust and WebAssembly experience. Before committing, verify that the WIT ABI packages cover the host calls you need, test the distro selection and upgrade path on a non-production daemon, and confirm that the audit chain and capability revocation meet your operational requirements.

Official sources

1. Official README
2. Project repository
3. Release notes