Tweet by KentonVarda
April 17, 2026
It's kind of crazy how much of the way we've been designing Workers over the past 9 years unexpectedly turns out to be so relevant to AI and agents. Durable Objects and lightweight isolate sandboxes are obvious big things. But there are subtler things. Consider "bindings". In Workers, our environment (`env` object) doesn't just contain strings. It can contain live objects, which we often call "bindings". For instance, a Workers KV binding is a live object representing a Workers KV storage namespace. Once you've configured it, you can just do: let val = await env.MYKV.get("foo") await env.MYKV.put("foo", "new value"); Notice: There's no connection string. No secret token that you have to pass to talk to your KV namespace. The Workers Runtime handles it for you. You just get an already-initialized client object, on which you can call methods. You can still do everything you want to do. But you know what you can't do? Leak the secret token. Because there isn't one. A KV namespace binding fundamentally cannot be "leaked" because it's not bytes. But over the years, a lot of people have questioned whether this really mattered. I've had people inside and outside the team say: "Why are you so weird, Kenton? Yeah sure it can't leak but now I have to learn this new way of thinking about things. No other runtime works this way so writing portable code takes extra work. I'd rather just stick to what I'm used to, and anyway I know better than to leak my environment variables." Well, now we have AI agents writing the code and... suddenly everyone is worried about agents leaking keys. People are creating convoluted schemes to intercept the outbound traffic and inject keys in a proxy, or trying to issue very-short-lived keys so that if the agent leaks them the window of attack is short. Ahem. Welcome, folks! We solved this 8 years ago! Here's an old blog post -- written when I personally was still very much Not Thinking About AI -- which seems so much more relevant now: https://t.co/hHfMQpu4FH
- Author
- KentonVarda
- Date
- April 17, 2026
- Canonical URL
- /tweets/kentonvarda-2045195153044828481-bcf31d