Security

Every agent session runs inside a trust boundary: an isolated, ephemeral sandbox holding short-lived credentials scoped to that one job. This page maps the boundary. Sandboxes and Permissions cover the mechanics.

Where code runs

Every session runs in its own sandbox: an isolated Linux machine created for that session, with the session's repositories cloned in, and destroyed when the session finishes.

                 the trust boundary: one session's sandbox
   ┌──────────────────────────────────────────────────────────────┐
   │                                                              │
   │  your code           repositories cloned for this session    │
   │                                                              │
   │  GH_TOKEN            minted for this sandbox alone, lives    │
   │                      1 hour, narrowable to read-only         │
   │                                                              │
   │  sandbox.variables   only the values this agent's config     │
   │                      names; write-only in the store          │
   │                                                              │
   │  model access        a per-session token for reaching        │
   │                      models through Ellipsis; never a real   │
   │                      provider key                            │
   │                                                              │
   └──────────────────────────────────────────────────────────────┘
     destroyed when the session ends; every credential inside
     expires or is revoked with it

     persists outside the boundary: the session timeline, logs,
     costs, the config snapshot, conversation workspace snapshots

Sessions never share a machine, and nothing an agent installs or changes at run time carries into any other session. The one thing reused across sessions is the cached environment image: your repositories plus the setup your config declares. Nothing from a running agent is ever cached. A sandbox lives at most one hour, the same lifetime as its GitHub token, so a session never outlives its credential.

You can open a live sandbox in a browser IDE and preview ports an agent serves. Those URLs are dashboard pages gated on org membership; they grant nothing by possession. Turn them off per agent with ellipsis.ide: false. Full mechanics: Sandboxes.

Credentials

Every credential in a sandbox is scoped and short-lived. Nothing is shared between sessions, and nothing is permanent.

• GitHub. Each sandbox gets its own token (GH_TOKEN), minted from your Ellipsis GitHub App installation when the sandbox starts. It lives one hour, covers only the sandbox's repositories, and dies with the sandbox. YAML narrows it per agent, down to read-only. The narrowed token is minted by GitHub with the reduced scope, so nothing running in the sandbox can exceed it: not a misbehaving tool, and not a prompt injection hiding in a pull request. No personal credential is ever involved.
• Your secrets. Values you store as sandbox variables enter only the sandboxes of agents whose config names them. Stored values are write-only: injected into sandboxes, never readable back through the dashboard, API, or CLI, which list names and timestamps only. Injected values die with the sandbox.
• Model keys. A real provider key never enters a sandbox; see Model providers.

Session logs are not redacted: they record what your setup scripts and the agent print, readable by your account. Keep scripts from echoing secret values. Transcripts synced from developer laptops are the exception: those are redacted on the laptop before upload.

Data retention

The sandbox is ephemeral; the session's record is not. After every session, Ellipsis keeps:

• The session timeline: every step, tool call, and message, with token usage and cost per step, searchable from the dashboard and the API.
• The downloadable session log and a snapshot of the exact config the session ran.
• For conversations, the conversation state and a workspace snapshot taken when the conversation goes idle, so the next message resumes with the working tree intact.
• Model call records, which power replay and the per-step cost breakdown.
• The cached environment image: your repositories at the built commit plus your setup output, reused so the next session starts warm.

Transcripts are kept indefinitely by default. To age them out, an organization admin sets Transcript retention on the Sessions page's Settings tab, from 7 to 365 days. Transcripts older than the window are deleted: the step records behind search, the stored session logs, and transcripts synced from laptops. The sessions themselves stay listed with their recap and cost.

Model providers

Agents reach models through Ellipsis: the sandbox holds a per-session token, Ellipsis attaches the real credential server-side, and the prompt goes to whichever provider your Models choice names.

What each choice stores:

• Ellipsis-managed needs no setup and stores no credential of yours.
• Your Anthropic key is stored write-only: no API response or dashboard surface ever returns it (the card shows the last 4 characters), and it never enters a sandbox.
• Your Bedrock stores a role ARN and an external ID, neither of which is a secret. Ellipsis assumes the IAM role you create, scoped to model invocation, using short-lived credentials that live only in memory; the role sessions Ellipsis opens are visible in your CloudTrail.
• Your own proxy must be HTTPS on a publicly routable address. Its credential is stored write-only and attached server-side, never inside the sandbox. Unlike the other choices, agents opt in per agent by naming the proxy in their config.

Whichever provider serves completions, token-count calls (a metadata call that includes the prompt) go to the Anthropic API on an Ellipsis key.