The Brief 40
The Same-Origin Policy Just Failed. Nobody’s Talking About Why.
A thirty-year-old browser boundary broke in four of seven agentic browsers the same week a password-spray campaign walked through legacy Azure authentication. Two attack surfaces. One root failure. The authority gap, demonstrated twice in seven days.
Four Agentic Browsers Just Broke a Thirty-Year-Old Security Boundary
In 1995, browsers adopted a rule so foundational that most of us have never had to think about it: a website you open in one tab cannot reach into another. Your bank stays walled off from the sketchy blog you clicked from a search result. That wall is called the same-origin policy, and for thirty years it has been one of the quiet load-bearing pillars of the entire web.
This week, University of Washington researchers showed that four of the seven major agentic AI browsers on the market — ChatGPT Atlas, Chrome with Gemini, Claude for Chrome, and Perplexity Comet — have already broken it. They built a working exploit against Atlas: one site reaching through the agent into another site’s data, straight through a boundary the browser was supposed to enforce.
Only one browser tested held up cleanly: Firefox AI Mode. It also had the least capability of anything in the study. That’s not a coincidence, and it’s not really a solution either — it’s a tradeoff, and it’s the same tradeoff every agentic deployment in your enterprise is quietly making right now, whether your security team has named it or not.
Azure CLI Password Spray: Same Week, Same Root Failure
Look past the browser story for a second, because the same week produced a second one that looks unrelated and isn’t. A password-spray campaign against Azure CLI compromised at least 78 accounts across 64 organizations, exploiting legacy authentication flows still sitting next to modern conditional access policies.
Different attack surface. Identical root failure.
In both cases, something got authenticated once — a login, a credential — and was then trusted to act correctly for the rest of its session, indefinitely, with no further check on what it was actually doing at the moment it did it. The Azure accounts that got compromised weren’t using broken credentials. They were using real ones, just ones nobody re-validated past the point of first use.
The Industry Is Circling the Gap. Nobody Is Standing In It.
To be fair to the industry, everyone is circling this. OWASP published its Top 10 for Agentic Applications built around identity and tool use instead of the classic network perimeter. The Department of War’s April guidance is pushing least-privilege and signing controls into procurement requirements. NIST’s COSAiS initiative is drafting control overlays specifically for single- and multi-agent systems. These are not nothing. They’re the industry correctly diagnosing that something has changed.
But diagnosis isn’t the same as a cure, and almost every proposed fix still operates at the wrong layer — hardening the login, tightening the perimeter, adding another identity check at session start. None of them answer the question that the UW researchers and the Azure CLI campaign both just demonstrated in the same week: what happens between authentication and the action, at the exact moment the action is attempted?
That’s where the gap opens. That’s where it stays open, unless something is checking authority at execution time, per action, not per session.
Why This Keeps Happening
It keeps happening because almost every security control built over the last two decades — SSO, MFA, conditional access, session tokens — was designed to answer one question: is this the right identity logging in? None of them were built to answer a second, harder question that agentic systems now force onto the table: is this identity authorized for this specific action, right now, given everything that’s changed since it logged in?
An agent’s authorization doesn’t stay constant across a session the way a human’s does. It shouldn’t. A procurement agent that’s authorized to read vendor invoices is not automatically authorized to approve a wire transfer, even if it’s the “same” authenticated session doing both. A browser agent authorized to summarize a webpage is not automatically authorized to carry data across an origin boundary because a prompt buried in that webpage told it to. But almost nothing in production today re-checks that distinction at the moment it matters. It checks once, at login, and then extends trust forward on autopilot.
“Two independent incidents surfaced the same gap in the same week, from two completely different directions. That’s not a coincidence. It’s what happens when an industry builds its defenses around a question — who logged in — that autonomous systems have already made obsolete.”
This is the authority gap, and I’ve been naming it in this brief since Issue 1: authentication and authorization are not the same fact, and treating them as though they are is the single most exploitable assumption in agentic security today. I’ve been writing about this convergence for going on four months. This week it stopped being a thesis and started being two headlines.
If your organization has agentic browsing enabled for research, procurement, CRM, or any workflow that touches sensitive systems, the question worth asking your team this week isn’t “did the agent log in correctly.” It’s this:
“What, specifically, stops this agent from doing something it was never authorized to do, the moment it tries — not the moment it started?”
For most environments right now, the honest answer is: nothing does. The session that logged the agent in is standing in for authorization it was never actually asked to prove, action by action, for as long as that session lasts. If your team can’t name the control that closes that gap, you’ve found this quarter’s priority.
The AGS Score is a structured self-assessment of your organization’s execution-layer authority posture — where agent directives are validated, where they aren’t, and what that exposure looks like at renewal.