Deno Sandbox

Perceived LLM-Style Writing in the Announcement

• Multiple commenters independently felt the blog post “reads like LLM output.”
• They point to patterns like: “This isn’t X, it’s Y”, overuse of em-dashes, short punchy two-sentence paragraphs, “why this matters/works” headings, second-person tone, and rule-of-three phrasing.
• Others argue these are long-standing human rhetorical devices and that em-dashes or curly quotes are weak signals; many humans just write like this (and some now consciously avoid such patterns to not “sound like an LLM”).
• There’s concern that frequent exposure to LLM text will subtly reshape human writing style.

Secret Placeholders and Outbound Proxy

• Core idea praised as “clever”: code only ever sees a placeholder for secrets; real keys are injected by an outbound proxy only for approved hosts.
• This resembles existing tokenization/proxy patterns (e.g., PCI token services, Fly’s Tokenizer, macaroons, Dagger secrets).
• The benefit: untrusted or LLM-generated code can’t permanently steal keys, but can still use them to call allowed APIs.
• Commenters liken this to HTTP-only cookies: still usable for actions, but not directly readable by injected code.

Security Caveats and Open Questions

• Several note this doesn’t prevent malicious behavior using the secret (e.g., destructive DB queries, misusing API access). It mainly mitigates exfiltration.
• Discussion of potential bypasses if the proxy blindly replaces placeholders anywhere in the request (bodies, reflected fields) and doesn’t understand context.
• Some ask how it works for non-HTTP protocols (e.g., raw TCP to databases) and how HTTPS interception and certificate pinning are handled; answers are unclear from the thread.
• Concern that LLMs could chain tools (e.g., call another code interpreter) to leak secrets, depending on system design.

Product Scope, Value, and Ecosystem

• Many see Deno Sandbox as “Firecracker microVMs + network policy + secrets proxy” delivered as a managed service.
• Some question whether “everyone has already built this,” while others argue repeated DIY sandboxes prove there’s a real product need, especially for scale and low latency.
• Comparisons and mentions: Sprites, E2B, Modal, Cloudflare, Fly, various open-source or commercial sandboxes—there’s a sense of a rapidly crowding space.
• Several highlight use cases beyond agents: long-lived dev servers, side projects, remote environments that resume instantly.

Pricing and Lock-In Concerns

• Multiple comments criticize pricing as 10–30× higher than cheap VMs from commodity providers if used continuously; only economical if usage is very bursty.
• Some lament lack of self-hosted support and broader “castle in someone else’s sandbox” lock-in, though other projects in the space offer open-source stacks.

Miscellaneous Notes

• SDKs exist for other languages (e.g., Python); control is via a WebSocket protocol.
• Some confusion around session lifetimes, snapshot/volume creation from CLI, and exact network/TCP capabilities; details are seen as incomplete or behind the docs.