Answer the security review with the mechanism itself.

Every agent run starts in a fresh microVM that belongs to exactly one workspace, holding the agent's current version, the resources it declares and the tools it's allowed to call, and nothing else; the code the model writes runs there, and when the run ends the machine is destroyed and the record is what stays.

A run can't reach another run, another workspace or the host, and its CPU, memory, disk and network are bounded per sandbox.

A misdirected call is refused, never quietly redirected.

One organization key reaches every workspace in your organization, and every call it makes has to name the workspace it acts on.

• A workspace id that doesn't exist, or belongs to another organization, returns 404.
• An organization key with no workspace named resolves only when the organization has exactly one workspace. Otherwise the call is refused with 400 and asks you to pick.
• A key issued for a single workspace that names a different one is refused with 403 rather than silently ignored, so a caller never acts somewhere other than where it asked to.

Your customer authorizes Slack, GitHub or any other provider inside your product, against your OAuth app, and your backend pushes the resulting tokens into that customer's workspace, where their agents pick them up on the next run. Levain stores them encrypted, ships them only into that workspace's runs, and the model never sees them.

• Pushing a credential is create-or-rotate: the same call with a fresh token replaces the old one.
• Levain never refreshes a pushed token. Refresh tokens and OAuth client secrets stay with the owner of the OAuth app, which is you.
• An OAuth access credential has to carry an expiry; the API refuses it without one.
• Listing a workspace's integrations returns each credential's expiry and whether it has lapsed. Secret material is never returned.
• Deleting an integration deletes the stored secret immediately. The integration record is kept, marked revoked, so the record stays intact.
• When a run finds a credential no longer works, a webhook fires, so your product can ask that customer to reconnect.

Anthropic and OpenAI don't train their models on data sent through the API, and in production inference runs through AWS Bedrock, where traffic stays within Bedrock and isn't sent to a provider's own external API. Every provider that can serve a request is named in the sub-processor list below.

• Every agent's model traffic goes through a proxy provisioned with the run, inside its sandbox. Direct provider routes are used in development and when you bring your own key.
• Bring your own key and the request hits your provider account, so that provider bills you for the tokens.
• Your key is encrypted at rest, decrypted only inside the sandbox at run time, and never returned by the API. Revocation is immediate, and runs after it fall back to Levain's provider accounts.
• Either way the call is recorded: the model, the token counts, the latency and the cost, in the run's session and in your analytics. The per-run and per-workspace cost figures are built from that.

• Anthropic
• OpenAI
• Amazon Bedrock

Agents, runs, records and each workspace's knowledge are readable and exportable through the API, with the workspace named on the call, and usage comes back per workspace in millionths of a USD. There is no export fee and no lock on your model keys.

Deletion is on request today: email privacy@levainlabs.com and we delete the workspace's data; there is no delete endpoint you can call. Suspending a workspace is a different action, one that refuses new runs and keeps everything, which is what offboarding usually wants.

What we collect, how long we keep it and the rights you can exercise are in the Privacy Policy.

Last updated: 20 August 2026

A sub-processor is a third party that processes personal data on our behalf to help us deliver the Service. The list below is current as of the date above; we give Customers advance notice before adding one that processes Customer Content, and Customers may object on reasonable grounds.

To receive notifications of changes, email privacy@levainlabs.com with the subject "subscribe: sub-processors".

In production, model inference runs through AWS Bedrock, which hosts foundation models from a range of providers including Anthropic, Meta, Cohere, Mistral AI, AI21 Labs, Stability AI, and Amazon's own model families. Customers may build agents that invoke any model the platform exposes from this catalog, and the corresponding model owner acts as a sub-processor when its model serves a request. Direct provider routes (outside Bedrock) are used in development and when a Customer brings their own provider key (BYOK).

What no third party touches

These components are part of the Service but are operated by Levain Labs on our own AWS infrastructure rather than by a third party, so they are not sub-processors:

• Application databases (PostgreSQL on AWS RDS managed by us, ClickHouse self-hosted on EKS, Redis self-hosted on EKS).
• The LiteLLM proxy that routes inference requests.
• Internal observability and logging (the LGTM stack: Loki, Grafana, Tempo, Mimir), self-hosted on EKS.

Third-party services that a Customer connects to their own agents (for example, Slack, GitHub, Intercom, or other integrations chosen by the Customer) are not our sub-processors. The Customer's relationship with those services is governed by the Customer's own agreement with them.

Questions about this list, requests for change notifications, or objections to a new sub-processor: privacy@levainlabs.com.

• No SOC 2 report. We haven't been through the audit, so there is no Type 1 or Type 2 report to send you.
• No HIPAA BAA. We don't sign one, so protected health information doesn't belong on Levain.
• No VPC deployment. Levain runs on our own AWS account; there is no install inside yours.