# AgentTwin execution boundaries and controls

AgentTwin tests prepared Node.js application and AI-agent workflows against synthetic service state. The runtime target determines what the execution boundary protects and what it does not.

## Direct local execution

Direct `npx agenttwin run` execution runs on the host by default and can access the host filesystem and network. It is not a security sandbox or a production isolation boundary.

## Local Docker

`npx agenttwin test` and `run --runtime docker` use a restricted local container for reviewed Node HTTP and tagged-SQL PostgreSQL tests, with network disabled. They require a local Unix-socket Docker engine and installed images. This is not arbitrary SDK or ORM compatibility.

## API-managed E2B

An API-managed cloud run uses a fresh E2B sandbox, an account, configured infrastructure and quotas. It requests deny-all egress and installs a guest IPv4/IPv6 firewall that allows only loopback and established control-plane replies; the run aborts if the firewall cannot be installed. Application code runs as the non-root `node` user.

Each sandbox is created for one run. Termination is attempted after success, failure or cancellation. Cleanup can fail; configured expiry is the backstop. The receipt records whether cleanup could not be confirmed.

## Customer E2B

A customer-configured E2B runtime requires your own credentials, template and provider billing.

## What enters and leaves an E2B run

Only explicitly listed application files and the world specification enter the run. Common credential paths, symlinks and path traversal are rejected. Synthetic, run-scoped service and database credentials are generated for the run; host environment variables are not forwarded.

Receipts record declared outcomes, observed operations, assertion results and captured initial and final state. A passing result verifies those checks against supported behavior; it does not prove complete provider fidelity or production equivalence.

## Source handling and retained receipts

Staged source and sandbox contents are not retained for automatic recovery. The control plane necessarily receives staged files while preparing a cloud run and deletes its staging workspace afterward. Synthetic run credentials expire with the run.

Run receipts are retained in the account so developers can inspect failures and compare later runs. Entries older than 30 days are pruned when the gateway starts or accepts a new run, not on a scheduled deletion deadline. Up to 1,000 receipts are retained per account. Revoking an account blocks new runs but does not erase existing receipts.

Read the [trust posture](https://github.com/Sashank-Singh/AgentTwin/blob/main/docs/TRUST-POSTURE.md), [execution limits](https://agenttwin.si/docs/safety/) and [evidence guide](https://agenttwin.si/docs/evidence/). Review application output, fixtures and receipts before sharing them.

## Not available today

- **SOC 2:** no certification, report or audit period. No compliance claim is made.
- **BYOC / VPC execution:** running inside a customer cloud estate is not implemented.
- **Organization roles and managed SSO:** organization-scoped RBAC, directory sync and centrally managed SSO are not implemented.
- **Audit logs:** no exportable, tamper-evident account or run audit trail is currently offered.

## Start with one bounded workflow

Bring a workflow with a supported invocation and an outcome you can describe. [Set up the project](https://agenttwin.si/docs/quickstart/), or [discuss the execution boundary](https://agenttwin.si/contact/) before preparing a test.

[See how AgentTwin is used and what it does not cover](https://agenttwin.si/what-is-agenttwin/).