RayTrace

SECURITY & ISOLATION

Your agent gets a sandbox.
Not your machine.

RayTrace runs coding agents in isolated cloud sandboxes, records what they actually do, and keeps each project separate from every other project. This page explains the boundaries in plain language — what is separated, what is restricted, and where the honest limits are.

Separate sandboxEvery project runs in its own isolated workspace
No provider key insideModel calls use RayTrace’s controlled bridge
Observed evidenceKept separate from what the agent reports

THE SHORT VERSION

Built for code you have not reviewed yet.

A coding agent can write files, run commands, install packages and call tools. RayTrace assumes that work should happen somewhere disposable and observable — not directly against your laptop, your credentials, or a production system.

Each sandbox is a separate gVisor-isolated container with its own workspace and home storage. One sandbox cannot browse another sandbox’s project. Sandboxes run as a non-root user with Linux capabilities dropped, resource limits applied, and network access restricted so private addresses are refused.

HOW ISOLATION WORKS

Several boundaries, not one promise.

A separate execution boundary

Every sandbox runs under gVisor, which places a user-space kernel between the agent’s processes and the host. That is a stronger boundary than an ordinary container sharing the host kernel directly.

Private project storage

Each sandbox gets its own workspace and home volumes. Other sandboxes’ volumes are not mounted, so an agent cannot wander into a neighbouring project’s files.

Least privilege by default

Sandbox processes run as a non-root user, with all Linux capabilities dropped and privilege escalation disabled. CPU, memory and process-count limits keep one run from consuming the whole machine.

A narrower network

Sandboxes can reach the public internet for package installs and documentation, but connections to private addresses are refused. That protects internal services and cloud metadata from code running inside a sandbox.

BEFORE ANYTHING IS UPLOADED

You see the boundary before you cross it.

Creating a sandbox uploads a copy of your project. Common secret-bearing files are excluded before upload — including environment files, private keys and common credential files — and the same screening is repeated on RayTrace’s side. The browser flow shows what would be uploaded before anything is sent.

No sandbox writes back to your computer automatically. When you destroy a sandbox, its files and any agent sign-in made inside it are deleted; the recorded session evidence is kept for your organization.

Review your project before uploading. Automated exclusions cannot detect a secret pasted directly into an ordinary source file.

FILES THAT DESERVE A SECOND LOOK

Risky files are flagged before the agent touches them.

Every uploaded project gets an initial scan that classifies files from “Ignore” to “Lock down,” based on how widely a file is used and how sensitive its contents are. Migrations, deployment configuration, credential-handling code and destructive database operations sit at the top.

You can mark any file to be reported when it changes, or restricted so the agent may not change it. Restricted files are enforced in the sandbox, not merely labelled in the dashboard — and a kernel-level record shows attempts as well as completed changes.

EVIDENCE, NOT JUST CLAIMS

What the agent says is kept separate from what was observed.

An agent’s transcript can say a command succeeded. RayTrace also records independently observed execution evidence from the sandbox, so reported results and observed results can be compared instead of blended into one story.

That separation matters when something looks wrong: a successful shell exit does not prove every command inside it succeeded, and a polished summary does not prove the work was done correctly. RayTrace does not reconstruct a model’s private chain of thought; it shows the requests, tool calls and execution evidence that can actually be checked.

MODEL ACCESS

Your provider key does not live in the sandbox.

Claude Code and Codex can run on RayTrace’s central model access through a controlled bridge, using a revocable per-sandbox token rather than your provider API key. Usage is metered against your plan, and access can be revoked without rotating your own credentials.

You can also sign in inside a sandbox with your own agent account. That sign-in stays in the sandbox’s private home storage and is deleted when the sandbox is destroyed.

THE HONEST BOUNDARY

Shared infrastructure, isolated sandboxes.

RayTrace sandboxes are isolated containers on shared infrastructure; they are not a separate physical machine per customer. That is a deliberate trade-off: strong sandbox isolation without making every run wait for a dedicated machine to be provisioned. Platform operators run the service and can administer the infrastructure, so RayTrace is not a zero-access vault for data you would never entrust to a cloud provider.

If your organization needs dedicated infrastructure or a specific compliance review, talk to us through the Team & Enterprise query form. We would rather describe the boundary accurately than oversell it.

Read the detailed privacy and release scope →