Making Effects Accountable: Audit, Uplinks, and Operations

Astrid’s authority model is tested at the point where an operator installs a real composition and exposes it to real users. The practical question is how to choose a principal and capsule set, configure a provider, expose an uplink, and keep the resulting effects accountable without letting convenience settings widen authority. This means treating installation, configuration, ingress, signing, and audit as parts of the runtime boundary—not as administrative details that can be trusted by default.

Start with an explicit composition

Astrid does not silently decide which agent product should run. A plain runtime can start with a daemon and no product capsules. An operator may then select a distribution, or “distro,” that supplies a curated composition of capsules and configuration. The explicit input matters: it lets the operator choose which behavior is being installed instead of turning the generic runtime into an implicit product launcher.

A distro can be a repository source, a local manifest, or an offline bundle. The stronger offline form packages a manifest, a resolved lock, and the capsule archives that the lock names. Each capsule is pinned by a content hash, and the manifest is bound to the lock. The installation process verifies the bundle’s signature and internal hashes before it installs any capsule. This establishes a useful sequence: choose the composition first, authenticate the bytes second, then activate the components.

The model provider is also a composition choice. Host configuration does not own a global model section. Provider capsules describe the models they can serve, and a registry capsule stores the active model selection per principal. That means two principals can use different providers or models while sharing the same runtime machinery. A model name is not a kernel capability; it is a selection inside a principal-scoped software composition.

The same separation helps with credentials. Provider configuration can be elicited at installation, and secret values are stored through a typed secret path rather than printed in command arguments or ordinary configuration dumps. A provider may discover a live model list during onboarding, but the installer’s ability to reach an endpoint does not automatically give the sandboxed provider unrestricted runtime access. Runtime requests still pass through the capsule’s network declaration and the HTTP airlock.

A defensible installation therefore has three distinct decisions. The operator chooses the composition. The principal receives an identity and state scope. The runtime checks each effect when the installed capsules exercise their capabilities. Signing and onboarding can establish what was selected and what bytes arrived; they do not make every future action permissible.

Let untrusted projects tighten, never widen

Astrid’s layered configuration treats a project directory as an untrusted input. This is a realistic assumption: cloning a hostile repository may also bring a workspace configuration file, and an agent may be asked to operate inside that directory. If the workspace file could add a server, expand a file allow-list, or raise a spending limit, the project would acquire a path to enlarge the authority of the host that opened it.

Astrid reverses that direction. Configuration is merged from defaults, system, user, workspace, and environment layers, but the workspace layer is subject to a hard restriction pass.