Sandbox Support: Daytona and E2B

This document explains what “Daytona support” and “E2B support” mean in Gateway/Viper today.

How Gateway identifies Daytona or E2B

Gateway does not directly inspect your runtime environment. Instead:

1. Viper collects selected environment variables from the agent process at request time.
2. Viper includes them in StateAttestationData.environment.vars.
3. Viper sends the state CID in X-Viper-State-CID (plus nonce/timestamp headers).
4. Gateway reads the referenced state blob and uses the captured variables as sandbox hints.

In short: sandbox identification is currently based on environment-parameter presence/value in Viper state attestations.

Captured Daytona parameters

By default, Viper captures these Daytona variables (when present):

• DAYTONA_SANDBOX_SNAPSHOT: Daytona snapshot identifier for the sandbox image/state used to start the runtime.
• DAYTONA_SANDBOX_ID: Daytona sandbox instance identifier.
• DAYTONA_ORGANIZATION_ID: Daytona organization/workspace identifier associated with the sandbox.

Captured E2B parameters

By default, Viper captures these E2B variables (when present):

• E2B_SANDBOX: E2B sandbox indicator/name provided by the runtime.
• E2B_TEMPLATE_ID: E2B template identifier used to create the sandbox.
• E2B_SANDBOX_ID: E2B sandbox instance identifier.

What “support” means

“Daytona support” / “E2B support” currently means:

• Viper knows which sandbox-related environment parameters to collect.
• Those parameters are attached to request provenance (state attestation).
• Gateway can read and store these parameters for audit/policy use.

It does not mean Gateway has cryptographic proof from Daytona/E2B that the runtime is genuine.

Trust boundary and spoofing risk

Environment variables are user-space inputs. A user or agent can set these same variables outside Daytona/E2B and appear sandboxed.

So these fields should be treated as claims, not proof.