Security Controls: Egress Governance And Secret Handling Via Proxy Substitution
Key takeaways
- Deno Sandbox can inject API secrets as placeholder environment variables and only replace them with real values via an outbound proxy for specified hosts.
- Code can be created and executed in Deno Sandbox from Python using the deno-sandbox library with a DENO_DEPLOY_TOKEN.
- Sandbox sessions can last up to 30 minutes and are billed by CPU time, GB-hours of memory, and volume storage usage.
- Fly has an open project called tokenizer that implements a similar secret-tokenization pattern for sandboxed environments.
- Sandbox instances can be provisioned with up to 4GB RAM, 2 vCPUs, 10GB ephemeral storage, optional persistent volumes, and snapshots for fast boot of preconfigured images.
Sections
Security Controls: Egress Governance And Secret Handling Via Proxy Substitution
Two complementary controls are described: restricting outbound network access by domain and preventing direct secret readout by injecting placeholders that are only materialized by an outbound proxy for specified hosts. The stated intent is to reduce secret exfiltration risk, including in prompt-injection scenarios.
- Deno Sandbox can inject API secrets as placeholder environment variables and only replace them with real values via an outbound proxy for specified hosts.
- The secret placeholder design is intended to limit exfiltration by malicious code, including prompt-injection-driven behavior, because code inside the sandbox cannot directly read real secret values.
- When creating a sandbox, it is possible to restrict which network domains the sandbox is allowed to access.
Product Positioning And Integration Surface
The product is positioned as a hosted sandbox within Deno Deploy rather than a feature restricted to Deno runtime users, and it exposes at least one non-JavaScript integration path via a Python library that authenticates using a deploy token.
- Code can be created and executed in Deno Sandbox from Python using the deno-sandbox library with a DENO_DEPLOY_TOKEN.
- Deno Sandbox is a new hosted sandbox product from the Deno team that is part of the Deno Deploy SaaS platform and is not directly tied to using Deno itself.
Execution Envelope, Lifecycle Limits, And Billing Dimensions
The corpus specifies a bounded compute and storage envelope (CPU/RAM/ephemeral storage) plus optional persistence and snapshots, and also specifies a maximum session duration with billing tied to CPU time, memory GB-hours, and volume storage. Together these define feasibility boundaries and unit-cost drivers for workloads.
- Sandbox sessions can last up to 30 minutes and are billed by CPU time, GB-hours of memory, and volume storage usage.
- Sandbox instances can be provisioned with up to 4GB RAM, 2 vCPUs, 10GB ephemeral storage, optional persistent volumes, and snapshots for fast boot of preconfigured images.
Emerging Pattern Reference: External Similar Implementation
A separate project is cited as implementing a similar secret-tokenization pattern, indicating the described approach is not unique to a single vendor in the corpus.
- Fly has an open project called tokenizer that implements a similar secret-tokenization pattern for sandboxed environments.
Unknowns
- What are the actual price rates (per CPU time unit, per GB-hour, and per volume storage unit), and are there minimum charges or billing granularity details?
- What concurrency limits, quotas, regional availability, and provisioning latency characteristics apply to sandbox creation and execution?
- How robust is domain restriction enforcement (e.g., handling of raw IP access, DNS rebinding scenarios, redirects, and other egress edge cases)?
- What are the exact rules for which outbound destinations trigger secret substitution, and what is the operational/auditing surface (logs, traces, allowlists, approvals)?
- What languages/runtimes are supported inside the sandbox beyond the fact that it can be orchestrated from Python, and what APIs exist for filesystem, networking, and process control?