Case study: governing agent workloads in sandboxes
BoundaryKit draws on a running local implementation, operated with OpenShell agent sandboxes and Ansible configuration as code. This case study records the operator's experience at a public, abstract level as of 2026-10-03; it is not a hypothetical deployment or a requirement to adopt the same stack. The adoption guide generalizes that experience, while the fictional packet provides a separate teaching example without exposing private configuration. Its NOT RUN labels apply to the fictional tests, not to this local system's operational status.
Operational setup and workload context
An untrusted agent receives an operator-facing task, attached or retrieved context that may contain hostile instructions, and a possible need for tools or a model provider. It may misread the request, follow instructions in content, call the wrong tool, attempt credential access, or reach beyond its approved scope. Approval and policy must come from outside the agent.
The reported hierarchy is generic host → operator-core VM → operator-described logical realms/groupings → individual OpenShell agent sandboxes. A realm in this case study is a workload-grouping term, not a proven OpenShell object, a known gateway mapping, or isolation between workloads. Individual sandboxes are the intended execution boundary; actual properties need tests. No specific agent framework, container engine, OS, hardware, or host layout is inferred for every grouping.
The operator uses Ansible configuration as code for provisioning, maintenance, and recovery workflows. OpenShell supplies the chosen agent-sandbox implementation. These are actual implementation choices, not proposed prerequisites for the framework. Running the system and using repeatable configuration do not, by themselves, establish the result of a specific recovery drill; that result belongs in its own scoped receipt.
Control objectives by boundary
- Operator and promotion: review policy, scopes, approvals, and rollback target before consequential mutations. Stop on missing or invalid policy rather than granting broad fallback access.
- Agent sandbox: keep execution lower trust; constrain tools, files, privileges, and egress at their actual enforcement points. Begin from default-deny network posture and grant only justified routes.
- Tool and data: allowlist task-specific tools, treat tool metadata and returned text as untrusted, refuse unknown/out-of-scope calls, and gate sensitive writes with human authorization.
- Credential and provider: agent-visible configuration carries references rather than raw secret values. A successful governed request, external resolution at the intended mediator, and non-disclosure in agent-visible material would all require separate observations.
- Audit and recovery: record decisions without secret payloads; capture known-good state, rehearse a fault and restore, and repeat authorized and denied checks before stronger claims.
These are framework control objectives, not claims that every control was observed in the reported setup. The adoption guide turns them into stage-specific outputs and deterministic acceptance gates.
Threats the adopter should test
| Threat | Corresponding boundary question |
|---|---|
| Prompt injection in messages or retrieved content | Can content alter policy, reveal hidden context, or initiate an unapproved action? |
| Credential access attempts | Can the agent read raw values from environment, workspace, logs, or mediator? |
| Network exfiltration, DNS, SSRF, or lateral movement | Does the named execution/network boundary refuse each unapproved route? |
| Filesystem/privilege escape | Can the workload read or write outside its approved scope or reach a neighbor? |
| Provider misroute | Does the route stop safely without silently using a different credential path? |
| Configuration drift or failed recovery | Does readback detect divergence, and can an authorized restore repeat the boundary checks? |
Evidence and limits
| Evidence level | What this repository supports | What it does not support |
|---|---|---|
| Operational experience, confirmed by the operator | A running local OpenShell implementation and Ansible-backed workflows | Independent certification, inter-group isolation, exact private gateway mapping, or a measured recovery result |
| Static repo checks | Public documentation and examples are reviewable when checks are run | A sandbox or provider route actually operated |
| Fictional acceptance example | A proposed test and receipt shape | A measured PASS |
| Historical scoped observation | Specific reported earlier refusals at one named boundary or stopped misroute | Neighboring/current boundaries or successful credential resolution |
| Production evidence | Would require real, workload-specific canary, authorization, egress, audit, rollback, and service-objective observations | General safety for every future workload |
Receipt #1 reports refused probes at an earlier inner sandbox under its own negative-test matrix. Receipt #2 reports placeholder configuration and one deliberately broken inference route that stopped, not a successful governed model request or secret resolution. The substrate receipt is fictional, and retired historical acceptance fixtures are not runnable proof. None of these results is transferred to the current reported hierarchy or the worked fictional packet.
A new operator should record workload, version, boundary, test input, and observed result for each probe. Use NOT RUN for an unexecuted test—not as a blanket label for an operating system. The public record does not establish specific recovery, host-containment, provider-mediation, or inter-group-isolation results for the current setup. That limit on test evidence does not negate its operation. The verification model explains the distinction; the threat model supplies a broader attacker/asset review.