Principals, Durable State, and the Meaning of Ownership
Astrid’s authority model would be incomplete if it protected a request but lost track of whose state the request changed. The focus here is the principal and the durable root: how Astrid identifies an acting software tenant, separates that tenant’s state from operator policy and external workspaces, and publishes changes without confusing a content hash with permission. This makes ownership a lifecycle question—what persists, who may advance it, what survives a crash, and what may eventually be reclaimed.
A principal is an actor, not a container for everything visible
In ordinary software, “the application” often stands for several different things at once: the process that runs code, the user who launched it, the directory it can see, the credentials it carries, and the data it creates. That shortcut becomes dangerous when one capsule serves several callers. The capsule is the same software, but the callers may not share an identity, secret, quota, or durable home.
Astrid treats a principal as an attributable executable identity. A principal can run an agent harness, a provider, a vault, an indexer, or another service. It is not inherently a model, a prompt, a conversation, or a capsule name. That distinction keeps ownership from following whichever product happens to be running at the time.
The same capsule can serve multiple principals, but the runtime must change the context of each invocation. Astrid’s hosted engine can install temporary overlays for the caller’s key-value view, durable home and temporary space, secrets, environment, quota profile, cancellation state, and operational log. These overlays do not turn the capsule into a different package. They bind the package’s execution to a different authenticated actor for the duration of the request.
This is the storage equivalent of the event-routing rule. A provider may share code and compiled artifacts, but Alice’s model selection cannot be read as Bob’s. A write made by Bob must be charged and audited under Bob’s context. If Bob’s principal view is retired, the runtime should cancel Bob’s blocked work without cancelling Alice’s work merely because both requests entered the same capsule instance.
When identity resolution fails, the safe fallback is not “use the default principal.” Astrid’s host state has neutral, fail-closed contexts for principal-less or unresolvable work. Such a context can return an empty or denied view, but it does not accidentally expose a nearby user’s home or KV namespace. This is a small design choice with a large consequence: ambiguity reduces authority instead of selecting a convenient owner.
The source also distinguishes a principal from a fleet. The broader fleet design gives one user a home fleet that may contain several agent and service principals. Principals inside one fleet may deliberately share a cooperative computer, files, or browser identity. That is a product-level collaboration boundary, not an adversarial tenant boundary. Separate users’ fleets must not share writable state or capability material merely because the physical store can deduplicate their bytes.
The distinction matters for deletion and transfer as well. A mutable alias or display name is not the durable identity. Moving a principal between ownership contexts is an explicit transition, not a filesystem rename. A later identity that reuses an old alias must not inherit the retired identity’s KV, secrets, or audit history by accident.
Durable ownership has five different shapes
Astrid’s principal-store design refuses to treat everything an agent can see as one exportable “workspace.” It separates at least five classes of state.
Principal-owned durable state includes the home, capsule KV, explicit durable capsule state, and selected preferences.