MicrosoftAvailable
SC-300
We Built an Agent That Broke All of Our Security Rules
Token built a browser agent that broke its own rules on identity, scope and traceability. The lessons apply to any browser agent that borrows a human session.
Short answer: A browser agent that works inside a user's logged-in session looks identical to that user, so the app cannot tell who acted or what the task allowed. There is no patch to install. Inventory your browser agents, narrow their reach, and require step-up approval for sensitive actions.
Browser agents that act inside a logged-in session look exactly like the user to the application. That is the main lesson from Token's write-up, published by The Hacker News on Nov 11, 2026. There is no CVE and no patch. The fix is a set of controls you apply yourself.
What Token built and what went wrong
Token tells customers three things about AI agents. They need their own identities, access that fits the job, and traceability separate from any human's. Then Token built an agent that broke all three by default.
The agent is called Rehearsal. It answers questions inside the Token platform by doing rather than telling. It opens pages in the browser tab, sets filters, and fills in forms.
Rehearsal runs in the user's browser, so it runs in the user's session and has their reach. To the server, its clicks are indistinguishable from the user's. Nothing in a session cookie shows who is driving.
Who is affected
Anyone whose staff use agents that act through an authenticated session. That includes agentic browsers, agentic extensions, and endpoint agents. The risk grows with each SaaS app those sessions can reach, such as a CRM or a cloud console.
The app cannot tell the agent is there. The agent cannot tell which field holds a secret or which button deletes a record. The session carries only the user's identity.
How serious it is
This is a design gap, not a bug with a severity score. Token's own warning is that agents are arriving faster than the standards. The risk is misuse of privilege: an agent can do anything its user can, and your logs will blame the user.
The standards below are drafts or early features. Check the W3C and IETF pages for their current status before you rely on them.
What the browser and web lanes cover today
Lane | What it does | Gap |
|---|---|---|
Chrome auto-browse | Needs approval before high-stakes actions such as payments or mass emails. Limits the agent to sites the task requires. Tags visited pages in history. | Neither Chrome nor Edge describes how to tell the app on the other end. |
Microsoft agentic browsing | Admins enable it per site and can pause it before passwords and card numbers. | Same gap: the app is not told. |
WebMCP (W3C community group draft) | Sites expose actions as tools and flag each as read-only or consequential. | Tools run with the user's rights, so reach is not narrowed. |
Web Bot Auth (IETF working group draft) | A site can verify which agent sent a request. | Does not cover delegation, so the person is omitted. |
Token's conclusion is that every agent lane should carry three signals. These are the agent's identity, a verifiable link to the person it acts for, and a scope narrower than that person's.
What to do now
Waiting for standards is not an option. Start with discovery, then constrain, then audit.
Inventory browser agents, agentic extensions, and endpoint agents that can act through authenticated sessions. Map each to users and owners.
Trace every consumer of each agent, meaning the people and other agents using it.
Review every identity each agent can reach.
Identify attack paths where an agent could bypass access controls.
Require explicit approval or step-up authentication, such as a passkey prompt, before sensitive or irreversible actions.
Ask critical SaaS vendors whether audit records separate agent activity from human activity, and whether they support task-scoped delegation.
Commands to see what is installed
These list Chrome extension IDs on a single machine. Match the IDs against the Chrome Web Store to spot agentic tools.
# Linux
ls ~/.config/google-chrome/*/Extensions
# macOS
ls ~/Library/Application\ Support/Google/Chrome/*/Extensions# Windows
Get-ChildItem "$env:LOCALAPPDATA\Google\Chrome\User Data\*\Extensions" -Directory | Select-Object FullNameIf you use Microsoft Defender for Endpoint, this advanced hunting query counts extensions across your fleet:
DeviceTvmBrowserExtensions
| summarize devices = dcount(DeviceId) by ExtensionName, ExtensionId, BrowserName
| order by devices descA worked example
Say an agent extension helps a sales rep clean up CRM records. It clicks Delete on the wrong record. Your CRM log shows the rep deleted it.
With a step-up rule, deleting a record triggers a passkey prompt. The agent cannot pass it, so a person must confirm. You cannot yet tell who clicked, but you can choose which clicks need a human.
If you build the agent yourself
Token shows what is possible when you own both sides:
Dim and lock the application while the agent moves, and show who has control.
Record every move for each session, including blocked ones.
Reduce the agent's reach below the user's. Rehearsal keeps dashboards read-only, saves nothing without approval, skips secret fields, and never sends a call the platform has refused.
Read the page through accessibility labels so the agent understands controls.
Until browsers and apps can carry identity, delegation, and task scope together, treat every agent using a human session as delegated access. Discover it, constrain it, and audit it.
What IT and security learners can take from this
This story is a clean example of identity and least privilege applied to a new kind of actor. Practice separating the agent's identity from the user's and scoping each to the task. The SC-300 exam guide covers identity fundamentals, and the SC-100 guide covers architecture-level decisions. For a broader security-architecture credential, see the CompTIA SecurityX CAS-005 voucher.
Source: The Hacker News.
Sources
Questions about this topic
Is there a patch for this problem?
No. It is a design gap in how agents use human sessions, not a software flaw with a fix. You reduce risk through inventory, narrower access, step-up checks, and vendor questions.
Why can't an app tell an agent from a user?
The agent acts inside the user's authenticated session. The session cookie carries the user's identity and nothing about who is driving, so the server sees ordinary user clicks.
What is a step-up check?
It is an extra verification before a sensitive action, such as a passkey prompt. An agent cannot complete it alone, so a person has to approve the action.
What are WebMCP and Web Bot Auth?
WebMCP is a draft from a W3C community group that lets sites expose actions as tools, marked read-only or consequential. Web Bot Auth is an IETF working group draft that lets a site verify which agent sent a request.
What should I ask my SaaS vendors about agents?
Ask whether audit records distinguish agent activity from human activity. Also ask whether they support task-scoped delegation, so an agent gets less access than the person it works for.
