Sandbox isolation

Running code on behalf of an agent is the highest-trust operation the platform performs, so it is the most contained. Execution happens inside a sandbox operated by a managed provider, separated from the application that serves the product and from every other customer. The shell, the bundled engineering tools, the lifecycle states, and the VNC pipeline are documented in the Workspace section of the docs; this page is the isolation, data-handling, and monitoring summary for reviewers, and it states the guarantees in the terms a security questionnaire asks for.

• One sandbox per session. A sandbox belongs to a single workspace session and is not shared across customers.
• Separated from the app tier. Code in the sandbox runs on the provider's isolated infrastructure, not on the servers that host the application or the database.
• No cross-tenant reach. A sandbox cannot read another customer's sandbox, workspace, or data.
• No standing database access. The application database is not reachable from inside the sandbox; the sandbox works with the files and inputs placed into it for the task.
• No ambient production secrets. The sandbox is not provisioned with the platform's production secrets.

A sandbox is provisioned when a session needs one, becomes ready, runs work, and goes idle between turns. It can be snapshotted so a later turn restores the same state, which is how long-running engineering work survives a pause. When a session is retired, the sandbox is reclaimed. The complete set of states is documented under Workspace in the docs.

Only the inputs a task needs enter the sandbox: the files, content, and instructions for the work at hand. Sandbox state is ephemeral and is reclaimed when the session retires; the sandbox is not a long-term store of personal data. Anything you want to keep is written back to your workspace explicitly. Customer Personal Data that passes through the sandbox is processed under the Data Processing Addendum, with the sandbox provider acting as a subprocessor, and is subject to the same no-training position as the rest of the platform.

Where a task needs to authenticate to a connected third-party tool, credentials are made available to the running step in a scoped form for the duration of the work and are not written into the sandbox as durable, recoverable secrets that outlive the session. The platform's own production secrets are held in a managed secret store outside the sandbox and are never injected into it. When the sandbox is reclaimed, any ephemeral credential material in it is gone with the rest of the state.

A sandbox can reach the network to do legitimate work, such as installing a package or calling an API a task requires. Outbound activity is bounded by the task and is subject to the same logging and anomaly detection that covers the rest of the platform, including monitoring of unusual data volumes leaving the environment. The sandbox is not exposed as a public inbound service; access to it is mediated by the platform. The controls behind this are summarised on the Security page.

Code that runs in the sandbox originates either from the agent, as part of completing a task, or from you, when you drive the shell directly. In both cases it runs inside the isolation boundary described above and has no path to the application tier or to other tenants. Work the agent performs that would have external effect, such as deploying or publishing, is subject to the human approval gate described under Automated decisions and human oversight; the sandbox itself does not push changes to production systems on its own authority.

Sandboxes run under resource limits, and the platform operates a janitor that reclaims idle and runaway sandboxes so a single session cannot consume resources indefinitely. Usage is metered, and abnormal consumption is an anomaly signal. The reconciler and janitor that maintain this are documented in the Background Jobs section of the docs.

You reach your own sandbox through the product, including the VNC pipeline that streams the desktop view, documented under Workspace. Ultron personnel do not have standing access to the contents of a customer sandbox. Access for incident response is least-privilege, time-boxed, and logged, as described on the Security page. No customer can reach another customer's sandbox by any supported path.

Sandbox provisioning, run activity, and reclamation are recorded, and administrative access to sandbox infrastructure is logged with the actor, the action, and a timestamp. Network egress is covered by the platform's volume-anomaly monitoring. Alerts page an on-call engineer for events above a low severity threshold. The logging and retention details are on the Security page and the Privacy Policy.

When a session retires, its sandbox is reclaimed and its ephemeral state is destroyed. Data you wrote back to your workspace persists as content and follows the content retention windows in the Privacy Policy, persisting until you delete it and then rolling out of backups within thirty days. Because the sandbox is not a durable store, there is no separate long-lived copy of sandbox state to delete after reclamation.

The sandbox runs on a managed provider whose identity, location, and role are recorded on the Subprocessors page. The provider is engaged under data protection terms compatible with the GDPR and is reviewed before onboarding and at least annually thereafter, as described under Supplier risk on the Security page.

If you are completing a security review, the questions this page is designed to answer are: where does code execute, how are tenants isolated, can the sandbox reach the application database or other customers, how is outbound traffic bounded and monitored, how are credentials handled, what is the lifecycle and how is state destroyed, and who at Ultron can access a sandbox. For anything not covered here, or for a completed questionnaire, write to security@51ultron.com.

Security reviewers with questions about the sandbox should write to security@51ultron.com. The provider that runs the sandbox is on the Subprocessors page, the technical and organisational measures are on the Security page, and the engineering detail is in the Workspace section of the docs.