Skip to Content
Platform
PlatformSecurity & data

Security & data

Isolation is structural, not incidental: your data is separated by organization, encrypted at rest, and your agent never sees your real API keys or credentials.

These are the security boundaries you can rely on. See Deployment & infrastructure for the underlying stack 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:

Deployment modelIsolation
Managed CloudOrganization and project isolation in Introspection-operated infrastructure
BYOCData Plane and network boundary in the customer’s cloud account
On-premCustomer-controlled private or air-gapped infrastructure boundary

Sandbox isolation

Agent workloads run in ephemeral, hardened sandboxes with scoped access to only the resources they need, egress domain whitelisting, and automatic cleanup after a task ends. There is exactly one task per sandbox: follow-up runs inside one interactive task can reuse its sandbox, but separate tasks never share sandbox state. A leaked credential, a runaway process, or a corrupted working directory is bounded to a single task. See Sandboxes for the task-facing view.

Authentication boundaries

Application traffic authenticates as an API key, a service-account application, or a federated application, while dashboard and CLI access authenticate a human member through a browser session — see Authentication & identity → Choose an authentication method for the complete trust model.

API key handling

Introspection is careful with API keys:

  • The full key is never stored. It is shown once, on creation, and only a one-way hash is kept. It is never transmitted between services in the clear.
  • 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.

Transport encryption, at-rest encryption of the underlying stores, and customer-managed keys are infrastructure controls — see Deployment & infrastructure.

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. Repository write access is a separate, declared grant — the runtime.github block described in GitHub → Workspace repositories. No manifest grant means no repository write capability.

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.

Self-improving agents

An agent’s recipe is a repository like any other, so the runtime.github grant can name it. Doing so gives the agent write access to the prompts, skills, and tools that define its own behavior — an agent that can propose fixes to itself. That is a supported pattern, and it is also the point where the security decisions above stop being theoretical: treat it as a governance choice, not a configuration detail.

The capability is opt-in. A runtime is always entitled to clone its own recipe, but that entitlement alone is read-only. Write access appears only when you list the recipe’s repository in the grant and elevate contents:

# .introspection/support-agent.yaml
name: support-agent
path: apps/support-agent
runtime:
  github:
    repositories:
      - acme/platform      # the repository this recipe lives in
    permissions:
      contents: write
      pull_requests: write

With it, the agent can open a pull request against its own recipe — an ambiguous instruction, a missing skill, a misleading tool description — and the merged commit becomes a new runtime version through the ordinary lifecycle. Nothing about the deploy path is special-cased for agent-authored changes.

Two things deserve explicit review:

  • The monorepo case grants more than you may intend. When a recipe lives inside a larger repository — the common shape, and what path: exists for — granting that repository so the agent can edit the service also grants the recipe beside it. A GitHub installation token cannot be scoped to a sub-path, so the two travel together: an agent granted acme/platform to fix a checkout bug can also edit its own instructions. Know which one you are doing.
  • An unpinned production lane closes the loop. A merged default-branch commit creates and activates a production runtime version whenever that lane is unpinned. Combined with write access to its own recipe, an agent can ship its own change all the way to production without a person in the path.

Two controls decide how much of that loop you allow, and both are yours:

ControlEffect
Required-review branch protectionThe agent can open a pull request but not merge it. A person approves every change to the recipe.
A pinned production laneMerges still land and versions are still built, but production stays on the version you pinned until you move it.

With neither, the agent self-deploys. Choose that deliberately, and keep the review gate on any runtime that handles untrusted input — prompt injection reaching an agent that can rewrite its own instructions is a persistent compromise, not a one-off bad turn.

Start with required review. An agent that reliably proposes good recipe changes has earned a shorter path; one that has not yet is exactly the case the review gate exists for.

Last updated on