Vendor-neutral adoption framework · untrusted agents · evidence gates

Govern untrusted AI-agent workloads with boundaries you can verify.

BoundaryKit is a vendor-neutral framework informed by a running local implementation of agent sandboxes, using OpenShell and Ansible configuration as code. It turns that operational experience into a guide for choosing trust boundaries, limiting tools and data access, grouping workloads, and testing recovery. You can follow the method with other tools.

Start the adoption guide Explore the worked example

Historical project credits: NVIDIA OpenShell Hermes Agent rootless Podman NUC-class hardware NemoClaw blueprint

Host Operator-core VM Logical workload groups Agent sandboxes

adoption stages fictional example evidence scope

trust boundaries assume agents are untrusted

Identify higher-trust operators, execution boundaries, data paths, and the evidence needed for each claim.

capability selection grant only reviewed tools

Choose tools and egress per workload; require explicit approval and observable denials for unwanted paths.

recovery gate prove before promotion

Represent intended configuration as code, then test rollback and recovery rather than inferring proof from files.

what it is

A sequence of adoption decisions, not a required stack.

Start with a trust-boundary map and tool inventory. Select an isolation substrate and policy for each workload, then group workloads for ownership and policy review. A logical group is not automatically a security boundary. Capture decisions, expected denials, and pass/fail evidence in the adoption guide.

The operator runs OpenShell agent sandboxes under an operator-core VM, organized into logical workload groups and managed with Ansible configuration as code. The diagram abstracts that operational setup. The separate fictional walkthrough teaches the method: its NOT RUN labels describe unexecuted example tests, not whether the real system is running.

adoption decisions

From trust model to evidence-backed operation.

Map trust boundaries

Classify agent input, state, operator privileges, and external systems before choosing a runtime.

Select tool and data gates

Define allowed tools, secrets-by-reference, egress scope, and negative tests for each workload.

Group workloads deliberately

Separate ownership, policy, and state according to risk. Verify any claimed isolation; grouping is only organization.

Codify and recover

Review configuration changes, collect scoped receipts, and require a rollback drill before promotion.

framework stages

Five decisions, each with a checkable output.

Trust boundaries

Map untrusted inputs, execution, operator authority, state, and external connections.

boundary map and asset inventory
explicit higher-trust domains
reviewed threat assumptions

Tools and substrate

Choose runtime controls by workload need, then test the intended allowed and denied paths.

minimal capability contract
secret and egress policy
scoped negative-test evidence

Workload grouping

Organize ownership, policy, and state; name the actual enforcement boundary separately from the group.

workload-to-policy mapping
no inferred group isolation
vendor adapter reviewed locally

04–05

Configuration and recovery

Review declarative intent, then observe rollback and recovery before making a promotion claim.

configuration-as-code review
recovery drill receipt
explicit pass/fail decision

claim discipline

Evidence must match the boundary and version claimed.

The adoption framework requires scoped tests and an observed recovery drill before promotion. Historical public receipts summarize earlier sandbox and inference-path attempts; neither measures current group-to-group isolation, proves present recovery, or certifies a new adopter's deployment.

Running locally · operator-confirmed experience

🖥️ The operator runs a local host/VM setup with individual OpenShell agent sandboxes.
📦 “Realm” names an operator logical workload grouping here, not an asserted OpenShell isolation primitive or proven gateway mapping.
🔒 Ansible configuration as code supports provisioning, maintenance, and recovery workflows. A specific recovery drill has its own result.

Historical · scoped boundary summaries

🛡️ Inner sandbox receipt: particular egress, SSRF, lateral-movement, DNS, filesystem, and non-root probes.
🔐 Inference receipt: placeholder configuration and one fail-closed misroute; successful governed credential resolution is not established.

The local implementation is operational. The fictional walkthrough's unexecuted tests are separate; specific security and recovery claims remain tied to scoped evidence.

Read boundary receipt #1 → Read boundary receipt #2 →

grounded in primary research

Aligned with published sandboxing and isolation patterns.

Anthropic

Dual-Isolation Thesis

"Without network isolation, a compromised agent could exfiltrate sensitive files; without filesystem isolation, it could escape the sandbox."

Filesystem containment and default-deny egress are design objectives for sandboxed workloads, not evidence that the reported realms have passed independent isolation testing.

Anthropic Engineering (2025) →

Google

Host Defense Architecture

"By intercepting all sandboxed application system calls to the kernel, it protects the host from the application."

A sandbox implementation should treat tool actions as boundary-crossing events and retain host protection as a distinct design concern; this citation is not proof of any BoundaryKit deployment.

Google gVisor Platform →

AWS

Minimal Attack Surface

"A minimal device model that excludes all non-essential functionality and reduces the attack surface."

VM containment is a design backstop distinct from sandbox policy; this citation is not a measurement of the current operator-core VM.

AWS Firecracker microVM →

illustrative workload categories

Categories are examples, not live inventory.

Illustrative A

Persistent agent workload

A long-running agent is one possible workload category. Its sandbox policy and state boundaries require workload-specific review, not an inference from realm grouping.

Illustrative B

Ephemeral task workload

Short-lived processing is another possible category. No active lab, teardown validation, or live workload inventory is implied by this example.

adopt, then review the case study

Start with the framework and a fictional walkthrough.

Adoption guide — start here Fictional worked example — follow the stages Documentation index 00 — Overview 01 — Historical substrate lesson (non-runnable) 02 — Historical promotion design lesson (non-runnable) 03 — Historical gateway lesson (non-runnable) 04 — Governance and claim discipline 05 — Gated preview access Security methodology Threat model Verification model Governed workload case study Illustrative historical substrate receipt (not measured) Historical scoped receipt #1 — inner sandbox Historical scoped receipt #2 — inference boundary