121–130 of 185 posts
Note that you don't need to use Deno or JavaScript at all to use this product. Here's their Python client SDK: https://pypi.org/project/deno-sandbox/ from deno_sandbox import DenoDeploy sdk = DenoDeploy() with sdk.sandbox.create() as sb: # Run a shell command process = sb.spawn("echo", args=["Hello from the sandbox!"]) process.wait() # Write and read files sb.fs.write_text_file("/tmp/example.txt", "Hello, World!") co…
Earlier quoted context omitted.
In the last one year, we have seen several sandboxing wrappers around containers/VMs and they all target one use case AI agent code execution. Why? perhaps because devs are good at building (wrappers around VMs) and chase the AI hype. But how are these different and what value do they offer over VMs? Sounds like a tarpit idea, tbh. Here's my list of code execution sandboxing agents launched in the last year alone: E2…
don't forget runloop!
> 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.
"Over the past year, we’ve seen a shift in what Deno Deploy customers are building: platforms where users generate code with LLMs, and that code runs immediately without review. That code frequently calls LLMs itself, which means it needs API keys and network access. This isn’t the traditional “run untrusted plugins” problem. It’s deeper: LLM-generated code, calling external APIs with real credentials, without human…
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.
We recently built our own sandbox environment backed by firecracker and go. It works great.
For data residency, i.e. making sure the service is EU bound, there is basically no other way. We can move the service anywhere we can get hardware virtualisation.
As for the situation with credentials, our method is to generate CLIs on the fly and expose them to the LLMs and then they can shell script them whichever way they want. The CLIs only contain scoped credentials to our API which handles oauth and other forms of authentication transparently. The agent does not need to know anything about this. All they know is that they can do
$ some-skillset search-gmail-messages -q "emails from Adrian"
In our own experiments we find that this approach works better and it just makes sense given most of the latest models are trained as coding assistants. They just love bash, so give them the tools.
Secret placeholders seems like a good design decision. So many sandbox products these days though. What are people using in production and what should one know about this space? There's Modal, Daytona, Fly, Cloudflare, Deno, etc
These are all wrappers around VMs. You could DIY these easily by using EC2/serverless/GCP SDKs.
Many a time I have tried to figure a self scaling EC2 based CI system but could never get everything scaled and warm in less than 45 seconds, which is sucky when you’re waiting on a job to launch. These microvm as a service thingys do solve a problem.
(You could use lambda, but that’s limited in other ways).
Earlier quoted context omitted.
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 e…
Where would this happen? I have never seen an API reflect a secret back but I guess it's possible? perhaps some sort of token creation endpoint?
Earlier quoted context omitted.
Where would this happen? I have never seen an API reflect a secret back but I guess it's possible? perhaps some sort of token creation endpoint?
How does the API know that it's a secret, though? That's what's not clear to me from the blog post. Can I e.g. create a customer named PLACEHOLDER and get a customer actually named SECRET ?
Earlier quoted context omitted.
Is there a chance you could ask Ryan if he had an LLM write/rewrite large parts of this blog post? I don't mind at all if he did or didn't in itself, it's a good and informative post, but I strongly assumed the same while reading the article and if it's truly not LLM writing then it would serve as a super useful indicator about how often I'm wrongly making that assumption.
As someone that has a habit of maybe overusing em dashes to my detriment, often times, and just something that I try to be mindful of in general. This whole thing of assuming that it's AI generated now is a huge blow. It feels like a personal attack.