Case Study: Governing an OpenShell/Hermes Agent Workload

This case study is a sanitized public walkthrough for reading the BoundaryKit Agent VM architecture. It is not a product claim, customer deployment claim, live topology map, or proof that a production workload is ready.

Scenario

An AI-agent workload receives approved input from an operator-facing workflow:

1. a message or task request;
2. attached or retrieved context that may contain hostile instructions;
3. a need to call tools or a model provider to complete the task.

The workload is treated as a probabilistic actor. It may misread the request, follow malicious instructions in content, invoke the wrong tool, attempt credential access, or try to reach data beyond the approved scope.

The public architecture places that workload inside an OpenShell sandbox running Hermes Agent, with rootless Podman runtime posture, a managed provider boundary, and evidence receipts for measured behavior.

Control path

operator intent
  -> policy and promotion boundary
  -> OpenShell sandbox running Hermes Agent
  -> rootless Podman runtime posture
  -> managed provider boundary
  -> NUC-class VM substrate
  -> public receipts and recovery expectations

Risks addressed

• Prompt injection: task content instructs the agent to ignore policy or reveal hidden context.
• Credential access attempts: the agent asks for environment variables, key material, provider tokens, or raw secret values.
• Network exfiltration: the agent tries direct outbound access, DNS exfiltration, SSRF, or lateral movement.
• Filesystem escape: the agent attempts to read or write outside the approved sandbox scope.
• Provider misroute: model/tool-provider access breaks or points to an unapproved path.
• Runtime drift: public claims no longer match what was measured.

Expected controls

1. Policy and promotion boundary
2. Changes are reviewed before stronger claims are made.
3. Missing policy follows a fail-closed posture.

4. Rollback and recovery expectations include a named rollback target before stronger claims are made.

5. OpenShell sandbox boundary

6. Agent execution is treated as lower trust.
7. Tool, file, and network behavior are constrained.
8. Default-deny egress is the starting posture; allowed provider paths are explicit exceptions.

9. Negative tests record denied crossing attempts.

10. Rootless runtime posture

11. The public case study favors rootless Podman.

12. A privileged Docker daemon or broad host socket is not part of the public runtime claim.

13. Managed provider boundary

14. The sandbox sees a placeholder or reference, not raw provider credentials.
15. Secrets-by-reference is the public rule; raw provider tokens never enter public examples or receipts.
16. Credentials resolve outside the sandbox boundary.

17. Broken provider routing fails closed.

18. Evidence receipts

19. Each measured boundary has a public-safe summary.
20. Each receipt includes non-claims.
21. Private logs, hostnames, IPs, VM names, ports, routes, key names, and incident details stay out of public docs.

Public evidence level

Current public receipts

• Boundary receipt #1 - inner sandbox summarizes refused egress, SSRF, lateral movement, external DNS, read-only filesystem, and non-root checks.
• Boundary receipt #2 - inference boundary summarizes placeholder-in-sandbox credentials and fail-closed behavior on the governed model path.

Reviewer takeaway

Read this as an operating model:

autonomous agent workloads are treated as untrusted, their authority is mediated by policy, provider access is kept outside the sandbox boundary, claims are tied to evidence, and rollback remains part of the definition of done.

Read this alongside ../verification.html, ../threat-model.html, boundary-receipt-01-inner-sandbox.html, and boundary-receipt-02-inference-boundary.html.