Examples & Integrations

How to read these examples

Each integration shows the same execution-layer pattern in a different runtime: install the agentsh binary, start a supervised session, attach policy, and run agent commands through the enforcing shell. The provider changes, but the security contract stays the same. File reads, writes, command execution, subprocesses, network egress, package installs, and sensitive output all flow through deterministic policy before the model or tool receives the result.

What the repositories demonstrate

The sandbox examples cover Firecracker microVMs, gVisor-backed environments, hosted devboxes, and provider-specific container APIs. They are useful when you need a concrete starting point for wrapping a hosted AI sandbox, proving that credential paths are denied, restricting package installation, or collecting an audit trail that survives prompt injection attempts. The MCP and framework demos show the same boundary applied to tool calls and agent frameworks instead of only raw shell commands.

Choosing a starting point

Start with the provider that matches your deployment target. Use the Secure Sandbox SDK when you want a TypeScript or Python wrapper around Vercel, E2B, Daytona, Cloudflare, Blaxel, Sprites, Modal, Runloop, exe.dev, or Freestyle. Use the lower-level agentsh examples when you want to inspect policy files, session setup, daemon behavior, or the exact audit events generated by an enforced run. For terminology used across the examples, see the Glossary.

What to verify after cloning

After cloning an example, run the normal allowed command first so you can see the baseline session lifecycle. Then try a denied file read such as an SSH key path, an unapproved outbound request, and a package install that should require policy. The important output is not only the terminal denial; it is the session report showing the operation, rule match, decision, and process tree. That is the evidence you can carry into CI, demos, security reviews, and production rollout planning.

How the examples fit together

The provider repositories show deployment mechanics. The Secure Sandbox page shows the SDK abstraction for applications that need one interface across providers. The MCP demo shows how the same enforcement model applies when an agent reaches tools through a protocol boundary. The mitigation demos show low-level controls closing specific exploit setup paths. Read together, they show agentsh as a runtime boundary rather than a single provider integration: policy follows the untrusted process wherever the agent runs.

Production rollout path

A typical rollout starts in observe mode, where agentsh records the file, command, and network activity a known-good agent workflow needs. Convert that profile into explicit allow rules, rerun the example in warn mode to find missing allowances, and then switch to enforce mode once the policy covers the expected path. The examples are intentionally small so you can see each stage clearly: setup, policy attachment, allowed operation, denied operation, and final report. That sequence is the same pattern you use when moving from a demo sandbox to a real coding agent, CI worker, or hosted agent runtime. The goal is to make the enforcement boundary observable before it becomes part of a larger application, and to keep the policy decisions easy to compare across providers.