Browser and Computer-Use Agents: The Execution Layer Nobody Is Governing
When an employee grants a browser agent access to their browser session, they are not granting access to a single application. They are granting the agent every authenticated session currently open in that browser. The agent does not need to log into anything separately. It uses whatever session tokens, cookies, and credentials are already present across every tab, every system, every platform the employee stayed logged into.
The Layer Where Enterprise Work Actually Happens
The browser won a specific, consequential role inside the modern enterprise that has no parallel in any other layer of the software stack. It is where people log into business systems, review sensitive data, approve requests, move money, reset credentials, manage tickets, and coordinate with customers. It became the default delivery surface for enterprise software precisely because it required nothing of the organization except network connectivity and a human who could navigate it. The browser was designed around the assumption that a person would stay in the loop. A human would notice when something looked strange, hesitate before clicking, question an unexpected prompt, or stop before moving sensitive data from one context to another.
That assumption created a specific security architecture underneath it. Enterprise security controls were built around the idea that while attackers might try to get into browser sessions, the person sitting at the keyboard was a participant in those sessions, a collaborator in their own defense who would notice things that automated tools might miss. The security stack that grew up around the browser reflected this: network controls to watch what went in and out, endpoint controls to watch the device, identity controls to watch who logged in. All of it anchored to the presence of a human in the session who would catch what the tools could not.
That assumption has now been undermined in a specific and underappreciated way. Not by attackers alone, not by misconfigured systems, but by a category of AI tooling that enterprises are actively deploying: agents that take actions inside a live, authenticated browser session on an employee’s behalf.
Browser and computer-use agents represent a genuinely different category from every other AI agent type organizations have grappled with so far. An agent that calls an API through a gateway has a defined scope of access, scoped credentials, and an explicit integration contract. That access was deliberately provisioned, is recorded in an identity system, and can be audited, revoked, and scoped independently of the person who requested it. An agent that operates inside a browser inherits a scope of access that was never designed for it, never audited against it, and is effectively invisible to every security tool the enterprise already operates. The difference is not one of degree. It is a different architecture of access entirely.
The major agentic browser products shipping today are not obscure or experimental. They include offerings from multiple of the largest technology companies in the world, each approaching the category with slightly different architectures but sharing the core characteristic that matters for security: they operate inside the user’s authenticated browser environment, acting on the user’s behalf using the credentials and session state the user already established, and producing no authentication event that any downstream system would distinguish from the user acting directly. A user who stays logged into enterprise email, their CRM, source code repositories, internal HR systems, and financial platforms is giving a browser agent the ability to read and act across every one of those systems, simultaneously, without any of them ever seeing a separate authentication event for the agent itself. The agent inherits the trust the user built with those systems through their own authentication, without contributing any authentication of its own.
This is not a future concern about a category still in development. Independent research shows that more than four in ten enterprise employees are already using at least one AI web tool, with the average approaching two tools per person. The governance infrastructure that should surround a deployment of this scale does not yet exist in most organizations, and the gap between adoption and governance is growing faster than the governance is being built.
Why This Threat Model Is Different
Every AI security conversation of the last several years has focused on the model layer: what a model will and will not do, how to constrain its outputs, how to prevent jailbreaks and misuse through the interface. Browser and computer-use agents shift the threat model to an entirely different layer, and the security tools built for the previous conversation operate at the wrong abstraction entirely.
Consider what the standard enterprise security stack is actually watching. Secure web gateways monitor network traffic. Data loss prevention tools watch for files moving outside a defined perimeter. Endpoint detection tools look for process behavior on a managed device. CASB platforms monitor API calls to sanctioned SaaS applications. None of these tools sits at the layer where a browser agent operates. An agent reasoning about the content of an email it just read, composing a reply based on that content, and clicking send produces no unusual network traffic, no file movement, no anomalous process, and no API call that any of these tools would flag. From the perspective of every existing security control, the agent looks exactly like a busy, productive employee having a good day.
This is the precise problem the security community has named as the browser agent visibility gap, and it is distinct from every prior category of enterprise security blind spot. Previous blind spots involved things the security stack was not watching for because they were unexpected or novel attack vectors. This one involves activity that is not just unexpected but structurally invisible, because the control planes were designed to watch network packets and file transfers, not to observe what an agent is reasoning about and deciding inside an encrypted browser session.
The threat model underneath this has three components that interact in ways that make each one worse than it would be alone.
Session inheritance at scale. A browser agent does not need to authenticate to any system separately from the user. It operates using the session tokens and cookies the user established when they logged in. This means the agent’s effective access is not the access the organization granted to the agent, it is the access the organization granted to the employee across every system that employee is logged into simultaneously. In many enterprise environments, that is a remarkably broad surface for a single session to carry, because the browser became the universal client precisely because it made persistent, cross-application login seamless for humans. What made that seamless for a human makes it dangerous for an agent.
Same-Origin Policy collapse. Standard browsers enforce a security boundary that prevents a script running in one tab from reading data from a different domain in another tab. A browser agent undermines this boundary by design, because reading content in one authenticated tab and acting on it in another tab, across domains, is a normal part of its workflow. An agent that reads a sensitive financial document in one tab and reproduces part of its content in a different application open in another tab has crossed the boundary that Same-Origin Policy was designed to enforce, without triggering any violation that the browser itself would detect, because the agent is not a script running inside a page, it is the thing sitting above all the pages.
Indirect prompt injection through rendered content. An agent that browses the web processes the content it reads as instructions. Any website, document, or email the agent encounters that contains hidden text designed to override its instructions can hijack the agent’s behavior. A site that embeds text invisible to a human reader but present in the DOM, instructing the agent to take a specific action or to exfiltrate specific content, represents an attack vector with no analog in traditional web security. The agent’s own reasoning cannot reliably distinguish between legitimate instructions from its user and adversarial instructions embedded in content by a third party, because both arrive through the same channel and look, to the agent, like things it should pay attention to.
The provider with the most widely cited agentic browser product in this space has publicly acknowledged that prompt injection in agentic browsers may never be fully patched. This is not a vendor confession of negligence. It is an honest acknowledgment of a structural property of how these systems work: an agent that is useful precisely because it can read and act on content it encounters cannot be fully insulated from content that is designed to manipulate it.
The Security Stack Gap: Why Your Existing Tools Cannot See This
The browser agent visibility gap deserves its own section rather than being folded into the threat model, because it has a specific implication for how organizations should approach governance: the tools they already own are not going to solve this problem, regardless of how well they are tuned.
Secure web gateways and next-generation firewalls watch traffic. An agent operating inside an encrypted browser session, performing actions inside authenticated SaaS applications over HTTPS, generates traffic that is indistinguishable from normal, legitimate employee activity. The gateway cannot see what the agent is doing inside the session, only that encrypted traffic is flowing between a known endpoint and a known cloud application.
CASB platforms watch API calls to sanctioned applications. Browser agents do not use APIs. They use the same browser-based interface the human uses. A CASB tool monitoring a CRM’s API for data exports will not flag an agent that reads CRM data by navigating the UI and then pastes that data into an email, because no API call was ever made.
Endpoint detection and response tools look for anomalous process behavior. A browser agent running inside a sanctioned browser on a managed device does not produce anomalous processes. It produces normal browser activity at potentially higher volume and velocity, which may not trigger any alert threshold at all, because the threshold was calibrated for human browsing speed, not agent browsing speed.
Data loss prevention tools watch for specific content patterns crossing a perimeter. An agent that moves data within the perimeter, from one SaaS application to another, or that uses data from one context to inform an action in another without explicitly transferring a file, may never trigger a DLP rule. The data never left; the agent moved within it.
The practical implication is that the security controls organizations have invested in, and whose coverage they understand and trust, produce a false sense of coverage for browser agent deployments specifically. A security team that reviews the agent vendor’s certifications, confirms the agent’s data residency, and checks that existing controls are configured correctly has done everything the standard governance process asks for, and still has no independent visibility into what the agent is actually doing inside the session. That is not a failure of the security team. It is a structural gap in the available tooling that has not yet been closed at the industry level.
The emerging response to this gap is a category of tooling specifically designed for browser-layer visibility: session-aware monitoring that can observe what an agent is reading, reasoning about, and deciding inside a browser session, distinct from traffic-level monitoring. This tooling is early, and the enterprises furthest along in thinking about browser agent governance are treating it as a requirement rather than an enhancement. But it requires a different procurement conversation than the security tools already in place, and in most organizations that conversation has not started yet.
The Governance Failure Most Organizations Are Walking Into
The most consequential governance failure in this category is not a misconfiguration or a security architecture error. It is a classification error that most organizations are making before any specific deployment decision is made: treating browser and computer-use agents as productivity tools subject to standard software approval processes, rather than as enterprise execution infrastructure subject to the same governance rigor as any other system with broad access to sensitive data and the ability to take actions on behalf of employees.
The distinction matters because the procurement and approval processes for productivity tools are not designed to ask the questions this category requires. A standard software approval process asks whether the tool is from a reputable vendor, whether it stores data in compliant jurisdictions, whether the vendor has relevant certifications, and whether it integrates with existing identity systems. These are legitimate questions, and browser agent vendors can generally answer them satisfactorily. But they are not the questions that govern the actual risk: what authenticated sessions can this agent reach, what actions can it take using those sessions, how would the organization know if it took an action it was not supposed to, and who is responsible when it takes an action that causes harm.
None of these questions are unusual or unreasonable to ask. They are exactly the questions a security team would ask before granting a new employee access to the systems a browser agent inherits on day one. The gap is that they are not being asked of the agent, because the agent arrives through a software approval process designed for tools, not for principals with access.
This misclassification produces a specific downstream failure that is now well documented across organizations that have deployed browser agents: the discovery, usually after deployment, that the agent has access to systems the organization never intended to include in its scope, because nobody mapped the authenticated session surface before deployment began. An employee who is logged into twenty enterprise systems when they open their browser has just given a browser agent access to twenty enterprise systems, and in most organizations that fact will never appear in any access control review, any privilege audit, or any identity governance report, because the agent’s access is not recorded as an identity event. It is recorded as a user event, because from the perspective of every downstream system, it was the user.
The longer-term consequence of this misclassification is a governance debt that compounds silently. Every week that browser agents operate in an environment without session surface mapping, access scoping, and session-layer visibility is a week during which the true scope of agent access grows as employees authenticate to additional systems, as IT provisions new SaaS applications, and as the organization’s authenticated surface expands through normal business activity. The organization’s exposure is not static; it grows with the organization’s footprint, and the governance infrastructure needed to contain it needs to be designed to grow with it rather than to capture a snapshot of a moment that has already passed.
What Most Teams Get Wrong
The most common mistake is the sequencing error: deploying the agent first and designing the governance second, usually triggered by the first incident rather than by proactive planning. Browser agents are widely available as browser extensions or standalone products, are straightforward for individual employees to install and use without any IT involvement, and produce immediate, visible productivity benefits that create organizational momentum toward wider adoption before any governance conversation has started. By the time a security or platform engineering team is asked to govern the deployment, the deployment is already widespread and the session-inheritance problem is already present at scale.
This sequencing error is more consequential for browser agents than for most other AI tools because of how access accumulates. With a text generation tool or a coding assistant, the worst outcome of ungoverned deployment is usually data exposure through the tool’s own data retention practices. With a browser agent, ungoverned deployment means an unknown number of agents have been granted an unknown scope of access across an unknown set of enterprise systems, because each employee who installed the tool brought their own authenticated session surface into scope without any inventory or access review. Reconstructing that picture after the fact is both expensive and incomplete.
The second mistake is trusting agent-side controls as a substitute for architectural controls. The browser agent vendors offer controls: session limits, action approval workflows, content filters, logging capabilities. These are real and worth configuring. They are not sufficient substitutes for the more fundamental question of what the agent can reach, because they operate inside the agent’s own trust boundary. A vendor’s logging capability tells an organization what the agent did according to the agent. It does not independently verify what the agent had access to or audit what it chose not to log. Relying on these controls without independent session-layer visibility is equivalent to relying on a contractor’s own self-reported activity log as the sole record of what they did inside a facility.
The third mistake is treating this as a purely security problem and assigning it entirely to the security team. The governance question for browser agents is as much an identity and access management question as it is a security question, because the core issue is that a new class of principal, the agent, is acquiring access through a channel, session inheritance, that was never designed to be governed. Addressing that requires changes to how organizations think about access management, not just changes to their security monitoring. Security teams cannot solve an identity architecture problem with monitoring tools alone, however sophisticated.
The fourth mistake, and the subtlest one, is treating the agent’s productivity benefit and the agent’s governance cost as separate conversations to be had in sequence: demonstrate the value first, then figure out how to govern it. This sequencing is intuitive and almost always wrong. The governance cost is not separate from the productivity benefit; it is the engineering work required to capture the productivity benefit without incurring the access risk. Teams that separate these conversations reliably end up in a position where the agent is widely adopted, the productivity benefit is visible and politically entrenched, and the governance conversation is now happening against a backdrop where restricting the agent means taking something away from people who have come to depend on it. That is a much harder conversation than the one that happens before deployment.
A Governance Framework for Browser Agent Deployments
The organizations that are furthest along in deploying browser agents safely share a consistent structural approach that can be described as four sequential controls, each of which enables the next.
Map the session surface before any deployment. Before a browser agent is authorized for any employee, the organization needs an honest inventory of what authenticated sessions that employee typically carries at any point during their workday. This is not a one-time exercise; it reflects the real surface the agent will inherit and should be specific to role, because a software engineer’s authenticated session surface is materially different from a finance team member’s. The inventory is the foundation for everything else; without it, access scoping is guesswork.
In practice, the mapping exercise usually produces a number that surprises the teams doing it. Most employees in knowledge-work roles carry between fifteen and thirty simultaneously active authenticated sessions at any given moment, spanning email, calendar, messaging, project management, code hosting, HR, finance, CRM, and various internal tooling. Every single one of those sessions is in scope for a browser agent that has access to the session profile. Seeing that number written down in an inventory, before authorizing a deployment, changes the conversation about what governance is needed in ways that an abstract “the agent inherits your sessions” statement usually does not.
Scope agent access below the natural session surface. The governance target is not to allow the agent access to everything the employee is authenticated to and then try to monitor what it does with that access. It is to constrain the agent to a deliberately smaller surface than the user carries, so that the agent’s access is proportionate to the tasks it has been authorized to perform rather than proportionate to wherever the employee happened to be logged in on a given day. This requires either dedicated browser profiles for agent sessions, which prevents the agent from inheriting unrelated authenticated sessions, or session-aware controls that prevent the agent from reading or acting on specific categories of content even when the authenticated access technically permits it.
The dedicated browser profile approach is the more architecturally sound of these two options, because it solves the inheritance problem structurally rather than relying on real-time content filtering to catch problems after access has already occurred. An agent running in a clean browser profile, authenticated only to the specific applications it has been authorized to access for the specific task it has been assigned, cannot reach the other twenty-four authenticated sessions the employee carries, because those sessions do not exist in the profile the agent is running in. This approach costs more in setup and operational overhead than simply giving the agent access to the employee’s existing browser session, and it is the right cost to incur.
Establish session-layer visibility as infrastructure, not monitoring. The goal is not to monitor what agents do after the fact and investigate anomalies. It is to have continuous, independent visibility into what agents are reading, reasoning about, and deciding inside browser sessions, in real time, as a baseline capability before any incident occurs. This is the control plane that every other governance function depends on, and it is the specific gap that existing security tools do not fill. Organizations that invest in this visibility before an incident are in a fundamentally different position than organizations that invest in it after one.
Treat agent access as an identity event. Every browser agent session that operates on an employee’s behalf should be recorded as a distinct identity event with its own audit trail, separate from the employee’s own activity record. This does not require inventing new infrastructure; it requires extending existing identity governance frameworks to include agent principals rather than treating agent activity as a subset of user activity. The practical implication is that when any downstream system asks “who accessed this data and when,” the answer should be able to distinguish between the employee accessing it directly and an agent accessing it on their behalf. The organizations that will be prepared for the regulatory and legal questions this category will eventually generate are the ones that built this distinction into their audit trail from the start, not the ones trying to reconstruct it from logs that were never designed to answer the question.
Where This Is Heading
Gartner’s published position on agentic browsers, recommending that enterprises block all agentic browsers until enterprise-ready versions with adequate governance controls are available in general release, is a notable data point not because it represents the permanent correct answer, but because it represents how seriously a leading analyst firm believes the current governance gap is, measured against the current state of organizational readiness.
That gap is real and it is closing, but it is closing unevenly. The vendors building agentic browser products are actively shipping governance capabilities: dedicated enterprise modes, session isolation features, centralized management consoles, and logging pipelines that organizations can connect to existing SIEM infrastructure. These capabilities exist today and are meaningfully better than what was available even a short time ago. At the same time, the session-layer visibility tooling that organizations need to independently monitor agent behavior is still early, and the identity governance frameworks that need to extend to cover agent principals have not been updated to do so in most enterprises.
A related development worth watching is the emerging category of what some vendors are calling guardian agents: purpose-built agents whose job is to supervise the behavior of other agents, monitoring their actions, enforcing access policies, and intervening when an agent’s behavior deviates from its authorized scope. This is an interesting architectural response to the browser agent governance problem, because it attempts to solve a session-layer visibility problem with an agent that operates at the same layer where the visibility gap exists. The approach has genuine appeal, and it also introduces a recursion problem that the industry has not yet resolved: the guardian agent is itself an agent operating inside the same session environment, inheriting the same access characteristics, and subject to the same prompt injection vulnerabilities as the agent it is supervising. Whether the governance value of having a supervisor agent outweighs the additional surface it introduces is a question worth tracking rather than answering definitively today.
The organizations that will navigate this transition well are the ones that treat it as an architecture problem from the start rather than a monitoring problem after the fact. The session inheritance issue is not solved by watching what an agent does with broad access; it is solved by not granting broad access in the first place, by building dedicated agent session environments that are scoped to the tasks the agent has been authorized to perform and isolated from the full authenticated session surface an employee carries. That architectural choice is available today, costs more than the defaults, and is the single most consequential governance decision an organization makes about browser agent deployments.
The alternative is a deployment model that is convenient, fast, and likely to produce the incident that triggers the governance conversation the organization should have had first. The security community’s current framing of browser agents as a “block until ready” problem is not permanent. It is a gap between what these products can do and what organizations have built to govern them doing it. Closing that gap is engineering work, and the organizations that treat it that way will be the ones using this category at scale while others are still debating whether to allow it.
A final note on timing: the governance infrastructure required for browser agents does not need to be complete before any deployment can proceed. It needs to be honest. Organizations that know exactly what authenticated surface a deployed agent reaches, have session-layer visibility into what it does with that access, and have an audit trail that records its actions as a distinct identity, can deploy and learn from browser agents productively. Organizations that have none of those things and deploy anyway are not moving faster; they are just delaying the moment of reckoning to a point where they will have less control over its timing and consequences than they do today.