Security & data

These are the security boundaries you can rely on. See Infrastructure for the underlying controls and Data Handling for what data is stored.

Tenant isolation by organization

Every piece of data in the platform is scoped to your organization. Your data is never visible to another tenant, and no request can ask the platform to act as a different organization: the tenant is fixed by your authenticated credentials, not by anything in the request.

How strongly that isolation is enforced depends on your deployment model:

Authentication boundaries

Application traffic supports three trust models:

• API key: a long-lived, environment-scoped server credential.
• Service-account application: a confidential B2B2C backend authenticates its own users and supplies their identities when it opens short-lived runner sessions.
• Federated application: Introspection verifies the end user through the partner’s configured identity provider before minting a token.

Dashboard and CLI access instead authenticate a human member through a browser session or browser-approved device login. See Authentication & identity for the complete trust model.

Introspection is careful with API keys:

• The full key is never stored. It is shown once, on creation, and only a hash is kept.
• If you revoke a key, access stops promptly across the platform.
• The key never enters a sandbox. Your running agent never holds the key that created its task.

See SDK authentication for configuring the credential flows.

Browser and federation boundaries

A browser never receives an API key, service-account secret, or general service-account access token. Its backend broker returns a short-lived, identity-bound runner token, runtime ID, and Data Plane URL; the browser exchanges the token for an HttpOnly Data Plane session cookie. Runtime resolution and end-user binding remain server-side Control Plane operations.

When a task calls an authorized partner endpoint, Introspection applies the task identity at the egress boundary. The agent and sandbox never see the assertion. The receiving endpoint verifies the platform signature and must distinguish federation-proven identity_assertion from caller-supplied identity_attribution before authorizing resources.

What an API key can do

An API key grants the runtimes capability rather than arbitrary platform access. There are hard limits on what any key can do:

• It cannot attach a local working tree; remotes is reserved for member-authenticated CLI login.
• It cannot administer organizations, members, applications, or integrations.
• It cannot escape its project or environment binding.
• It cannot grant a runner more than the server’s runner-scope ceiling.

To rotate or change an API key’s environment or identity binding, create a replacement and revoke the old one. Administrative changes use the member-authenticated CLI or dashboard instead of widening the key.

Encryption

Protected fields use application encryption bound to the owning organization and record, so ciphertext from one record cannot be reused in another. Managed Cloud uses encrypted-only storage for supported conversation payload fields by default: the processor writes encrypted payloads and removes their plaintext counterparts before persistence.

Some development and explicitly configured deployments can use dual mode for debugging compatibility, which stores both encrypted and plaintext payload attributes. Do not use dual mode where encrypted-only application storage is required.

Your agent never sees your real credentials

When your agent makes an outbound call to a model provider or upstream API, the real credential is injected at the network boundary, on the wire. The agent’s code never sees the real key. This means a recipe, or anything running inside the sandbox, cannot read or exfiltrate the credentials it uses.

The credential that created a task is also never passed into the sandbox. Each sandbox holds only a short-lived, task-scoped token for talking back to the platform, so a token from one task cannot be used against another.

The same least-privilege boundary applies to recipe source. A managed runtime can receive a short-lived, read-only GitHub token scoped to the repository its pinned recipe uses. That clone credential is not a general write credential.

Write access is a separate, declared grant. A runtime that needs to push a branch or open a pull request declares workspace repositories in its manifest’s runtime.github block: repositories bounds which registered repositories its tasks may touch, and permissions bounds what the minted token may do, over a closed allow-list that reads are implicit in and that refuses escalation keys such as workflows and administration. No manifest grant means no repository write capability.

The grant decides the ceiling, not which repository holds the recipe, so a recipe may grant its own repository and give its agent write access to the prompts and tools that define it. That is a supported pattern — self-improving agents — and, like any agent write access, the customer’s branch protection is what decides whether the change is a proposal or a deploy. Work with repositories walks through declaring the grant and the review boundary that should accompany it.

Audit log

Sensitive actions across your organization are recorded to an audit log: who did what, when, and to which resource. Each entry captures the actor (a member or an API key), the action taken, the resource it affected, and a timestamp, so you have a verifiable trail of changes to projects, members, keys, integrations, and deployments.

The log is queryable and filterable by person, action, resource, or time range. For retention or compliance review, page the audit list API and serialize the records. When one member acts on behalf of another, the entry records both, so delegated actions are never anonymous.

Securing your agent

Everything above is the platform boundary: what isolates one organization from another, what an API key can reach, and what your agent is never shown. Those guarantees hold regardless of what your recipe does.

They do not cover what your agent does with the content it reads. An agent that retrieves documents, runs tools, fetches pages, or delegates to a child agent is taking in text from outside the operator, and that text can be written to steer behavior. The platform bounds the blast radius — credentials are injected at the network boundary, egress is restricted, and each task is destroyed with its sandbox — but it cannot decide which of your agent’s own actions should be reachable from something it read.

That is a recipe design decision. Keep it in mind when adding a capability: an action that must never happen belongs outside the agent’s tools entirely, and an action that is sometimes allowed belongs behind a check that does not depend on the model’s cooperation. Review these decisions explicitly whenever a coding agent changes the recipe’s capabilities.

Related

• Infrastructure: encryption, networking, identity, and container hardening.
• Data Handling: what agent-run data is held, how it’s stored, and how to control it.
• Authentication & identity: caller credentials, end-user identities, and trust levels.
• SDK authentication: configure keys, token grants, and browser brokers.
• Platform: the source control, tools, models, and architecture this security model protects.
• Sandboxes: how each task runs in isolation.