Architecture overview
BoundaryKit draws on a running local agent-sandbox implementation and treats each agent as an untrusted, tool-wielding workload. A prompt, retrieved document, tool response, package, or model output may redirect it. The adoption guide generalizes the method: map crossings, limit capabilities, select enforcement separately from administrative grouping, version desired state without secrets, and measure recovery. The fictional worked packet is a teaching example; its unexecuted test statuses do not describe the operational local system. No vendor, host type, or automation tool is required by the method.
Trust model, not a product topology
A usable implementation distinguishes these responsibilities:
- Operator/control zone: people and policy/configuration machinery authorize change and retain the previous known-good state. An agent cannot promote its own privileges or approve its own output.
- Logical workload grouping: ownership, review queue, lifecycle, or policy administration can group several workloads. A group label—whether called a realm, project, or tenant—does not itself enforce process, filesystem, network, or secret isolation.
- Execution boundary: a selected sandbox, VM, or other tested mechanism constrains each untrusted workload. Its actual guarantees depend on configuration and negative probes at that boundary, not its name.
- Data, tool, and provider boundaries: allowlisted tools and egress routes serve approved operations; separate identities and mediators hold credentials. Descriptions, arguments, responses, and retrieved data remain untrusted.
- Audit and recovery boundary: record scoped decisions without secrets; compare observed state to reviewed state; restore a captured known-good target and rerun the same checks before a recovery or promotion claim.
The five packet outputs assign an authority, mechanism, and falsifying observation to each intended crossing. A successful test at one boundary says nothing about a neighboring boundary.
The running local implementation
The operator confirms a running local setup using a generic host, an operator-core VM, logical realms/workload groups, and individual OpenShell agent sandboxes, with Ansible configuration as code. This public account was recorded 2026-10-03. The diagram abstracts that implementation without exposing live inventory or private gateway-to-group mappings; it is not a claim that each depicted boundary has been independently tested.
Figure: an illustrative hierarchy only. Policy/promotion govern change, while Ansible is the reported configuration-as-code choice for repeatable provisioning, maintenance, and recovery workflows. Neither a grouping label nor configuration-as-code use proves runtime isolation or a successful recovery.
| Layer or responsibility | Reported role | Limit of the public claim |
|---|---|---|
| Generic host | Substrate outside the workload | No published host/hypervisor containment measurement |
| Operator-core VM | Operator-controlled environment | A reported VM, not a measured outer boundary |
| Operator-described realms | Logical workload groupings | Not asserted to be OpenShell objects, enforced isolation boundaries, or a particular gateway mapping |
| Individual OpenShell sandboxes | Intended execution boundary for untrusted agents | Historical receipt #1 covers one earlier inner sandbox, not this hierarchy's current behavior |
| Operator policy/provider objectives | Tool, credential, and promotion decisions | Historical receipt #2 covers a placeholder and one stopped misroute, not successful credential mediation |
| Ansible configuration as code | Reported provisioning, maintenance, and recovery repeatability | Not a recovery drill or readback proof |
OpenShell documentation describes a gateway control plane managing sandbox lifecycle/state and a sandbox data plane with local enforcement. That vendor terminology must not be silently equated to the operator's realm grouping. A proposed adapter may use one or more gateways according to the chosen product version/configuration; the actual topology and enforcement must be verified locally before a corresponding claim. This public narrative does not reveal or infer the operator's exact mapping. See OpenShell architecture and how it works for vendor-specific terminology, not a BoundaryKit requirement.
Hermes Agent, rootless Podman, and NVIDIA NemoClaw are credited in historical workload/runtime and blueprint context, not inferred for every current grouping. Product names here identify examples, not endorsements or mandatory dependencies.
Evidence limits
Receipt #1 reports historical refusals at a defined earlier inner sandbox. Receipt #2 reports a placeholder in sandbox configuration/environment and one stopped deliberate misroute; it does not demonstrate a successful governed model request or credential resolution at the mediating boundary. Neither receipt retests the reported hierarchy.
The substrate receipt is fictional illustrative acceptance material. Isolation substrate and gateway runtime layout preserve historical design lessons without a maintained runnable lab. Production readiness, host containment, inter-group isolation, and successful recovery each require separate workload- and version-specific observations. The verification model defines the claim vocabulary.