Sixteen thousand merges, blocked
How we organise
How we’re rethinking work at Cloudflare with Cloudflare OS (Cloudflare)
Cloudflare has published a first-person account of moving its whole workforce onto AI tooling. Every employee works in a browser-based workspace wired to internal systems over the Model Context Protocol. An agent there inherits the permissions of the person using it, not the permissions of the person who built it. Code-review agents flagged nearly a quarter of a million problems in four months, blocked 16,000 merges, and caught architectural issues in close to 600 designs before a line of code was written. Sales teams saved more than 10,000 hours in one month, and staff built over 4,000 apps and tools in 30 days. Cloudflare also names a failure of its own. Giving non-engineers the same tools with slightly friendlier interfaces produced what it calls a flood of vibe coded apps looking for a problem to solve.
Structure: Cloudflare did not stand up a central AI team. It put champions in each department and left the permissions to the platform. Those two designs fail differently. A central team owns the tooling and becomes the queue. Champions own the adoption, and that only works if the platform is already refusing what nobody should do. The observable is where the permission model lives. It sits in the platform, or it sits in the head of whoever configured the agent.
Ask this week which person’s permissions your agents run as. If the answer is the builder’s, the blast radius of every agent you run is the most privileged person who ever touched it.
How we build
The next generation of MCP (Cloudflare)
The initialize handshake and the session header are gone. Each request now carries its own protocol version, client identity and capabilities. The protocol is stateless. New Mcp-Method and Mcp-Name headers let a gateway route and police a call without reading the body. Tool catalogues can now be cached by the client across reconnects. Dynamic Client Registration is deprecated, and so are several older features, but a deprecated feature must stay available for twelve months before it can be removed.
Architecture: a stateless protocol with the method in the header turns central control of agent traffic into something you buy rather than something you build. The gateway can see which tool is being called, and by whom, without reading the body, so policy about agents becomes a decision the gateway takes at the ingress. Does your agent traffic pass through one ingress at all? Ask whether anyone can say how many tool calls left your network last week.
Find out this week whether agent calls in your estate pass any point where they could be counted. If they do not, no policy you write about agents is enforceable. We ask it first in any agent review.
On building scalable control planes (All Things Distributed)
Zak van der Merwe spent fourteen years building control planes for EC2 and DSQL. He argues the control plane is the part nobody budgets for and the part that decides whether a system scales. The data plane is the raw capability. The control plane is the conduit between that capability and the customer. Static stability is what he designs the control plane for: whatever happens to it, machines already running keep running. Splitting into availability zones shrank the blast radius of a single failure, because zones fail independently. Sharding further took years, because every place in the codebase that talks to the database has to know which shard to route to.
Engineering: the agent platforms being sold this year are control planes under a newer name, and they inherit the problem exactly. Ask whether your agent platform is statically stable, meaning agents already running survive an outage of the control plane. Most orchestration layers are not, and nobody finds out until the layer is down. Look at your last outage. Did work in flight carry on, or did it stop?
Put that question to your platform team this week. A team that has never tested what a running agent does when the control plane is unreachable does not know the answer.
How we assure
The Agent Access Model (Cloudflare)
Cloudflare proposes authorising every action against the task and its accumulated state rather than against the run. An identity broker issues short-lived credentials, a mediation layer enforces policy against them, and an activity log records what the agent did. The Trust Ratchet has no equivalent in current practice. Capability can only narrow within a task, so once an agent touches protected data the associated capability is removed and cannot come back. Restoring it means dispatching a new task that is freshly authorised. Cloudflare calls this a reference architecture rather than shipping software. It writes that it is not comfortable saying that multiplayer access control can be built end to end today.
Security: that last sentence is worth more than the architecture around it. A vendor that names the piece it cannot build has handed you a test for every vendor that names nothing. Sort your agent workflows into two groups: those serving one principal, and those serving several people who hold different permissions at once. The second group is the case Cloudflare says is unsolved. Few organisations can do that sorting at all, and that is the observable.
Take the agent with the widest access in your estate this week and establish whose permissions it holds. If it holds more than one person’s, you are already in the unsolved case.
Improving Fable 5’s biology safeguards (Anthropic)
Anthropic has rewritten the constitution behind Fable 5’s biology classifier and reports roughly 85 per cent fewer false positives on biology-related requests. The safeguards had shipped too broad. They were refusing legitimate questions. Dual-use professional biology and drug development queries stay blocked, and Anthropic says it intends to serve those through trusted access pathways instead. It also says false positives will inevitably remain, because some very low-risk requests fall inside the classifier’s safety margin.
Ethics: a refusal rate is a product decision with a number attached, and here a vendor has moved that number towards the user and published the move. The question it hands a buyer is whether you know your own refusal rate. Organisations running classifiers over internal traffic rarely measure how often they refused work that should have proceeded, because a refusal generates no ticket and no cost line. We would ask for that number before asking anything about the model.
Establish this week who hears about a refused request in your organisation. If the answer is nobody, your safety controls have no feedback loop and their cost stays invisible.