Security & Data Flows

Agent isolation and secrets

Why the agent process never holds a real credential, and how stored secrets are handled.

Agent isolation

The agent that implements a ticket runs in its own sandboxed process, separate from the web app, the worker, and everything under /data.

What it can reach: the ticket's own worktree, a working copy of your repository, and nothing else.

What it cannot reach: /data (the state database, encrypted secrets, license token), your git remote's credentials, or the real value of your model-provider key. None of these are readable from inside the sandbox, regardless of what a ticket's text asks for.

Model calls go through a local gateway, not directly to the provider. The agent's own environment only ever contains a short-lived, per-job token for that gateway. The gateway itself holds the real key and injects it. Capture everything the agent's process can see, and you still won't find your Anthropic key in it.

Git operations are done by the orchestrator, not the agent. Pushes, opening a PR, and writing back to a connected tracker all happen outside the sandbox. Even a ticket engineered to talk the agent into pushing somewhere it shouldn't has no credential available to do it with.

Secrets

Every secret you give it (a model-provider key, git credentials, a notifier token) is write-only through the dashboard. Paste it in once; from then on you can replace it or remove it, but never read it back out, including as an Owner.

  • Stored encrypted at rest (AES-GCM).
  • Redacted everywhere a run might otherwise surface it: logs, the live run view, the audit log, and any diagnostics bundle you'd send to support.
  • Shown in Settings only as •••• plus the last four characters, next to Replace and Remove.