Astrid's Core Promise: Composition Without Inherited Authority
Astrid is a Rust runtime and operating-system project for software packaged as WebAssembly capsules. The question that matters here is not simply whether an agent can produce a useful answer or call a tool, but who is allowed to turn that answer into a real effect. Astrid’s distinctive promise is that software should compose without inheriting one another’s authority: behavior may be assembled from replaceable components, while permission remains explicit, bounded, attributable, and revocable. That distinction provides the working map for understanding the project, its current hosted runtime, and its more ambitious native-OS direction.
The problem is not intelligence; it is authority
An agent system can decide what to do without being entitled to do it. A model may select a file operation, a network request, or a subprocess because the request appears useful. The model’s output is still only a proposal. A prompt that says “be careful” is not a boundary around the machine, because the prompt does not control every path by which code can reach a file, credential, socket, or process. If the proposal is wrong, malicious, or merely overconfident, the host must have an independent way to refuse it.
Astrid starts from that uncomfortable premise: an agent is untrusted code running on a computer with access to valuable resources. The current runtime therefore does not give a capsule ordinary ambient access to the host. WebAssembly code runs inside a sandbox and reaches external resources through host calls with typed interfaces. Those calls are where the runtime can check what is being requested, whose context is making the request, and whether the effect fits the policy attached to that context.
This is not an attempt to make the model itself authoritative. Astrid does not choose a product, an LLM provider, an agent loop, or a user interface. Those are compositions that can live above the runtime. The runtime’s job is narrower and more consequential: make the boundary around their effects real enough that a mistake in one component does not automatically become permission to control everything else.
A simple example makes the distinction concrete. Suppose a capsule is part of an assistant that wants to read a project file and ask an external service for information. The capsule can contain the code that understands the request and formats the result. It can declare the interfaces and resource categories it expects. But the declaration does not, by itself, let the capsule read an arbitrary path or connect to an arbitrary host. The actual host call still crosses the runtime’s checks. Composition explains what the capsule can contribute; authority determines what it may cause.
What Astrid is—and what it is not
The source repository supports two related but different descriptions of Astrid. Today’s concrete product is a portable user-space runtime for macOS and Linux. A daemon owns system resources, loads capsules, routes events, manages sessions, and exposes local control surfaces. Capsules can provide agent loops, providers, tools, services, or non-cognitive infrastructure. They communicate through typed interfaces and an event bus, and their lifecycle can be managed while the daemon is running.
The project’s longer-term direction is an Astrid-owned operating system. The proposed native kernel would create protection domains, schedule them, route bounded IPC, mediate hardware, revoke authority, and recover failed domains. That design is explicitly exploratory. It is not the same thing as the current daemon, and the repository’s workplan warns against treating an architecture paragraph or a successful host prototype as proof that a bootable native system already exists.
That distinction is important because “kernel” has two meanings in the source. The current astrid-kernel is a semantic supervisor inside a host process. It wires together the event bus, capsule registry, capability store, durable state, audit, and local transport. The planned astrid-native-kernel would be a ring-0 capability microkernel with a much smaller vocabulary. It would know about domains, memory, endpoints, budgets, devices, and revocation—not websites, LLMs, filesystems, or tool semantics.
So the subject is neither a generic agent framework nor a finished general-purpose operating system. It is Astrid’s attempt to provide a governed substrate on which many kinds of software can run. The hosted runtime is the evidence-bearing baseline. The native kernel is a proposed continuation of the same boundary discipline.
Four questions that must not be collapsed
The easiest way to misread Astrid is to use one word—“the agent,” “the capsule,” “the token,” or “the kernel”—for several different responsibilities. The project becomes clearer when four questions are kept apart.
What behavior is being composed? A capsule manifest describes package identity, WebAssembly components, typed imports and exports, event topics, tools, commands, configuration, and requested capabilities. The loader can combine WebAssembly execution with a native MCP bridge or static context under one lifecycle. This makes software replaceable and additive. A provider can be swapped, an uplink can be added, and an orchestration component can be revised without teaching the generic runtime what the product is supposed to mean.
Who is acting? Astrid uses a principal as an attributable executable identity. A principal is not synonymous with a model, a conversation, or a capsule name. The same capsule may serve several principals, but their state and authority cannot safely be inferred from the capsule alone. The runtime carries principal context through invocation, IPC, storage, secrets, quotas, and audit paths. A display name or a field in an unverified message is not an adequate substitute for authenticated identity.
What effect is permitted? Astrid divides this question among several gates rather than asking one universal interceptor to decide everything. The WebAssembly sandbox removes ambient authority. Manifest-backed host checks constrain filesystem, network, process, socket, and identity operations. IPC publication and subscription are ACL-controlled. Signed capability tokens can authorize bounded resource patterns. Human approval and spending budgets add policy for sensitive actions. The host operating system provides another boundary for native subprocesses. These layers overlap, but they do not have the same job.
A manifest can be reviewed and used to construct a gate; its text is not a cryptographic grant. A model can request a tool; its output is not authorization. A content hash can identify bytes; it is not permission to read them. An audit record can show that a decision and effect occurred; it does not prove that the model’s reasoning was wise or that the input was true. Astrid’s central discipline is to keep those statements from quietly becoming one another.
What state and evidence remain afterward? An action may change a principal’s files, key-value data, or other durable state. The principal-store work separates immutable typed objects from mutable roots, physical placement, and user-facing projections. A root transition says which committed state is current; a capability says who may act on it. The audit chain records authorization proofs, outcomes, and relevant lifecycle events. These records make the system more accountable, but accountability is not the same as permission and neither is the same as correctness.
The separation also changes what “sharing” means. Two principals may eventually benefit from the same physical bytes or compiled work without receiving one another’s authority. Conversely, a shared runtime domain can have the union of the grants held by the capsules inside it. Physical reuse is therefore an efficiency decision, not a grant, while domain placement remains a security decision.
The diagram is deliberately modest. The model or agent loop contributes behavior, but it does not sit on the authority path as the final decision maker. The principal supplies an identity context, but identity alone does not grant every capability. The daemon routes the request, and the gates decide which effects can proceed. The audit record describes the boundary crossing without becoming the boundary itself.
The practical meaning of “without inherited authority”
In ordinary software composition, combining components often combines their assumptions as well as their functionality. A library may inherit the process’s filesystem access. A plugin may inherit the host’s network identity. A subprocess may inherit environment variables, credentials, or a working directory simply because the parent had them. Those defaults are convenient, but they make it difficult to answer a basic question after a failure: which component was actually allowed to do this?
Astrid tries to make the answer explicit at the points where authority matters. A capsule’s requested filesystem scope is checked against the path being used. A network destination is checked before the host performs DNS resolution and, for HTTP, against an SSRF airlock. An IPC message carries principal attribution that can be verified or marked as merely claimed. A persistent capability token is signed by the runtime rather than minted by the agent. A durable state transition is tied to a principal root rather than inferred from a filename or a hash. Each mechanism narrows a different ambiguity.
This approach has a cost. There is no single switch that makes a deployment safe. Reviewers must understand which gate covers which effect, whether a capability is operator-approved or capsule-declared, and whether a contract is implemented or only specified. Typed mediation can also limit performance and feature breadth. The current host ABI is incremental: some filesystem operations, streaming features, and network surfaces remain incomplete even though their versioned WIT contracts define their intended shape. Honest denial or an explicit unsupported result is preferable to pretending that a partially connected path is complete.
The thesis is also narrower than universal security. Bounded authority does not make capsule business logic correct. It does not eliminate timing channels, defeat a hostile host underneath the runtime, or solve the consequences of a stolen signing key. It cannot make same-fleet cooperative sharing equivalent to adversarial tenant isolation. These are not embarrassing exceptions to the idea; they are the conditions that give the idea meaning. A boundary is useful only when its scope is stated.
Astrid’s future native-kernel program carries the same logic below the hosted daemon. Ring 0 would enforce the smallest set of machine-level mechanisms required for isolation and recovery, while runtime hosts, drivers, applications, and reasoning systems remain above it. That future is valuable as a test of architectural continuity, but it must be earned through executable evidence rather than inferred from intention.
Astrid is therefore best understood as a project about the governance of composition. It lets software behave as a system without making the system’s authority mysterious. The next question is how that promise becomes concrete in the capsule model itself: what a capsule declares, how the daemon connects it to other components, and why those declarations still stop short of permission.