E2B Workload Identity lets backends verify which sandbox is calling

The problem: a shared key does not say who is calling

When a sandbox fetches a document, submits a task result or calls an internal service, the receiving backend needs to know who is asking and what that caller may do. E2B points out that a shared API key can authenticate a request, but it does not identify which sandbox sent it.

The alternative is to issue a separate credential for every sandbox, which means building the machinery to distribute, rotate and track those credentials. E2B says Workload Identity is meant to make this easier. The company describes it as another step in making sandboxes useful for real applications: agents need access to a customer's systems, and those systems need a reliable way to identify them.

How the feature works

When creating a sandbox, a developer defines a named workload token and its audience, meaning the service intended to receive it. That token is then referenced in a network rule. When a matching HTTPS request leaves the sandbox, E2B adds a signed token to the request header the developer has configured.

E2B issues the token outside the sandbox, which keeps it out of the sandbox's environment and filesystem. The token carries an expiration and the intended audience. In the example in the announcement, the token is defined with the E2B SDK using Secret.iamToken, with an audience of api.example.com and the token type JWT-SVID.

• The reference iam.tokens.backend is a placeholder, not the JWT itself. E2B substitutes the real token when forwarding matching requests.
• E2B can reuse a cached token for the same sandbox execution and audience while it is valid.
• Any HTTP request header the service expects can be used.
• Code inside the sandbox makes a normal HTTPS request, for example with curl, and does not need to send an Authorization header, even with a dummy value.

If an HTTP client uses its own CA bundle, it must be configured to trust E2B's egress proxy. E2B refers developers to its documentation on TLS certificates for Python Requests and Node.js.

Verifying the identity and setting permissions

For E2B Cloud, the company publishes an OpenID Connect (OIDC) discovery document. It names https://id.e2b.dev as the issuer and points to the JSON Web Key Set (JWKS) containing E2B's public signing keys. BYOC deployments use their own issuer URL and public keys, which are configured when support enables Workload Identity for the deployment.

A backend can use a JWT verification library to fetch and cache the keys. E2B recommends configuring it to accept ES256 signatures, require the expected issuer and audience, and check the expiration and not-before times. The backend should also confirm that the token's subject belongs to the expected project and sandbox execution.

Access rules stay with the customer. For example, a backend that starts a document-processing task can associate the sandbox ID with that task, and check the association before returning data. The same approach can let a sandbox submit results for its assigned job or call a specific internal tool. In E2B's words, the company provides the signed workload identity, and the customer decides which resources and operations it can access.

Example: temporary AWS credentials

The announcement also walks through an AWS scenario in which a sandbox needs to read an object from an S3 bucket. The backend receives the injected E2B JWT, exchanges it with AWS Security Token Service (STS), and uses the resulting temporary credentials to fetch the document. For this, the token audience is set to sts.amazonaws.com.

• E2B is registered as an OIDC provider in the AWS account that owns the role, once per issuer per account.
• A role trust policy restricts access using the audience and a subject pattern tied to the E2B project ID. E2B notes that provider registration alone does not restrict access to a project.
• The role is granted access to a single S3 object.
• A Flask app using boto3 reads the bearer token, calls STS with it and returns only the document to the sandbox.

In the example, the AWS credentials expire after 15 minutes, independently of the E2B token, and no long-lived AWS access keys are needed. E2B cautions that the example lets every identity accepted by the trust policy read the same document. For documents tied to individual sandbox jobs, the verified identity should also be checked against that job's permissions. For BYOC, the issuer host and the configured trust domain in the spiffe:// subject can differ, and support can provide both values.

What it means for developers

For teams running agents in E2B sandboxes, the feature offers a way to identify each sandbox to their own services without handing out and managing per-sandbox secrets. Because the token is added outside the sandbox, code running inside never holds it. Workload Identity is generally available on E2B Cloud, while BYOC users need support to enable it for their deployment.