Your Agent Browses as You. Nobody Issued It a Credential.

The agent did not need your password. It already had your session.

On 6 August 2026 Cloudflare launched Kitesurf, a browser built for AI agents rather than for people, and free while in beta. It drops tabs, themes, extensions and pixel-perfect rendering, runs on Workers without Chromium, and in Cloudflare's own tests uses three to seven times less CPU and memory than Chromium on common agent tasks. It is also roughly 1.7 to 1.8 times slower on wall time, which Cloudflare states plainly rather than burying.

The performance numbers are what got written up. The design assumption underneath is more interesting, and Cloudflare states it plainly. The browser is built "on the assumption that every page load is untrusted input and every session starts fresh", and the piece doing the work is described as "an ephemeral, fully isolated, stateless engine designed to exist only for the duration of a task". Each page's cookies are kept in their own jar.

That is the precise opposite of the consumer agentic browsers, whose entire value proposition is that they run inside the profile you are already signed into.

What the inheritance actually is

When an agent drives your everyday browser, it does not authenticate. It arrives after authentication, in a context where every site you use has already decided who you are.

Brave's security team named the consequence in October 2025, in research covering several AI browsers: an agentic browser assistant "executes with the user's authenticated privileges", across a surface the researchers listed as banks, healthcare provider sites, corporate systems, email hosts and cloud storage.

Read that as an access control statement rather than a security warning and the shape of the problem changes. There is no credential. Nothing was issued, so nothing has a scope, an expiry, an owner or a revocation path. The permissions are the union of every session in the profile, granted implicitly and simultaneously, and they change whenever the human logs into something new.

The demonstration is on the public record. In August 2025 Brave documented a chain against Perplexity's Comet in which instructions hidden behind a spoiler tag in a Reddit comment executed when the user clicked to summarise the page. The agent read the user's email address from an account page, began a login, retrieved the one-time code from the user's Gmail, and posted both back to Reddit as a reply. Brave recorded a disclosure timeline running from 25 July 2025, an initial fix two days later, retesting that showed incomplete remediation, and public disclosure on 20 August 2025, with a later note that the issue persisted.

The researchers' conclusion was architectural rather than product-specific: traditional web security assumptions do not hold for agentic AI, and new security and privacy architectures are needed for agentic browsing.

Why better filtering is the wrong fix

The obvious response is to harden the boundary between the user's instruction and the page's content. That work is real and worth doing, and it is not the control that matters here.

Two pieces of this problem have been covered before and both sit upstream of the browser. Tool poisoning in the Model Context Protocol is about instructions arriving through a tool's own description, which is a supply question about what the agent is connected to. The guardrail layer built around a model is about validating what goes in and what comes out, which is a filtering question. A third piece, on where a long-running agent executes, is about placement: whose cloud, what network, which logs.

This is a fourth question and it is not answered by any of them. It is not what the agent is connected to, what it is told, or where it runs. It is whose identity it carries while it does the work.

Filtering fails safe only if the thing behind the filter is small. The reason a hidden instruction in a Reddit comment mattered was never the comment. It was that the process reading the comment could also read the inbox. Cut the reachable surface and the same injection produces a wrong summary instead of an exfiltrated credential.

The two architectures

There are only two, and the choice is per task rather than per product.

Cloudflare's browser lands on the right-hand column by construction, and honestly so. The company frames the absence of long authenticated sessions as a current limitation rather than a security feature, and treating it as a property worth choosing is our reading rather than the vendor's claim. The reasoning is simple enough. Most agent work on the open web is reading, and reading a public page does not require an identity at all. Attaching one to that work is a cost with no matching benefit.

What this means in regulated Australian work

The obligations here are ordinary ones arriving through an unfamiliar door.

An agent browsing inside a logged-in session can reach personal information the organisation holds, which engages Australian Privacy Principle 11. That principle requires an entity to take "such steps as are reasonable in the circumstances" to protect the information from misuse, interference and loss, and from unauthorised access, modification or disclosure. Australian Privacy Principle 11.3 adds that those steps "include technical and organisational measures", which is exactly where an access model for a non-human actor sits.

Australian Privacy Principle 6 is a separate obligation and it turns on purpose, not on location. Information collected for a primary purpose must not be used or disclosed for a secondary purpose unless the individual consented or one of the listed exceptions applies. An agent can move information somewhere new for the same primary purpose and engage nothing; it can also leave the information exactly where it is and engage the principle fully by using it for something else. Those are different tests, and an agent can fail the second while the first holds perfectly.

For entities regulated by the Australian Prudential Regulation Authority, be precise about where the obligation actually sits, because the binding standard does not use the phrase access management. CPS 234 paragraph 21 requires information security controls commensurate with the vulnerabilities and threats to information assets, their criticality and sensitivity, the stage at which they sit in their life cycle, and the potential consequences of an incident. The standard defines confidentiality as access being restricted only to those authorised.

The access detail sits in CPG 234, which is guidance and expressly does "not themselves create enforceable requirements". It is nevertheless the more useful document here, because it already contemplates non-human access. It records that access "is typically granted to users, special purpose system accounts, and information assets such as services and other software", and that an entity would typically ensure "identities and credentials are issued, managed, verified, revoked and audited for authorised devices, users and software/processes".

An inherited browser session fails that description on every verb. Nothing was issued, so nothing is managed, verified, revoked or audited, and there is nothing to put in front of a reviewer at recertification time.

Then there is attribution. If the agent acts as the human, the log says the human did it. That is fine until the day the record matters: a payment change, a record amendment, an access grant, a message sent. Reconstructing what actually happened after the fact, with no field distinguishing agent-initiated from human-initiated action, is the kind of evidence problem that turns a contained incident into a long one.

It also puts a person in an unfair position. An employee whose account performed an action they did not intend has no record to point at, because from the system's perspective there is nothing to distinguish the two cases. The organisation ends up arguing about recollection at exactly the moment it needs a fact.

TheAICommand works to the Verified Draft Method: de-identify the inputs, ground the model in your own source material, keep a person at the decision point, verify against the primary source, and log what happened. The last step is the one this article is really about. A log that cannot tell you who acted has not logged what happened.

A worked example

[TEAM] wants an agent to gather supplier information from public websites each week and produce a comparison for [OWNER_ROLE].

Run in the analyst's own browser, that agent has the analyst's mail, the finance system, the document store and the ticketing tool available for the entire session, none of which the task needs. One poisoned supplier page is enough to make that inheritance matter.

Run with its own identity, the same task looks different. The agent browses public pages with no session at all, because none of the source material requires a login. It writes its output to a single location using a credential issued for it, scoped to that location, held in the organisation's secret store, rotated on a schedule and revocable in isolation. The action of writing the file is attributed to the agent, on behalf of [OWNER_ROLE]. If the agent reads a page carrying hidden instructions, the worst outcome is a wrong comparison, caught by the person who reads it.

Nothing in the second version is exotic. It is the access model applied to a non-human actor, which is the thing that got skipped when browsing agents arrived as a consumer feature rather than an enterprise deployment.

The hype check

Two corrections in each direction.

Agentic browsing is not unusable, and the honest framing is a spectrum rather than a prohibition. Reading a page, filling a form on a low-consequence site, comparing options and drafting a summary are useful, and the risk is proportionate to what is open in the same profile.

Equally, none of this is solved, and Kitesurf is not a finished product either. Cloudflare describes it as twelve weeks old, with its first commit in May 2026, free while in beta and reached by adding a browser parameter to an existing Browser Run endpoint rather than installed as an application. A fresh-session agent browser is a good default for reading and a poor fit for the work people most want automated, which is exactly the work that requires a login. The identity model for agents acting on behalf of named humans is still being built, and anyone claiming a complete answer is selling one.

Do this Monday

1. Ask who is running an agentic browser. Not whether it is approved. Whether it is installed, and in which profile.
2. List what is signed in. Open the browser profile you would use and write down every service with an active session. That list is the current permission set.
3. Split the tasks in two. Reading the open web, and acting inside a system. Only the second needs an identity, and it should not be the human's.
4. Check one log. Take an action an agent could perform and see whether the record distinguishes the agent from the person. If it does not, that is the finding.
5. Give one agent its own credential. Pick the highest-value automation, issue a scoped credential, and confirm you can revoke it without logging anyone out.
6. Write the rule down in one line. An agent never runs in a profile signed into anything the task does not need. It is short enough to follow.

Bottom line

A browser session is a credential. It was issued to a person, for a person, by a process that assumed a person was driving, and an agent sitting inside it inherits every permission that person holds with no scope, no expiry and no separate name in the log. Cloudflare's fresh-session agent browser is worth watching less for its speed than for what it declines to carry. The control is not a smarter filter on what the page says. It is deciding, task by task, whether the work needs an identity at all, and issuing one properly when it does.

References

1. Cloudflare, Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers, 6 August 2026. https://blog.cloudflare.com/kitesurf/
2. Artem Chaikin and Shivan Kaul Sahib, Brave, Agentic Browser Security: Indirect Prompt Injection in Perplexity Comet, 20 August 2025. https://brave.com/blog/comet-prompt-injection/
3. Shivan Kaul Sahib and Artem Chaikin, Brave, Unseeable prompt injections in screenshots: more vulnerabilities in Comet and other AI browsers, 21 October 2025, updated 31 October 2025. https://brave.com/blog/unseeable-prompt-injections/
4. Privacy Act 1988 (Cth), Compilation No. 104, registered as C2026C00227, in force 4 June 2026, Schedule 1, Australian Privacy Principles 6 and 11. https://www.legislation.gov.au/C2004A03712/latest/text
5. Australian Prudential Regulation Authority, Prudential Standard CPS 234 Information Security, in force 1 July 2019, paragraph 21. https://www.apra.gov.au/standards/cps-234
6. Australian Prudential Regulation Authority, Prudential Practice Guide CPG 234 Information Security, June 2019, Attachment C. https://www.apra.gov.au/practice-guides/cpg-234