Today we are releasing Cloudflare OS, a chatbot with connectors, just like every other tech company is doing. Except actually, it's different. This is a remake of Sandstorm[.]io, my startup from 10 years ago, except this time built on Cloudflare Workers (the platform I've spent the last 9 years building) and deeply leveraging AI. This is more or less the culmination of my secret 10-year master plan. This is a full-on personal app vibe coding platform, in which the sandbox is so secure that you can pretty much go wild -- the AI cannot introduce a significant security bug. We believe a company's security team can feel comfortable giving non-technical users permission to vibe code and then sleep soundly at night. How is that possible? It's the Sandstorm security model, revisited. A "Gadget" is the same thing as a Sandstorm "Grain": a fine-grained app instance. For example, if you have a document editor app, each document runs as a separate instance of the app, in a separate sandbox (one "Gadget"). This means two things, both of which I think are Big Deals: 1. The platform can manage all access control, by controlling who can access the Gadget at all. There is no way the Gadget can accidentally leak itself to an attacker -- even an attacker who has access to other Gadgets based on the same app. 2. Since everyone is running their own copy of the code, everyone can freely *modify* their copy of the code. Think about #2# a bit more. What if, when you wanted a new feature in the software you are using, you could just prompt your agent to add it? This doesn't work in the cloud Software-as-a-Service model, because you are not running your own copy of the app. Sandstorm tried to change that 10 years ago, but the world wasn't ready, because not enough people had the skills or patience to actually modify their software. AI has changed that. Now you just ask the agent -- the same agent that you are using to help you interact with the Gadget can also modify the code of the Gadget. And it is so fun.

Building software by prompting agents without ever reading or editing the code directly isn't actually a new thing. It's just called being an engineering *manager*. We have decades of experience about how to be effective as engineering managers. It is a different skill, though.

I actually think this is the wrong approach to agent authorization. Here's why: If you have to explicitly configure each agent's permissions, you've lost. Because you're only going to have patience to configure so many agent permissions. So in this route you can only have a certain relatively small number of agents before configuration fatigue prevents you from making more. I don't think that's what we want. I don't think that's what's good for AI safety. What we want is an enormous number of very fine-grained agents. Each task is a new agent. And each task has exactly the permissions needed for that task, no more, no less. There's really only one known way to make that manageable: Capability-based security. The basic idea is, when you give the agent a task, you naturally give it the capabilities it needs to perform that task. Like say you want an agent to review a Google Doc. Today, with a lot of AI assistants "Hey go review the document titled Foo Spec". The agent has permissions to all your docs, so it goes and finds the right one and opens it. That's wrong. You should say "Hey, go review this document: " And then here's the key part: The harness should see that you're pasting a URL, and should infer that you want to give the agent access to that document. Only that document. No other document. Importantly, you didn't really have to do anything unusual to configure this. You just pasted the URL of the thing you wanted the agent to access. Which you probably would have done anyway. Sure, it's not always that easy. Maybe you commonly run agents that need access to 10 different things, and it's tedious to paste those 10 URLs every time. So you create some sort of a bundle that you give them. And of course, the agent should be able to ask for extra things it needs. But we need to get away from this idea that the agent always starts out with access to everything, even when it doesn't need most of it. Also, I tend to think all agent authority has to derive from a human -- contrary to what is argued here. Every "autonomous agent" has to report to someone, and uses a subset of that person's authority. This is needed for accountability -- because agents are not accountable. If you see "Claude deleted the database", what are you supposed to do about that? You need to see "Claude acting on behalf of Bob deleted the database". To be clear, I totally agree that it's problematic when Alice configures an agent with her own credentials and then Bob tells the agent to do something with those credentials. Then you'll see "Claude acting on behalf of Alice", but actually Claude was acting on behalf of Bob. The answer is that Bob should not be able to command Alice's agent. Bob has his own agent, which may have all the same context, but operates with Bob's credentials. But if Alice sets up an agent for her team, Bob maybe doesn't want to spend time configuring his own version of it with all the same credentials, that's tedious. This has to be automated. I think capabilities make this easier. Alice gave a set of capabilities to her agent. The harness should be able to look at that list, and recreate the same list using Bob's credentials, without Bob having to do much except click "OK". I realize there's a lot of hand-waving here -- this is a complicated topic. I'll drop some code next week. If you're attending AI Engineer in SF, come to my talk on Tuesday, where I will also only be able to scratch the surface in 20 minutes...