> ## Documentation Index
> Fetch the complete documentation index at: https://docs.labelbox.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Security
> How Managed Agents isolates organizations and sandboxes, controls network access, decides which credential values agents can read, and handles your data.
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](/recursion/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](/recursion/api-keys).
* People at your DNS-verified domains can sign in through your own SAML identity provider, and you can require it for them. See [Enterprise SSO](/recursion/enterprise-sso).
## 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 stay open forever.** A hard stop closes the sandbox. An idle sandbox stops after the environment's idle period and may later be released. After an idle stop or release, send another message to reopen the same session. Its workspace files can be used when the workspace reopens successfully.
## Network access
New environments have no internet access unless you allow it. Grant only the destinations the task needs.
* 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.
Privileged Docker requires unrestricted internet access (`network_policy: {}`). A nonempty policy and privileged Docker cannot be combined on create or when access settings change.
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. See [Environment reference](/recursion/environments-reference).
Model calls, MCP servers, and the `web_search` and `web_fetch` tools don't go through the sandbox, so the network policy doesn't govern them; control them in the agent's configuration. A session started by an automation or from Slack in an environment with limited or no internet access gets no `web_fetch` tool, so event text can't use it to send data out. See [Tools](/recursion/tools).
## 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:
```mermaid theme={"theme":"css-variables"}
flowchart TD
vault["Vault"] --> bearer["MCP bearer token"]
vault --> envvar["Environment-variable secret"]
bearer -->|"added outside the sandbox"| mcp["MCP server"]
envvar -->|"set as plaintext"| sandbox["Sandbox, shared by the tree"]
```
| Credential | Can the agent read the value? | Recommendation |
| - | - | - |
| MCP bearer token | No. It's added to requests to the MCP server and never enters the sandbox or the model's context. | Prefer this whenever the service speaks MCP. |
| Environment-variable secret | Yes. It's a plaintext environment variable in the sandbox, so any command any agent in the session tree runs can read it. The console asks you to acknowledge this before storing one. | Use only for tools that need a variable, with the narrowest-scoped token the service offers. |
Tool output masks an environment-variable secret's current value, but a transformed, truncated, very short or since-rotated value can still appear in output or the transcript.
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](/recursion/multi-agent#what-a-child-inherits).
* 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 give sessions short-lived access bounded by the connection and agent grant. Standalone GitHub MCP requests use a token whose permissions come from the selected tools and repositories; sandbox `git` and `gh` receive no GitHub credential. See [GitHub access](/recursion/github) and [Integrations](/recursion/integrations).
## Automations and event sources
* **Deliveries are verified.** Slack and GitHub event sources check every delivery's signature. Connecting the account on **Integrations** creates and manages the signing secret, which never reaches a sandbox. A custom webhook source that doesn't verify signatures 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. In an environment with unrestricted internet access, that text reaches a session that can use the open internet.
* **Automations run a pinned agent version.** Removing a grant from the agent doesn't reach an automation until you move it to the new version.
* **Runs are recorded.** Every run keeps its frozen configuration, trigger, event, and opening message, including after the automation is deleted. A webhook run records only the sender's own headers.
## 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](/recursion).
* **Files.** Files you attach to a session and the deliverables agents save stay in your organization, in the session's **Files** tab. See [Files](/recursion/files).
* **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, 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
Store credentials and grant them to sessions.
Configure network policy, compute, and lifecycle.
Scope, rotate, and revoke keys.
Decide who can do what.