In a blog earlier this February, Snyk engineers said they scanned the entire ClawHub (the OpenClaw marketplace) and found that over 7 percent of the skills contained flaws that expose sensitive credentials. “They are functional, popular agent skills that instruct AI agents to mishandle secrets, forcing them to pass API keys, passwords, and even credit card numbers through the LLM’s context window and output logs in plaintext,” they reported.
OK, so we know OpenClaw is a security “Dumpster fire” right now, as we have reported.
I looked at Deno sometime ago; it treats TypeScript as a first-class citizen. I couldn’t help notice this detail in their recent Sandbox update:
You don’t want to run untrusted code (generated by your LLMs, your users’ LLMs, or even handwritten by users) directly on your server. It will compromise your system, steal your API keys, and call out to evil dot com. You need isolation.
Deno Sandbox gives you lightweight Linux microVMs (running in the Deno Deploy cloud) to run untrusted code with defense-in-depth security.
OK, sandboxes aren’t new, but Deno’s deployment environment caught my attention.
Deno and Deno Deploy
Well, it’s been a while since my last article about Deno and TypeScript, so I’ll speed through my example just to make sure I still remember everything before we check out the new sandbox stuff.
So let’s install Deno on my Mac. Fortunately, this looks the same as before:
As before, Deno correctly detected my shell. After restarting it, I checked everything was hunky dory:
So I’m not a TypeScript guy, and yet in that article, I wrote a bit of code to persuade myself that TypeScript is just looking at contents for equivalence. (Checkout the post for more on how an OOP developer can grok TypeScript)
class Car {
drive() {
// hit the pedal to the floor
}
}
class Golfer {
drive() {
// hit the ball far
}
}
// No error?
let w: Car = new Golfer();
So let’s do what we did last time and use a project initializer to run a TypeScript test.
I replace the main.ts with my drive method example from above, and run it:
So Deno handles my TypeScript as a first-class object, and proves it is a structural type system. But let’s get to the good stuff, and sign into Deno itself:
Before we can use a sandbox, we need to hop through a small verification hoop:
Don’t worry — it just checks your credit card exists, using the handy StripeLink that appears on your phone like a phishing request. Now we can set up — I’ll be following the right-hand column with code integration:
Now, we have the typical problem of connecting our identity to our requests. You can create a sandbox directly in code, which is neat — but first, we need a token.
So I’ll create an organisation token to connect my identity to Deno. I installed the SDK as the panel above suggested and created a token using the nice blue button. One small gripe here is that the terms “access token”, “organisation token”, and “deploy token” seemed to be used interchangeably.
OK, after setting the DENO_DEPLOY_TOKEN environment variable in my shell, we should be ready to run some code and create our very own sandbox on Deno’s cloud.
I save the following code as main.ts . I’m going to assume await is some sort of promise, as this is clearly asynchronous code. (The term “await” is also familiar enough in Victorian prose.)
import { Sandbox } from "@deno/sandbox";
await using sandbox = await Sandbox.create();
await sandbox.sh`echo "Hello, world!"`;
Remember to prove this happened, Deno will have to retain a record of the sandbox even after it has expired. As we are dealing with a security solution, we do need to tell Deno that we are happy use networking with the right flags:
OK, depending on how the statements are called, that appeared to work. Better proof must come in the appearance of the sandbox in my records:
We can see a little more detail in the instance from a nice filterable event log on the dashboard:
Well, that was just fine. I wrote some code on my laptop and ran it in a sandbox on Deno’s cloud. But we need to do a bit more to avoid the horrors of exfiltration.
Exfiltration shooter
What exactly is exfiltration? Of course, I could give the example of popular multiplayer games (you know them, or you don’t) whose very purpose is to appear as an avatar in the game server, steal things, then escape. This can happen accidentally in real life, too; you have seen this when the press manages to see notes a politician made in a private meeting, only to walk confidently outside, exposing the notes they are holding. In this case, the politician has misunderstood their safe boundaries—or has never used their camera’s zoom function.
This isn’t a security article, and I’m not Bruce Schneier — but you get the idea. You don’t want to run code in your cosy sandbox that captures and escapes with secrets. One way to combat this is to restrict exit points, but another is to obfuscate your private data while it resides within the sandbox. This is what Deno refers to as secret redaction and substitution.
Configured secrets never enter the sandbox environment variables. Instead, Deno Deploy substitutes them, only to reveal them when the sandbox makes outbound requests to an approved host.
I’ll show this process partway. We can set up a secret simply enough, and the approved host where it will be revealed to:
await using sandbox = await Sandbox.create({
secrets: {
ANTHROPIC_API_KEY: {
hosts: ["api.anthropic.com"],
value: process.env.ANTHROPIC_API_KEY,
},
},
});
So this means that the Deno will obfuscate the environment key that it finds in my laptop, but send it to Anthropic, revealed only after it leaves the sandbox:
I won’t make a real call to the LLM in the Sandbox (I certainly could, as I can access the Sandbox via the CLI and have it last for as long as I need), but I’ll set up a secret on my laptop environment as if I were:
And with my code altered:
I’ll run the code and see what the value of the secret is in the Sandbox:
As I said, to fully prove this, I’d have to contact Anthropic with my key to prove the process — but I’ll leave that to you.
From a Deno tutorial video. The diagram appears under the hosts as they demonstrate sandboxes.
Conclusion
I focused on just one aspect, obfuscation, but you can also control the allowed outgoing addresses just as easily. And we’ve already looked at other aspects of the Deno Deploy service.
Obviously, the timing couldn’t be better. With the exponential increase in generated and untrusted code (that people nevertheless wish to trust), this type of service is gold dust. I’m sure it will be appearing in different services pretty soon.
The post OpenClaw is being called a security “Dumpster fire,” but there is a way to stay safe appeared first on The New Stack.
Log in
