Skip to Content
Platform
PlatformSecurity Model

Security model

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.

This page describes the security guarantees Introspection gives you. For the operational controls behind them, see Infrastructure (encryption, networking, identity) and Data Handling (what data is held and how it’s controlled).

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 multi-tenantLogical separation per organization, plus per-org encryption
Dedicated single-tenantInfrastructure-level separation on its own dedicated environment

Authentication

There are two ways to authenticate:

  • Dashboard: you sign in through the browser and hold a session.
  • Server-side SDK: you authenticate with an environment-scoped API key or a short-lived service-account token.
  • CLI: you authenticate as a member through browser-approved device login; the server grants the operator and local-development scopes.

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 Authentication & API Keys for creating and using keys.

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, integrations, or billing.
  • 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, mint a replacement and revoke the old one. Operator-only actions use the member-authenticated CLI or dashboard instead of widening the key.

Encryption

Sensitive data is encrypted at rest, with encryption scoped per organization so ciphertext from one record cannot be reused in another. Conversation and event content is encrypted as it is written and is never persisted in the clear.

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.

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 actor, action, resource, or time range) and can be exported for your own retention or compliance review. When an operator acts on behalf of another member, the entry records both, so delegated actions are never anonymous.

Last updated on