Can your security team identify which AI agents are currently operating within your workforce's browsers? If an agent began automating tasks this morning, would defenders recognize it as something other than legitimate employee activity? The reality is that most organizations cannot answer these questions. This gap reflects not inadequate security effort, but rather the pace at which artificial intelligence has shifted from providing answers to executing actions.
Agents now run browser automation inside authenticated corporate applications through multiple mechanisms: debugging interfaces, browser extensions, purpose-built agentic browsers, and emerging standards such as WebMCP. Each method determines what data an agent can reach, how its actions appear in logs, and whether conventional security controls can detect them.
1. Remote Debugging: Applications Controlling the Browser
The Chrome DevTools Protocol (CDP) represents one established path for agent-driven browser control. Originally designed to enable developers to inspect, debug, and automate Chromium-based browsers, CDP grants programmatic access to navigation, page content, network activity, and user interactions. Libraries such as Playwright and Puppeteer have leveraged this capability for years. AI agents now use identical techniques to browse websites, retrieve information, populate forms, and operate web applications.
The critical detail: automation need not run from within the browser itself. An external application can establish a connection to a browser running with debugging enabled and command its tabs. When that browser maintains authenticated sessions to corporate systems, the automation inherits that access.
To most security monitoring tools, a browser instance launched with debugging enabled and logged into business applications appears indistinguishable from a standard authenticated session.
The relevant questions for defenders: What applications possess the ability to launch or connect to debuggable browsers? Do organizational policies permit this behavior? Which authenticated corporate sessions can those applications reach?
2. AI Extensions and Agentic Browsers
A second mechanism embeds the agent directly within the browser itself.
Browser extensions including Claude in Chrome can read page content, navigate between tabs, trigger button clicks, and execute multistep workflows. These capabilities demand extensive permissions: scripting access, tab manipulation, and debugger API calls. While these permissions enable the intended functionality, they simultaneously broaden what an extension can observe and control.
Agentic browsers such as Perplexity Comet and ChatGPT Desktop embed AI capabilities directly into the browsing interface itself. These integrated features may operate outside the permission framework that governs traditional extensions, potentially bypassing existing extension-based controls.
Without a complete inventory of browser types deployed across your infrastructure, visibility into active agents remains limited. Two particular risks emerge.

First, agents operate using the authenticated user's identity. When an agent retrieves a document or modifies a setting within an internal application, the receiving system observes an authenticated user performing an authorized action. Without supplementary logging and monitoring, neither the application nor its audit trail may distinguish between actions taken by the agent and those initiated by the employee.
Second, agents process content as input data. While browsers display pages for human interpretation, agents read those pages and determine subsequent actions. This creates exposure to prompt injection attacks, where instructions embedded in websites, documents, or messages attempt to manipulate agent behavior. The result is software interpreting untrusted content while holding trusted permissions.
3. WebMCP: Websites Exposing Tools Directly to Agents
A third approach restructures how websites communicate with agents.
WebMCP is an emerging web standard developed through the W3C Web Machine Learning Community Group, with involvement from Google and Microsoft. Rather than requiring agents to interpret pages and simulate clicks, websites can expose structured tools that agents invoke directly.
As an example, instead of navigating through a support portal and completing form fields, an agent could call a tool to generate a support ticket. Chrome introduced an early preview in 2026, and the standard specification remains under development.

This approach introduces a distinct trust challenge. Websites now define not just content but the actions agents can perform.
Tool names, descriptions, and input specifications guide agent behavior. These definitions originate from the website and must not be assumed trustworthy. A compromised or hostile site could employ deceptive descriptions or unexpected functionality to influence agent decisions.
Each tool operates within its website's security boundary, yet agents operating across multiple sites can transfer information between them. The risk extends beyond what a single tool accomplishes to encompass what corporate data an agent transmits when invoking it.

The critical question: Which corporate data can agents send to website tools, where does that information travel, and can your organization control which tools agents are permitted to use?
What This Means for Browser Security
All three mechanisms share a fundamental characteristic: software executes actions on websites using the access privileges tied to a user's browser session.
This reality demands that browser security abandon the assumption that a human operator initiates every action. Endpoint, network, and application controls remain relevant. However, these controls were engineered to observe processes, network traffic, and authentication events—not to track what an agent reads, decides, and executes within an authenticated browser tab. This represents the current visibility gap.
The objective is not to prohibit employees from adopting AI agents. Agents will become routine in how work is performed. Rather, the objective is ensuring that existing browser security controls continue to function when an agent, rather than a human, operates the browser.