A Request in Motion: How Astrid Preserves Identity Across Boundaries
Astrid’s capsules, event routes, and effect gates become meaningful only when one request remains attributable as it crosses them. This chapter connects those mechanisms around a single question: can a request that enters through an uplink retain the right principal, the right authority, and the right evidence all the way to a capsule effect and its response? The answer is a qualified yes for the paths the hosted runtime implements, provided that identity is verified at the boundary and every shared state lookup is re-scoped to that identity.
A request crosses several boundaries, not one
Consider a client asking an Astrid-backed assistant to perform an operation. The client may be the local CLI, an MCP connection, or an HTTP-facing gateway. Astrid calls these frontends uplinks because they are protocol clients of the daemon, not privileged application layers. Their first responsibility is to establish or carry an authenticated connection. The request then enters the daemon as an event with a source, topic, payload, and principal attribution.
At this point, the principal is not a decorative field. It determines whose authority and state the rest of the request may use. A host-verified local connection can bind the request to a principal. The IPC contract also distinguishes a claimed attribution from a verified one when an uplink relays a remote identity. In the current host path, publish-as derives the effective identity from host-verified connection state when available and ignores the guest-supplied name; an unbound connection receives a non-privileged anonymous identity. A claimed name may be useful as input to an additional authentication step, but it must not be accepted as proof that the sender owns the named principal.
The daemon publishes the event through the bus. The bus checks the route’s topic and principal scope before delivering it to the capsule. Astrid’s publish-side demultiplexer separates queues by capsule, topic, and principal rather than handing a shared consumer a mixed batch and asking it to filter afterward. That choice matters because a capsule instance can be serving multiple callers at once. The route is part of the context in which the request is admitted, not merely a transport detail.
The capsule receives the event and invokes its behavior. If it needs to read a file, call a network service, spawn a native process, publish another event, or change durable state, it crosses a host interface. The corresponding host path checks the requested operation. The route that delivered the request does not automatically authorize the effect. A principal-scoped IPC subscription is not a filesystem grant, and a capability to invoke one tool is not permission to connect to every network destination.
Only after the relevant effect-specific checks succeed does the operation reach the resource or state it names. The result then travels back as an event through the appropriate route. Audit receives the authorization and outcome information along the way. The whole path is therefore a chain of boundaries: ingress, attribution, routing, invocation context, effect authorization, state change, and response.