Hacker News

I feel like this is a bot account. Or at least, everything is AI generated. No posts at all since the account was created in 2024 and now suddenly in the past 24 hours there's dozens of detailed comments that all sort of follow the same pattern/vibe.

Yes... but...

Presumably the proxy replaces any occurrence of the placeholder with the real key, without knowing anything about the context in which the key is used, right? Because if it knew that the key was to be used for e.g. HTTP basic auth, it could just be added by the proxy without using a placeholder.

So all the attacker would have to do then is find and endpoint (on one of the approved hosts, granted) that echoes back the value, e.g. "What is your name?" -> "Hello $name!", right?

But probably the proxy replaces the real key when it comes back in the other direction, so the attacker would have to find an endpoint that does some kind of reversible transformation on the value in the response to disguise it.

It seems safer and simpler to, as others have mentioned, have a proxy that knows more about the context add the secrets to the requests. But maybe I've misunderstood their placeholder solution or maybe it's more clever than I'm giving it credit for.

Reminds me a little of Fly's Tokenizer - https://github.com/superfly/tokenizer

It's a little HTTP proxy that your application can route requests through, and the proxy is what handles adding the API keys or whatnot to the request to the service, rather than your application, something like this for example:

Application -> tokenizer -> Stripe

The secrets for the third party service should in theory then be safe should there be some leak or compromise of the application since it doesn't know the actual secrets itself.

Cool idea!

Yeah, this is a really neat idea: https://deno.com/blog/introducing-deno-sandbox#secrets-that-...

  await using sandbox = await Sandbox.create({
    secrets: {
      OPENAI_API_KEY: {
        hosts: ["api.openai.com"],
        value: process.env.OPENAI_API_KEY,
      },
    },
  });
  
  await sandbox.sh`echo $OPENAI_API_KEY`;
  // DENO_SECRET_PLACEHOLDER_b14043a2f578cba75ebe04791e8e2c7d4002fd0c1f825e19...

Kind of like how XSS attacks can't read httpOnly cookies but they can generally still cause fetch() requests that can take actions using those cookies.

@deno team, how do secrets work for things like connecting to DBs over a tcp connection? The header find+replace won't work there, I assume. Is the plan to add some sort of vault capability?

It must be performing a man-in-the-middle for HTTPS requests. That makes it more difficult to do things like certificate pinning.

We had this same challenge in our own app builder, we ended up creating an internal LLM proxy with per-sandbox virtual keys (which the proxy maps to the real key + calculates per-sandbox usage), so even if the sandbox leaks its key it doesn't impact anything else.

I was just about to say the same thing. Cool technique.

This is an old trick that people do with Envoy all the time.

Dagger has a similar feature: https://docs.dagger.io/getting-started/types/secret/

Same idea with more languages on OCI. I believe they have something even better in the works, that bundles a bunch of things you want in an "env" and lets you pass that around as a single "pointer"

I use this here, which eventually becomes the sandbox my agent operates in: https://github.com/hofstadter-io/hof/blob/_next/.veg/contain...

It’s pretty neat.

Had some previous discussion that may be interesting on https://news.ycombinator.com/item?id=46595393

I like this, but the project mentioned in the launch post

> via an outbound proxy similar to coder/httpjail

looks like AI slop ware :( I hope they didn't actually run it.

Like the emdash, whenever I read: "this isn't x it's y" my dumb monkey brain goes "THATS AI" regardless if it's true or not.

What I don't understand -- why put your name on LLM marketing copy? Add an extra tag of authenticity to the message? For me, it does the opposite.

These are all wrappers around VMs. You could DIY these easily by using EC2/serverless/GCP SDKs.

Factory, Nvidia, Perplexity and Manus are using E2B in production - we ran more than 200 million Sandboxes for our customers

We'll increase the lifetime in the next weeks - just some tech internally that needs to be adjusted first.

What's the use case for this? Trying to get raw API access through a monthly plan? Or something else?

For what it's worth, I do this from about 50 different IPs and have had no issues. I think their heuristics are more about confirming "a human is driving this" and rejecting "this is something abusing tokens for API access".

The idea is to gate automatic secret replacement to specific hosts that would use them legitimately to avoid exfiltration.

Well, this is the hard part, but the idea is that if you're working with both untrusted inputs and private data/resources, then your agent is susceptible to the "lethal trifecta"[0], and you should be extremely limiting in its ability to have external network access. I would suggest starting with nothing beyond the single AI provider you're using, and only add additional domains if you are certain you trust them and can't do without them.

[0] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

Yes, sprites looks great too – would certainly be interested in a comparison.

what are the key architectural differences?

Everyone wants to lock you in.

Unfortunately there's no other way to make money. If you're 100% liberally licensed, you just get copied. AWS/GCP clone your product, offer the same offering, and they take all the money.

It sucks that there isn't a middle ground. I don't want to have to build castles in another person's sandbox. I'd trust it if they gave me the keys to do the same. I know I don't have time to do that, but I want the peace of mind.

This is, in fact, the biggest problem to solve with any kind of compute platform. And when you suddenly launch things really, really fast, it gets harder.

Isn’t that basically how zip-bombs work?

> Hasn't everyone already built this for themselves in the past 2 years?

Even if this was true, "everyone building X independently" is evidence that one company should definitely build X and sell it to everyone

Sandboxes with the right persistence and http routing make excellent dev servers. I have about a million dev servers I just use from whatever computer / phone I happen to be using.

It's really useful to just turn a computer on, use a disk, and then plop its url in the browser.

I currently do one computer per project. I don't even put them in git anymore. I have an MDM server running to manage my kids' phones, a "help me reply to all the people" computer that reads everything I'm supposed to read, a dumb game I play with my son, a family todo list no one uses but me, etc, etc.

Immediate computers have made side projects a lot more fun again. And the nice thing is, they cost nothing when I forget about them.

> Hasn't everyone already built this for themselves in the past 2 years?

The short answer is no. And more so, I think that "Everyone I know in my milieu already built this for themselves, but the wider industry isn't talking about it" is actually an excellent idea generator for a new product.

Has everyone really built their own microVMs? I don’t think so.

It’s a cloud service - so you can call out to it from anywhere you want. Just don’t ship your credentials in the app itself, and instead authenticate via a server you control.

We honestly should have just linked to oracle.com instead of evil.com

seems it.