The Agent That Logs In As You: Why Browser Agents Break Every Control You Just Built

Two announcements landed four days apart in late July, and read together they describe a fork in how AI agents are going to get access to systems. On 28 July at Black Hat, Snowflake announced the Cortex AI Gateway, a centralised gateway for the Model Context Protocol that enforces identity, policy and audit at the level of the individual tool call, with Agent Identity reaching general availability alongside integrations with Okta and 1Password, plus a preview capability for detecting data exfiltration triggered by AI agents. On 30 July, Google announced that Gemini Spark could operate the desktop version of Chrome directly, and from 3 August it began rolling out in the United States. The Google announcement is explicit about what that means in practice: with permission, Spark can use your logged-in accounts and your saved passwords to run errands such as scheduling apartment viewings or starting a flight booking. One of these models gives the agent an identity of its own. The other gives the agent yours.

That distinction is not a detail, and it is not a criticism of either product. It is the whole architecture. Under the delegated model, an agent is a principal. It gets credentials that are separate from any human, its permissions can be scoped narrowly, its actions carry a distinct identifier through every log it touches, and when something goes wrong you can revoke it without disturbing a single person. Under the session inheritance model, none of that exists, because there is nothing to issue. There is no OAuth grant to review, no token to rotate, no service account to name, no SCIM record to deprovision, no entry in the application inventory. The agent operates inside a session that a human already established, on a device the human already owns, using a credential store the human already unlocked. From the perspective of every system further down the chain, no agent is present at all.

Consider what that does to your evidence. A staff member enables the feature, the agent visits your CRM or your finance tool or your ticketing system, and the access log records a successful authenticated request from a known user on a known device inside a normal session. The user agent string is Chrome, because it is Chrome. The IP address is whatever it always is. Conditional access policies pass, because the conditions genuinely are met. Anomaly detection has very little to work with, since the only signals that separate an agent from a human are pacing and volume, and a well behaved agent doing three errands looks quieter than a person catching up on a Monday. If you are asked six months from now to prove who performed a particular action, the honest answer is that a person authenticated and something took an action in that session, and you cannot narrow it further.

It is worth being fair about the safeguards, because they are real and the design choices are sensible ones. Google states that Chrome is protecting against threats such as prompt injection, and that sensitive actions including payments are handed back to the person rather than completed by the agent. Handing back payment authority is exactly the right instinct, and it reflects a vendor that has thought about the failure mode. But the risk that changed here is not likelihood, it is blast radius. Prompt injection defences reduce how often a hostile page succeeds in redirecting an agent. They do not change what that agent can reach when one does, and what it can reach is now every session the person has open and every credential the browser has stored. A defence that works ninety nine times out of a hundred behaves very differently when the hundredth failure has the keys to the entire estate rather than to one sandboxed browser instance.

The two models are going to coexist, and the uncomfortable part is the difference in how they arrive. The delegated identity model comes through procurement. Somebody evaluates it, security reviews it, an architect designs the policy, and it lands in a change record with an owner. The session inheritance model comes through a consumer subscription and a toggle, and it arrives on the endpoint. Google is simultaneously extending Google AI Pro to more than a hundred and sixty additional countries, which means the population able to switch this on is expanding faster than most internal review processes can track. This is the shape shadow IT has taken all year. It is not somebody signing up for an unapproved SaaS product. It is somebody enabling a capability inside a product you already approved, and the capability quietly changes the security properties of everything the browser can see.

Map that onto the frameworks and the gaps are not subtle. ISO 27001 Annex A control 5.17 concerns authentication information and the expectation that credentials are not shared, and a feature whose stated function is allowing software to use your saved passwords deserves a considered position rather than silence. Control 5.15 on access control and 5.16 on identity management both assume that access can be attributed to an identity, which session inheritance defeats by design. The SOC 2 common criteria in the CC6 series carry the same assumption, since CC6.1 through CC6.3 describe registering, authorising and restricting identities, and an unattributable actor inside an authorised session is a genuine question for an auditor rather than a theoretical one. If any part of your business handles cardholder data, an agent operating a browser near a checkout flow raises PCI DSS scope questions that are much easier to answer before an assessor asks them. And under ISO 42001, this is an AI system operating on company data, which means it belongs in the AI system inventory whether or not anybody procured it.

The compliance automation platforms will not catch this for you, and it is important to understand why rather than assuming a connector is missing. Vanta, Drata, Secureframe, Sprinto and Thoropass build their monitoring on the systems that hold structured records: the identity provider, the MDM fleet, the cloud accounts, the code repositories, the HR system. Their coverage is genuinely good because those systems emit events. A browser capability enabled by an individual under a personal subscription emits nothing any of them can subscribe to. There is no app grant in the identity provider, no new SaaS tenant, no OAuth consent event, no billing line on the company card. The control here has to be authored deliberately as a policy statement with an owner and a review cadence, and the evidence for it has to come from browser management rather than from an integration.

The practical work for this month is short and mostly consists of deciding things rather than building them. Establish your position first and write it down, because the answer that a browser agent may never touch a work session is a legitimate one, and so is the answer that it may, provided the browser profile it runs in holds no production credentials. Enforce whichever answer you choose through Chrome enterprise policy on managed devices rather than through an email asking people to be careful. Separate work and personal browser profiles properly, so that a capability enabled in one cannot reach sessions established in the other. Review what your password manager actually exposes to the browser, since 1Password and its peers are now on both sides of this question, appearing as an integration in the agent identity stack and as a credential source in the session inheritance stack. Update the acceptable use policy so it addresses agents acting as a person rather than only addressing which AI tools are approved, which is the distinction most policies written last year missed. Then add the capability to the AI system inventory you are already maintaining for ISO 42001, the EU AI Act, or the Australian automated decision making disclosure that commences in December.

The governance question of 2026 was never really whether AI agents would be allowed inside the business, because that was settled the moment tools such as Cursor and GitHub Copilot became normal and the productivity case stopped being arguable. The question that matters now is whose identity the agent wears while it works. Every serious enterprise control we have built over two decades, least privilege, segregation of duties, attribution, revocation, non repudiation, rests on the assumption that an actor can be named. Delegated agent identity preserves that assumption and is worth the effort it costs. Session inheritance quietly removes it, in exchange for a genuinely delightful user experience, on a device you manage, through a toggle you did not review. Both futures are shipping right now. The organisations that stay in control of this will be the ones that noticed the fork in the road while it was still four days of news, and chose a side on purpose.