Security

Agents run code, reach the network, and use credentials on your behalf. This page describes the boundaries that contain them, what you control, and what your agents can and can’t see.

​

Organization isolation

• Every agent, environment, session, vault, skill, tag, and integration connection belongs to exactly one organization.
• Each request runs in one organization, chosen by your API key’s scope or the x-organization-id header, and is checked against your membership on every request.
• A resource in an organization you can’t reach returns 404 not_found, the same as one that doesn’t exist, so its existence isn’t revealed.
• Your role is checked for every operation. A read-only role can’t create, change, or delete anything. See Organizations and roles.

​

Authentication

• API keys are personal, act with your current role, and always expire, after 365 days at most.
• The full key is shown once and can’t be retrieved later. Revoking a key takes effect immediately.
• If you’re removed from the tenant, or a key’s organization is archived, the key stops working.
• API keys can’t create or revoke API keys or buy credits. Those are console actions that need a signed-in session.

See API keys.

​

Sandbox isolation

• One sandbox per session tree. A root session and its child sessions share one sandbox. Other sessions can’t see into it.
• Setup tests carry no credentials. A setup test runs without any session’s credentials. When a session runs setup on its own compute, environment-variable secrets are removed from the script’s shell, but a program the script starts can still read them. Only use setup scripts you trust.
• No privileged containers by default. Privileged Docker access is off unless you turn it on for an environment.
• Sandboxes don’t live forever. A hard stop tears the sandbox down. An idle sandbox stops after the environment’s idle period, and a stopped one is deleted after its retention period.

​

Network access

New environments have no internet access unless you allow it:

• In the console, Internet access defaults to No access. Enabled allows unrestricted access.
• In the API, omitting network_policy stores a deny-all policy. Send {} for unrestricted access, or up to 200 ordered rules to allow specific destinations.

Changing a stored network policy, or turning on privileged access, requires expected_access from your latest read, so two people can’t silently overwrite each other’s access settings. Grant only the destinations the task needs. See Environment reference.

​

Credentials

Credentials live in vaults, and secret values are write-only. The API and the console show how a credential is stored, never its value. Stored secrets are encrypted at rest with a key specific to your organization. What reaches the agent depends on the credential type: You control what each session gets:

• An agent’s default vaults apply to its sessions. A session can replace them, or narrow them to specific credentials with credential_refs.
• A subagent that’s a different agent from the roster gets only its own default vaults, never its parent’s. To share a credential, grant the same vault to both. See Multi-agent.
• Environment-variable secrets are the exception. They come only from the vaults granted to the root session, and every agent in the session tree, including roster agents, can read them, because the tree shares one sandbox.

​

Integrations

Built-in integrations don’t use vaults. An admin signs in to each app once on the Integrations page, and that sign-in is never returned by the API or shown in the console.

• Scoped by the allow-list. An agent reaches only the apps it’s granted, and only the tools on each app’s allow-list. Read-only tools can’t change data; write and destructive tools can, so add them only when a task needs them.
• Short-lived access in the sandbox. A session gets access that works only for its granted apps and allowed tools, and expires within an hour. It’s renewed while the session runs. Commands in the sandbox can use it, so an agent could read it, but it’s no use outside that scope or after it expires.
• Acts as one account. Agents act in the app as the account that signed in. Choose an account whose own permissions fit the work.
• Stops when you disconnect. Disconnecting removes the app’s sign-in, and no session gets new access through it. Access already issued lasts at most until it expires.

Native integrations such as GitHub, Slack, and Jira work the same way: each session gets a short-lived token limited to the access level and resources you granted, and the connection’s own permissions are the ceiling. For GitHub, git gets the token through a credential helper that refuses repositories outside the grant, and gh gets it only for the command being run; the model never receives it in its context. See GitHub access. See Integrations.

​

Automations and event sources

• Deliveries are verified. Slack, GitHub, and signed custom webhook sources check every delivery’s signature against a Webhook signing secret in a vault. That secret is used only to verify deliveries and never reaches a sandbox. An unsigned custom source accepts any request that reaches its URL, so use one only for data that’s safe to act on.
• Event data is input, not instructions you wrote. An event run’s opening message includes the event as JSON after your prompt. Treat event text, such as a Slack message or an issue body, as untrusted, and grant automation sessions only what their task needs.
• Runs are recorded. Every run keeps its frozen configuration, trigger, event, and opening message, including after the automation is deleted.

​

Data handling

• Sessions keep their history. Transcripts, events, sandbox state, and outputs are kept on the server so sessions can resume. Session messages and events are encrypted at rest with your organization’s key. Because of this server-side state, Managed Agents can’t be used for workloads that require Zero Data Retention or HIPAA BAA coverage; see the notice on the overview.
• Files. Uploads and session deliverables stay in your organization’s library until you delete them or an upload’s expiry passes. A deleted file stops being listed and served at once, and its stored content is removed after a grace period. Sessions that attached it before the delete can still receive it until then. See Files.
• Memory. Learned memory contains what agents learned from your sessions. Every memory change is kept as a version for 30 days, and recent versions of live memories are kept regardless of age. To remove sensitive text for good, write a clean version, then redact the old one; redaction keeps who wrote it and when, and can’t be undone. See Memory.
• Deleting a session isn’t erasure. Deleting stops the session, requests sandbox teardown, and removes it from lists and reads, but the transcript is retained. It can’t be undone through the API.
• Secrets stay out of history when you use vaults. Never put a secret in a system prompt, message, rubric, metadata, environment env_vars, or a file. Those values are stored with the session or environment and returned by reads.
• Failure messages are sanitized. A session’s failure.message never contains raw provider responses or credentials, and setup-run stderr_tail is redacted and limited to 2 KiB.

​

Your responsibilities

• Grant each session only the vaults and credentials its task needs, and each agent only the apps and tools its work needs.
• Keep environments on No access, or on specific allowed destinations, unless the task needs the open internet.
• Review what an agent produces before you merge, deploy, or send it.
• Rotate credentials and API keys regularly, and revoke them at once if you suspect exposure.
• Treat anything an agent can read as something it might print.

​

Next steps