AI browser agents inherit everything

Of everything shipped under the agentic banner in the last two years, AI browser agents are the one that actually works on contact. There is no integration project. No API to wait on, no vendor connector, no procurement cycle, no engineering sponsor who has to be persuaded that your workflow is worth a quarter of their roadmap. The agent operates the software you already have, through the interface that software already exposes, using the session you are already logged into. That is not a small thing. Every enterprise runs on a long tail of internal systems — the claims tool, the old scheduling portal, the vendor console with four users and no support contract — that will never get a proper connector because the business case for building one will never clear the bar. A browser agent works against all of them on the first afternoon.

So the productivity case here is real, and it is the least inflated one in the category. This is not a pilot that produces a slide. People use these agents and immediately do less of the work they hated: the copying between two systems that will never talk, the fourteen-page report someone has to skim monthly, the reconciliation that exists only because two teams bought different tools in 2019. And the security framing that dominates the discussion is not wrong either. Prompt injection through hostile page content is a genuine attack class, demonstrated repeatedly, and anyone dismissing it as theoretical has not been paying attention.

But the conversation is aimed one level too low. The dominant framing treats the browser agent as software to be secured — sandbox it, filter the page, constrain the tool calls, scan the DOM for instructions. All of that is worth doing and none of it addresses the actual structure of what happened. An agent operating inside an employee's authenticated session is not software you deployed. It is an employee you onboarded without an onboarding. It inherits every permission that human accumulated over years — every system they can reach, every record they can pull, every action they are entitled to take — instantly, completely, and with none of the hesitation that was doing the real access control.

Reluctance was load-bearing

Enterprise access control has always been quietly over-provisioned, and it worked anyway. Everyone in the room knows this. The analyst has read access to the entire customer database, not just their accounts. The support lead can pull any ticket in any region. The finance associate can see every vendor record going back a decade. None of them ever did. Not because a control stopped them — nothing stopped them — but because there was no reason to, it would have taken an afternoon, and it would have felt strange. Someone might have asked why. That combination of incuriosity, habit, workload and social friction was not a policy. It was a property of human beings, and it was holding up a substantial part of the security model.

Nobody designed it that way. Nobody wrote down that the containment strategy for excessive permissions was that people are busy and mildly reluctant to do odd things. But every organisation depended on it, and the dependency was invisible precisely because it never failed. An agent has none of those properties. It is not busy. It has no sense that an action is unusual, no instinct that pulling ten thousand records to answer a question about one is disproportionate, no colleague who might notice. Ask it to reconcile a discrepancy and it will reach for everything the reconciliation could plausibly need, because that is the efficient way to answer, and efficiency is the only thing it optimises. It is not misbehaving. It is doing exactly what a diligent employee with no social awareness and infinite patience would do, which is a category of person the security model never had to survive. It is the same discovery organisations make when they automate a desk and find that half of what the person was doing had never been written down — the difference being that here the undocumented human contribution was restraint.

The permissions nobody tested

The consequence is that permission scope was never really tested. The gap between what an employee could access and what they actually accessed was enormous, and it was where all the slack in the system lived. Role definitions written in a hurry during a migration, inherited from a team that no longer exists, granted for a project that ended two reorganisations ago, never revoked because revoking things breaks people's Monday and nobody wants that call. These grants were not wrong in practice, because practice never reached them.

The agent collapses that gap to zero on day one. Not maliciously, and not through any breach — this is the part that makes it hard to see. Nothing was compromised. No control failed. The paper permissions are simply being exercised for the first time, at machine speed, by something with no reason to stay inside the informal boundaries the humans observed. If your access model has been carrying decades of accumulated over-grant, the agent is the first thing that will ever find out. It will find out on an ordinary Tuesday, in response to a reasonable request, and it will not tell you that it found out.

The log says you did it

Then there is the trail. Every action the agent takes carries the human's identity, because it is the human's session — the same cookie, the same token, the same name in the same field. From the perspective of every system involved, a person did this. That is fine on the day. It stops being fine six months later, when someone opens an access review, or an investigation, or a regulator asks what happened to a particular record between two dates.

You look at the trail and it is a person's name on every row. You cannot separate what that person decided from what the agent did in their name, and neither can they — they will remember approving something that week, roughly, in general terms. Attribution is the foundation underneath every access review, every investigation, every compliance response and every conversation that begins with someone asking who authorised this. It does not fail loudly. It quietly stops working, and you find out at the worst possible moment, which is the moment you need it. This is the shape we described in autonomy as a delegation problem: authority moves, and no record is kept of what moved. The person did not hand over a defined task. They handed over their identity, and the log has no field for the difference.

Session access is not API access

It is worth being precise about what makes this different from the integrations these organisations already run, because on the surface it looks like the same thing with a friendlier setup. An API integration has four properties that took years and several arguments to establish. It is scoped — it can reach these objects and not those. It is logged as itself, under its own identity, distinguishable from every human in the system. It is revocable in one place without disrupting anyone's day. And it was reviewed, by someone whose job it was to ask what this thing needed and why.

A browser agent in a live session routes around all four. It is scoped to the human, which is to say barely scoped. It is logged as the human. Revoking it means revoking the human or trusting them to uninstall something. And it was never reviewed, because there was nothing to review — no ticket, no design doc, no security questionnaire, no meeting. Here is the uncomfortable part: that is not a defect in the implementation. It is the reason adoption is instant. Every one of those four properties is friction, and the browser agent's entire value proposition is that it has none. The friction it removes is the governance. Nobody set out to bypass the controls; the bypass is the feature.

Injection is a symptom

Prompt injection fits inside this structure rather than sitting beside it. The agent reads a page and cannot reliably distinguish content from instruction, which means any page it reads can address it — a comment on a ticket, a line in a calendar invite, a support email rendered in a tab, a document someone outside your organisation controls. The reason that matters so much here is not the trick itself. It is that the thing being addressed holds a live, fully-permissioned session. Injection is how an outsider reaches the agent; inheritance is why reaching it is worth their time. We have treated the mechanism at length in the argument that injection is the capability, and the short version is that it is not a bug schedule to be worked through. Defend against it seriously, and understand that the defence is a mitigation on top of the real exposure, not a substitute for addressing it.

AI browser agents arrive anyway

None of this leads anywhere useful if the conclusion is prohibition, and we should be honest that prohibition is what most security teams will reach for first. It will not hold. AI browser agents arrive through individual employees, one extension and one personal account at a time, driven by people who are not trying to evade anything — they are trying to finish by six. The people adopting them fastest are usually the ones with the most tedious work and the least patience for a process that would take a quarter to say yes.

A ban does not remove the agent. It removes your visibility of the agent, which is the same outcome as doing nothing, with a policy attached that makes people quieter about what they are using. This is the shadow AI dynamic in its clearest form: what employees adopt without asking is information about what your systems fail to provide, and suppressing the signal does not remove the demand that produced it. The organisations that handle this well will not be the ones that said no. They will be the ones that noticed early and made the access legible.

Grade by reversibility

The question that actually sorts these situations is not whether the agent is capable of an action. It is capable of nearly everything the human is, and asking permission-shaped questions of an entity holding the human's permissions produces the answer yes. The useful question is whether the action can be undone, and whether you will know it happened.

Reading a record is recoverable — the information moved, which matters, but the world did not change shape. Updating a field is recoverable if you kept the previous value. Sending a message on someone's behalf is not recoverable at all; the recipient read it, and no amount of correction unreads it. Approving a request, releasing a payment, closing a case, submitting a filing — these leave marks the world keeps. That gradient is the real control surface, and it is the same one we drew around agents with spending authority: the irreversible action is the one that deserves the boundary, and the boundary should sit exactly there rather than being spread evenly across everything the agent might touch. Most organisations have never sorted their systems this way. It is a more useful afternoon than another round of policy language.

Provision for the task, not the person

What follows from all of this is unglamorous and mostly organisational. Treat agent access as a distinct identity with its own scope, rather than as a shadow of the employee's — even where the technology makes that inconvenient, and it will, because session inheritance is the path of least resistance and everything else requires deliberate work. Provision for the task the agent is doing, not for the person who happens to be logged in. The reconciliation agent needs two systems, not the eleven its operator can reach.

Insist on attribution in the log, and treat its absence as a finding rather than a limitation you live with. If a system cannot record that an action was agent-initiated, you have learned something important about which work should be running there. Grade the agent's reach by reversibility rather than by sensitivity classification, which tends to protect the confidential and ignore the irreversible. And run the access review you have been deferring for years — not as a compliance exercise, but because the agent is about to exercise every permission that review would have caught, and it will do so before anyone has scheduled the meeting. That review was always the right thing to do and never urgent. It is urgent now, and the reason is not that anything got less safe. It is that something finally showed up willing to use what you granted.

What you bought versus what you granted

The browser agent is worth adopting, and we would not tell a client to sit this one out. It does real work against systems that will never be reachable any other way, and the people using it are not wrong about the value. Just be clear about the nature of the transaction. You did not deploy a tool. You issued a credential — silently, to something that will use every bit of it, in a person's name, without ever wondering whether it should. The property that makes it so immediately useful and the property that makes it so hard to govern are not two things in tension. They are one thing seen from two sides. It works because it inherits everything. That is the whole feature, and it is the whole problem.