Cloudflare narrows an agent's authority by what it has already read, and an Australian directorate wrote a similar rule.
In August somebody on Cloudflare's sales team built a piece of software with AI and then asked for what it needed in order to run. The request covered production access to about a dozen systems, plus administrator permissions on a deployment pipeline. Sam Rhea, Cloudflare's chief information officer, wrote about it on 5 August and described two obligations the company was trying to hold together, giving people room to build while keeping the systems underneath them safe.
I want to be accurate because my own earlier notes were wrong. Rhea never records the request being refused. He uses it as the point where an existing problem became visible, which is more useful because the issue was larger than one employee asking for broad access.
Cloudflare OS launched the same day in a separate account by Phillip Jones and Dan Carter. Every agent and every application inside it begins with access to nothing. An agent asks for a specific resource, and that request can be granted or denied at the level needed for the job.
The component making that possible is called a Gatekeeper, a broker between the agent and the target system. An agent might get one GitHub repository rather than the account around it, then permission to read issues while source code stays unavailable. Individual fields can be masked, requests rate-limited, and a person can still be required before a pull request merges.
Two choices underneath that design matter more to me because they remove shortcuts that turn narrow policy into broad access. The Gatekeeper keeps the credential, so the API key never reaches the agent. Server code also runs with outbound networking switched off and reaches external services only through explicitly granted capabilities.
Rhea's fifth principle is the rule the design keeps returning to. Nobody should gain more permission with a system of record because they happen to be using AI. When he shares an agent with a colleague, that person authenticates through the same Gatekeeper with their own permissions rather than inheriting his, so the agent carries no authority of its own between people.
Cloudflare also records every resource an agent observes, and those observations stay attached to the agent and its work. When somebody else opens the workspace, the Gatekeepers compare that person's access with the resources the agent already read before showing the work. That same observation record can then narrow what the agent is allowed to do next. Reading sensitive data can prevent it from writing to certain places, inviting collaborators, handing the work to another agent or making an outbound request. The permission therefore changes because of what happened during the task, rather than staying fixed until somebody revokes it.
Cloudflare describes the mechanism and leaves the interpretation there. Mine is that authority contracts according to what the agent has already seen, so the grant depends on state as well as on the permission issued before work started. In Knowing when authority ends I looked at when permission should stop, and this gives another answer to that problem.
Expiry ends authority because time has passed or a transaction boundary has been reached. Cloudflare can narrow authority because the agent crossed an information boundary, which means the control responds to the path the work actually took rather than only to conditions known at the beginning.
On 15 September Cloudflare extended the same approach into Workers, its platform for running code. Four roles run from Metadata Read-Only through Content Read-Only and Editor to Admin, each assignable across the whole Developer Platform, one product or a single resource. The same structure applies to a person, a continuous integration token or an agent.
The role names matter less than the way one change can depend on authority over two separate objects. Changing a route requires Editor permission on the Worker and Workers Routes permission on the zone, so neither grant alone is enough.
Another detail in the same post looks smaller and matters more. When an API call is refused, the response includes a link from which the caller can identify the permission the action required. A scoped agent can fail, discover the missing permission and ask for that grant instead of receiving a wider bundle in advance. I think that is a control-layer decision. Over-broad access exists because people want work to continue and working out the smallest usable permission is slow, so service accounts get more than they need and keep it for years. Cloudflare has made denial informative enough to become part of how narrower authority is acquired.
None of that would carry far beyond Cloudflare if an unrelated authority had not arrived at the same rule.
Four days before the Workers update, the Australian Signals Directorate published separate guidance for executives and chief information security officers using agentic AI systems. It opens by stating plainly that the software layer connecting a model to its tools and systems is not inherently secure, then covers least privilege, identity and access management, monitoring, human approval for high-impact actions and staged deployment. It also complements earlier joint work with CISA and international partners, so the position is wider than one national agency.
The September update to Australia's Information Security Manual matters more here because it expresses those ideas as named controls. ISM-2133 gives each AI agent a unique identity. ISM-2134 requires a register of agents, while ISM-2135 specifies the owner, business purpose, identities, credentials, tools, permissions and data repositories that register should record.
ISM-2157 is the one that made me check the source twice. Tools invoked by an agentic application are subject to the access controls of the invoking user and to an agent-specific, task-scoped authorisation, with the effective permission limited to the minimum allowed by both. The person does not lend the agent everything they can do, and the task grant cannot exceed the person either. The system intersects the two.
That is very close to Rhea's fifth principle, reached independently by a national signals directorate. Cloudflare limits an agent through the person using it and the capability granted for the job. ASD arrives at the same shape from security practice.
ISM-2158 gives the comparison another layer. External content retrieved by an agent remains untrusted and cannot change or override access controls, tool permissions or human approval requirements. ASD is preventing newly observed information from expanding authority. Cloudflare uses newly observed information to contract it. That pairing is more useful than repeating that AI agents need least privilege. One design stops what the agent reads from giving it more authority. The other lets that observed world take authority away when the path through the task makes a later action unsafe.
Cloudflare is still describing its own system, which is the weakness this journal keeps running into with applied cases. Publishing the core and an example deployment as open source improves the evidence because the design can be inspected unlike a normal vendor case study. It still gives us no incident rate, defect count or independent measure of production failure.
ASD does not verify that Cloudflare's Gatekeeper works. It arrives independently at a similar control requirement, which is a different claim and a weaker one than verification. The manual is ASD's considered advice. Any obligation on Commonwealth entities comes through the Protective Security Policy Framework and the way organisations apply the ISM to their risk environment.
I would rather leave that distinction visible than turn advice into regulation because it makes the argument sound stronger. The argument survives. An operator built a system in which an agent begins with nothing and can lose authority as its information state changes. An unrelated security authority separately defined agent identity, task-scoped grants and an intersection between user and agent permissions.
The principle I would carry forward is narrower than least privilege. An agent's authority should depend on what it has already read as well as on what somebody granted before work started, because the path through the task can change what remains safe. That will cost money, create more ways for work to stop and make behaviour harder to predict from a policy document alone. I would like to hear from anyone running this kind of state-dependent control in production about what it broke, because that evidence is needed before the idea becomes a pattern.
Sources
- Cloudflare, Cloudflare OS: an open platform for agents, apps, and work, Phillip Jones and Dan Carter, 5 August 2026
- Cloudflare, How we're rethinking work at Cloudflare with Cloudflare OS, Sam Rhea, 5 August 2026
- Cloudflare, Give every teammate and agent the right level of access to your Workers, 15 September 2026
- Australian Signals Directorate, Agentic AI Harnesses, 11 September 2026
- Australian Signals Directorate, Guidelines for system access, Information Security Manual, September 2026 (ISM-2133, ISM-2134, ISM-2135)
- Australian Signals Directorate, Guidelines for software development, Information Security Manual, September 2026 (ISM-2157, ISM-2158)
The Cloudflare accounts are published by the company that built the systems described, alongside commercial material; no independent verification is claimed. Cloudflare OS is published as open source, so the design can be inspected, which is not the same as evidence about how it behaves in production. The prose was drafted with AI assistance. The research, verification and editorial decisions are the author's.