zlacker

>>johnsp+(OP)
> In Deno Sandbox, secrets never enter the environment. Code sees only a placeholder

> The real key materializes only when the sandbox makes an outbound request to an approved host. If prompt-injected code tries to exfiltrate that placeholder to evil.com? Useless.

That seems clever.

>>emschw+Hb
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!

>>motrm+Ud
This reminds me of a SaaS that existed 15+ years ago for PCI-DSS compliance. It did exactly that: you had it tokenize and store the sensitive data, and then you proxied your requests via it, and it inserted them into the request. It was a very neat way to get around storing data yourself.

I cannot remember what the platform was called, let me know if you do.

>>pbowye+Pf2
There are multiple companies doing that. I was using one a few years ago, also don't remember the name, haha.

I guess it's an obvious thing to sell, if you go through the process of PCI-DSS compliance. We were definitely considering splitting the company to a part that can handle these data and the rest of the business. The first part could then offer the service to other business, too.