Answers, with the limits attached.

Security and data

Each answer names a mechanism rather than an intention, and each limit is stated beside the thing it limits.

Where do the credentials live, and who can read them?

An Environment holds the machine's own variables and a Vault holds a small bag of overrides for one run. The name collides with HashiCorp's and means close to the opposite here. A Vault is a per-run override layer rather than a central store. Both are encrypted at rest with AES-256-GCM under a key derived for your account alone. Values are write-only. No endpoint returns one, to anybody, including an operator.

Deleting your account destroys that key with it, so what any backup still holds is unreadable rather than merely deleted.

Does the model ever see them?

No. Secrets merge into the sandbox's process environment when it spawns, and reach an agent's configuration through ${VAR} substitution. Nothing puts them in the prompt, the system prompt or the model's context.

An agent that reads its own environment and says the value out loud has said it. The next answer is what happens to that line.

What ends up in your logs?

Every secret value you registered that is eight bytes or longer is replaced with [REDACTED] before the log line is written, not after. The transcript we store never held it.

The match is on exact bytes. A value the agent re-encodes, splits or prints in pieces is not caught, and neither is one shorter than eight bytes.

Can one account's agent reach another's?

Every user-facing query is scoped by account. The few unscoped internal reads carry an _unsafe_ prefix so a reviewer can grep for all of them in one command, and a cross-tenant isolation suite in CI asserts the scoped endpoints answer 404 on another account's data.

What is recorded when something changes, and for how long?

The event is written where the change happens rather than where the request arrived, so the console, the API and a background worker are covered by one rule. An update names the fields that moved and never their values; a secret event records the key, the size and the provider. Read your own trail at GET /api/audit, filtered by action, resource or time.

Conversation log events are kept 90 days, audit events a year, usage 400 days. On your own instance every window is a setting.

Can the agent do something nobody approved?

Set an agent's permission policy to ask and a tool call stops for a human before it runs, not after. The stronger pattern is the one the case study uses. Build the last gate somewhere the agent cannot reach, so refusing is somebody else's job rather than the model's.

Asking is not the default, and it is not universal. claude, codex and gemini enforce it. opencode cannot, and refuses anything stricter than auto-allow with a 422 rather than pretending to hold the line.

What if none of this may leave our network?

Run the server yourself, or keep the platform and put the sandboxes on your own hardware with a runner. Either way the code and the secrets stay inside your perimeter.

Read the runner's trust model first. It runs in trusted mode, the agent's processes run as the daemon's user, and no container or VM stands between them. An opt-in Firecracker backend exists and is not the default.