Agentic browsers — Atlas, Comet, Dia — are already on devices in your organisation. Some are managed. Many are not. Employees are installing them for the same reason they adopted every other productivity tool before it became official: it makes their work easier and no-one told them not to.
The question is whether you govern that adoption or let shadow AI answer it for you. Shadow AI is already embedded in how people work, and ungoverned agentic browsers mean zero telemetry, zero policy, and no incident response capability. That is a worse outcome than controlled deployment.
This playbook gives you a four-stage framework — Assess, Pilot, Govern, Monitor — built for companies with 50–500 employees and no dedicated SOC. It covers an acceptable use policy template, sandboxed pilot design, least-privilege configuration, SIEM telemetry integration, human-in-the-loop controls, shadow AI discovery, and a numbered incident response playbook for browser-agent compromise. It is part of a broader series on browser-agent security overview; the attack surface this playbook addresses — prompt injection and link-mediated exfiltration — is covered in the companion article.
Blocking outright requires full endpoint control. And most companies with 50–500 employees simply do not have it. BYOD devices, contractor laptops, and unmanaged endpoints create gaps that no EDR or secure web gateway can close without enterprise-grade MDM — and most lean IT functions have not deployed it. Obrela recommends blocking agentic browser binaries for regulated sectors, but acknowledges that approach requires exactly the endpoint control most SMBs lack.
The deeper problem with blanket prohibition is what happens when it fails. Employees who adopt agentic browsers without governance produce the worst possible outcome: no telemetry, no logging, no policy guardrails, and no incident response capability. Cisco researchers found that 26% of agent skills analysed contained at least one security vulnerability — and those are the skills employees are pulling from unvetted registries.
The practical answer is controlled adoption with governance gates. Zero Trust architecture frames this well: treat every agent action as potentially untrusted, apply least privilege, and minimise the blast radius of any compromise. The incidents this controlled approach would have mitigated are real.
The first stage — assessing your current exposure — starts with knowing what is already installed. The discovery methods in the shadow AI section below are your starting point. For context on the full threat landscape this playbook is designed to address, the pillar article in this series maps all six attack surfaces.
A sandboxed pilot is a time-bounded deployment to a small, well-defined user cohort using non-production data and isolated system access. The goal is to validate your governance controls before you expose the broader organisation. Diana Kelley from Noma Security puts it well: “Don’t try to boil the ocean: start small, learn fast, and let the guardrails evolve.”
Here is how to structure it.
Who is in the pilot. Pick 5–10 people from a low-risk function — research, marketing, communications. Technically confident enough to report unexpected behaviour, but not connected to production systems or regulated data. Giskard’s analysis of Atlas explicitly recommends isolated testing environments with non-production data.
What the pilot environment must not touch. No access to internal applications holding customer PII, financial records, or production databases. Enterprise-managed options (Edge for Business, Island) are worth considering here — they provide centrally managed policy controls and MDM integration that consumer agentic browsers lack, which matters a lot when your IT function is lean.
Telemetry before the first user session. Get logging in place before anyone opens the browser. Agent activations, action types, cross-domain navigations, and content uploads must all be captured from day one. Retrofitting telemetry after deployment creates blind spots. Do not do it.
The phased timeline. Run weeks 1–4 in restricted read-only agent mode with no autonomous actions. From weeks 5–8, allow low-risk agent actions with human-in-the-loop confirmation on everything else. Disable agent/action mode by default — explicit opt-in per task, not a persistent session.
Exit criteria. Define these before the pilot starts. Close the pilot when: zero uncontrolled data exfiltration events have occurred, telemetry coverage is 100%, and all pilot users have completed AUP training — not on a calendar date. Tooling to support these controls is covered in the companion article.
An AUP for agentic browsers needs to exist before rollout, not after your first incident. A generic “AI usage policy” will not cover it. SentinelOne makes this point directly: confirm your policy addresses autonomous agents, not just chatbots.
Keep it to two pages maximum. Extend your existing IT acceptable use policy with agentic browser-specific clauses rather than building a parallel document. Nobody reads parallel documents.
Here is a template structure with eight numbered policy clauses:
Scope. Which agentic browser products are covered. Which user groups are authorised. Which devices are permitted. If a product is not on the approved list, it is not sanctioned.
Agent-mode activation. Agent/action mode must be explicitly activated per task. The default state is disabled. No persistent agent-mode sessions.
Prohibited uses. No automation of internal production systems without written approval. No agent access to customer PII, PHI, or PCI data outside the sandboxed pilot. No connecting agents to financial transaction systems.
Data handling. No pasting of classified or regulated data into agent prompts. No uploading internal documents to agent memory. Clear browser memory after sessions involving sensitive workflows.
Human oversight. All high-risk actions require human confirmation before execution. Users must not leave agent sessions unattended during autonomous workflows.
Logging and audit. All agent sessions must generate telemetry. Users must not disable or circumvent logging. Sessions are subject to periodic audit review.
Incident reporting. Any unexpected agent behaviour must be reported immediately through your existing incident reporting channel. Users must not attempt to resolve agent misbehaviour themselves.
Policy violations. Align consequences with your existing IT AUP. First violation triggers a review. Repeated violations result in access revocation.
Review this policy quarterly — a policy written in Q1 can have gaps by Q3 as new products and capabilities arrive. Set update triggers for material new releases or major public incidents. Compliance frameworks these controls satisfy are covered in the compliance article in this series.
Least-privilege access means disabling everything by default and enabling capabilities per workflow. Simple as that. The more permissions the agent has, the larger the blast radius of any compromise. Giskard’s analysis of Atlas confirms that in agent mode, a successfully injected instruction can propagate across multiple authenticated sessions and domains before detection.
Five specific configuration steps:
Disable autonomous action by default. Require explicit opt-in per task. No persistent agent mode.
Restrict agent scope to approved domains. No open-web navigation during agentic sessions. If the agent does not need to visit a domain to complete the task, it should not be able to.
Block agent access to local file system, environment variables, and developer tools. Most productivity use cases do not require these, and they are common targets.
Enforce enterprise SSO and MFA for any agent session that touches internal systems. Consumer agentic browsers often retain data indefinitely and rely on users to manage privacy settings — do not depend on user-managed defaults.
Separate agentic browsing from sensitive browsing. Do not allow agent-mode sessions to run in the same context as sessions accessing production systems or regulated data.
There is also a DLP gap worth flagging. Most data loss prevention tools were built for files and emails, not dynamic browser action content. PII, PHI, and PCI data flowing through agent prompts is a leakage vector that traditional DLP misses entirely. Extend DLP controls to cover agent prompt inputs, not just file uploads.
Agentic browser telemetry is the stream of structured events — agent activations, action types, data uploads, cross-domain navigations — that feeds your monitoring and detection stack. You do not need an enterprise SIEM to get started. Lightweight open-source options like Wazuh or Security Onion work fine. The requirement is simply that telemetry is collected at all.
Six specific signals to capture:
Agent activation events. When agent/action mode is turned on, by which user, on which device, at what time.
Action type logging. What the agent did — form submission, navigation, file upload, API call — with timestamps and target URLs.
Cross-domain navigation. When the agent navigates from an approved domain to an unapproved one. High-priority alert signal.
Content upload volume. Large or unusual data uploads during agent sessions.
Human-in-the-loop bypass events. Any override or dismissal of a confirmation prompt during a high-risk agent action.
Session duration anomalies. Unusually long sessions, or sessions outside business hours.
Four example alert rules:
Noma Security’s Agentic Risk Map visualises all AI agents in an organisation — useful alongside your SIEM. Zenity’s Correlation Agent surfaces manipulation attempts and reduces investigation time.
Human-in-the-loop (HiTL) controls require explicit human confirmation before the agent executes high-risk or irreversible actions. Treating this as a binary toggle — on for everything, or off for everything — either paralyses productivity or removes oversight entirely. You need a tiered decision framework.
hCaptcha tested five major browser agents on 20 common abuse scenarios and found these products attempted nearly every malicious request with no jailbreaking required. Vendor-native HiTL controls are immature. So use external controls — browser extension policies, proxy rules, SIEM alerts — to enforce confirmation requirements until vendors build more granular options.
A three-tier classification:
Always require confirmation (high-risk): Financial transactions. Form submissions to external services. Access to internal systems with customer data. Credential entry or OAuth authorisation. Any first-time action in the pilot.
Require confirmation on first use, then allow (medium-risk): Navigation to approved external domains. Content summarisation of non-sensitive pages. File downloads from known sources.
Allow unattended (low-risk): Read-only browsing of public web content. Search queries. Navigation within a single approved domain.
“High-risk” means anything that could result in data exposure, financial loss, or a compliance issue if the agent acts incorrectly. Without a dedicated SOC, that definition should be inclusive — when in doubt, require confirmation.
Schedule quarterly reviews of what sits in the “allow unattended” tier. Agents gain capabilities, and autonomy creep is a real problem — actions that were safe six months ago quietly stop being safe. A quarterly review keeps your HiTL controls calibrated. Compliance frameworks these controls satisfy are addressed in the compliance article in this series.
Shadow AI discovery is not a one-time exercise. Even after rollout, new tools appear on devices without going through the adoption process. You cannot govern what you cannot see. Zenity automatically identifies Atlas, Comet, Dia, and other agentic tools across managed and unmanaged devices if you want automated discovery. If you do not have an enterprise endpoint agent, here are five lightweight methods.
Network proxy and firewall log inspection. Look for outbound connections to known agentic browser API endpoints — api.perplexity.ai, chatgpt.com agent endpoints, Dia browser service domains. Even a basic firewall can log these.
Browser extension audit. Query managed devices for installed browser extensions associated with agentic browsing capabilities. Chrome enterprise management or basic UEM can enumerate extensions without additional tooling.
UEM/MDM device inventory. Query for installed applications matching known agentic browser binaries — Comet, Atlas, Dia, Fellou — on managed devices.
User survey. Direct outreach asking what AI tools teams are using. Position this as governance enablement, not an investigation — honest responses come when people believe the goal is to help them use tools safely.
DNS query monitoring. Monitor DNS requests for agentic browser service domains. Lightweight, does not require deep packet inspection, and surfaces both managed and unmanaged device activity.
When you find shadow AI, the governance response matters as much as the discovery. The goal is to transition from unsanctioned to sanctioned usage, not to punish early adopters. Employees who self-adopted are often your most productivity-motivated people — alienating them does not serve anyone.
Create a self-service adoption request process: if an employee wants to use an agentic browser, submission triggers a vendor due-diligence check and AUP acknowledgement. This channels shadow AI into the governance framework. How prompt injection creates these risks is covered in the prompt injection article in this series.
This is a numbered incident response playbook, not narrative framing. Prompt injection is unlikely to ever be fully solved — OpenAI acknowledges this about Atlas. What you can control is response speed and damage containment. Real-world examples of these risks illustrate what this playbook addresses.
Terminate the active agent session — close the browser, revoke the session token, or kill the process.
For managed browsers (Edge for Business, Island), use the admin console to remotely terminate. For unmanaged browsers (Atlas, Comet), instruct the user to close all windows and disconnect from the network.
Do not continue using the browser to investigate. The agent may still be acting on the injected prompt.
Pull telemetry from your SIEM or XDR for the compromised session: action log, navigation history, content uploads, form submissions.
Identify what the agent did — which domains it navigated to, what data it accessed, what it uploaded or submitted. Look for indicators of prompt injection: unexpected external navigation, form submissions the user did not initiate, data uploads to unfamiliar endpoints.
If the agentic browser retains persistent memory across sessions — Atlas and Dia both do — clear the agent’s memory store. An injected prompt can persist into future sessions if memory is not purged.
Delete browser memory, conversation history, and cached context associated with the compromised session. Verify the clearing was successful — some products require multiple steps or admin-level access to fully purge persistent context.
Priority order: (1) OAuth tokens or API keys the agent used; (2) SSO session tokens; (3) passwords for any service the agent logged into; (4) shared credentials the agent may have accessed.
Scope this to every system the agent navigated to, plus any system where those credentials provide access. If the agent operated within enterprise SSO, invalidate the user’s session and force re-authentication across all connected services.
Map the exposure: open tabs, page content, local files (if file system access was available), clipboard contents, form field data, and internal application screens. Zenity Labs notes that agentic browsers often hold deep access to local files, cloud sessions, and developer environments — the scope can be wide. This inventory feeds directly into Step 6.
GDPR trigger: if the agent accessed or exfiltrated personal data of EU residents, a 72-hour breach notification clock may start — consult legal counsel.
HIPAA trigger: if the agent accessed protected health information, breach notification obligations apply.
SOC 2 trigger: if the agent accessed systems in scope for a SOC 2 audit, document the incident for the next audit cycle.
Without a compliance officer in-house, engage external legal counsel if any regulated data was in scope. GDPR and SOC 2 obligations are covered in the compliance article in this series. Obrela’s compliance framing for browser-agent incidents is a useful reference.
Identify the specific prompt injection vector — malicious webpage, email, document, or another external input.
Reproduce the injection in the sandboxed environment to confirm mitigation. Update the AUP and HiTL controls based on what the incident revealed. Brief the team without blame — prompt hygiene training requires real examples to stick. Open-source tools for red teaming and detection can support the exercise.
An agentic browser embeds an LLM directly into the browsing environment, enabling it to autonomously navigate, submit forms, and execute workflows. A regular browser with AI add-ons provides suggestions and summaries but does not take autonomous action. That distinction matters. The agent can take actions the user did not explicitly initiate, across any authenticated session it can reach — which is a fundamentally different class of risk.
Potentially yes. GDPR and HIPAA apply regardless of whether a human or an AI agent took the action — the organisation is still the data controller. Giskard’s analysis of Atlas recommends treating consumer agentic browsers as out of scope for regulated data until enterprise-grade audit and identity management are in place. Detailed treatment of liability is in the compliance article in this series.
At least eight weeks — four of restricted read-only usage followed by four of graduated autonomy with HiTL controls. The pilot closes when exit criteria are met (zero exfiltration events, full telemetry coverage, all users AUP-trained), not on a calendar date.
No. Lightweight open-source options like Wazuh or Security Onion work fine. Even basic syslog forwarding is better than no monitoring. The requirement is that telemetry is collected at all. Enterprise platforms add correlation and automation, but they are not prerequisites.
Enterprise secure browsers (Island, Microsoft Edge for Business) provide central policy control, MDM integration, and administrative audit capabilities. Consumer agentic browsers prioritise AI capability and user experience but lack enterprise governance features — policy management, audit logging, and MDM all fall back on your IT team, which adds real overhead to a controlled pilot.
You cannot fully prevent it on unmanaged devices. Make the sanctioned path easier instead: provide a governed option through the pilot programme, a self-service adoption request process, and an AUP with clear expectations. DNS and proxy monitoring gives partial visibility.
Prompt hygiene is awareness of what context, data, and instructions go into the AI agent — the same concept as phishing awareness training applied to LLM interactions. Noma Security’s CISO guide covers the core points: never paste sensitive data into agent prompts, verify agent actions before confirming, and report unexpected behaviour immediately.
Check your telemetry for: unexpected cross-domain navigation, form submissions the user did not initiate, data uploads to unfamiliar endpoints, sessions outside business hours, and OAuth token generation linked to non-standard applications. The SIEM integration section above provides specific alert rules.
Start with an enterprise-managed option (Edge for Business, Island) if central policy control and MDM integration are priorities. Evaluate consumer agentic browsers (Atlas, Comet) only within the sandboxed pilot and only after governance controls are in place.
At minimum: (1) an AUP covering agent-mode usage, (2) basic telemetry via firewall logs or lightweight SIEM, (3) DNS monitoring for known agentic browser endpoints, (4) browser extension audit capability, and (5) an incident response playbook. No enterprise EDR, CASB, or SASE required. Start with what you have and build from there.
Six Demonstrated Exploits That Prove Agentic Browser Security Is Not TheoreticalWithin 24 hours of ChatGPT Atlas launching in beta, security researchers had demonstrated successful prompt injection attacks against it. Working exploits on a live product within a single day. That pattern defines agentic browser security in 2025 and 2026.
An agentic browser is a browser with an LLM-powered assistant that takes autonomous actions on authenticated sessions: reading email, summarising documents, executing transactions. The security problem is that the same content the assistant reads to help you can contain attacker-authored instructions that redirect it. This is how indirect prompt injection works architecturally — and it is the root cause behind every exploit documented here.
What follows is the complete chronological evidence record: six publicly documented, researcher-attributed attacks against six products in six months, August 2025 to February 2026. For the full browser-agent security overview, see the pillar article.
Six publicly documented, researcher-attributed exploits across six different products in six months. That is the incident record.
The timeline: Brave Security Research disclosed the first agentic browser vulnerability against Perplexity Comet (August 2025) via screenshot-based OCR injection. In October 2025 they followed up with Fellou (trusted-content navigation injection) and Opera Neon (hidden-HTML element injection). ChatGPT Atlas launched in beta that same month and was promptly exploited. Miggo Security disclosed a semantic attack against Google Gemini via calendar invites in January 2026. Microsoft Defender Research published findings of AI Recommendation Poisoning deployed commercially by 31 companies across 14 industries in February 2026. PromptArmor and Cisco Talos disclosed zero-click data exfiltration against OpenClaw via Telegram link previews the same month.
Every incident shares the same architectural root cause: the LLM treats attacker-controlled content as trusted user instruction. Artem Chaikin and Shivan Kaul Sahib of Brave Security Research put it plainly: “Fundamentally, they boil down to a failure to maintain clear boundaries between trusted user input and untrusted Web content when constructing LLM prompts while allowing the browser to take powerful actions on behalf of the user.”
Two of the six incidents involve commercial-scale exploitation, not researcher proof-of-concept. OpenAI CISO Dane Stuckey was equally direct: “Prompt injection remains a frontier, unsolved security problem, and our adversaries will spend significant time and resources to find ways to make ChatGPT agent fall for these attacks.”
Brave Security Research — Artem Chaikin, Senior Mobile Security Engineer, and Shivan Kaul Sahib, VP Privacy and Security — disclosed the first publicly documented agentic browser vulnerability against Perplexity Comet in August 2025, with a follow-up published October 21, 2025.
The attack mechanics behind this exploit are straightforward once you understand them. Malicious instructions are embedded as near-invisible text within a web page — “faint light blue text on a yellow background” — imperceptible to human eyes. When a user takes a screenshot, OCR extracts the hidden instructions and passes them to the LLM. The LLM has no way to distinguish extracted text from the user’s own query. The injected commands direct the AI to use its browser tools maliciously while the user sees nothing suspicious.
Because the agent operates with the user’s authenticated session, injected commands inherit access to whatever the user is logged into. Brave noted that “simple natural-language instructions on websites (or even just a Reddit comment) [can] trigger cross-domain actions that reach banks, healthcare provider sites, corporate systems, email hosts, and cloud storage.”
Two principles from this disclosure recur across every subsequent incident: the attack surface is not the product code but the content the browser processes, and traditional input sanitisation cannot detect instructions embedded in images.
Two months later, Brave Security Research disclosed two further vulnerabilities: Fellou (discovered August 20, disclosed October 21) and Opera Neon (disclosed October 31 after Opera requested a delay pending patching).
Fellou had the widest attack surface of the three Brave disclosures. The browser treated all visible webpage content as trusted LLM input on navigation alone — simply asking the assistant to navigate to a page sent that content to the LLM. A page with visible malicious instructions was sufficient to trigger injection. No screenshot, no special trigger: every webpage became a potential vector.
Opera Neon used hidden HTML elements — zero-opacity elements, comment nodes, non-rendered markup — invisible to users but fully readable by the AI assistant processing page content.
Both vulnerabilities confirmed Brave’s thesis: indirect prompt injection is not an isolated bug but a systemic architectural challenge facing the entire category. The same-origin policy is rendered inadequate because it governs browser sandbox behaviour, not AI agent behaviour. As Brave put it: “Agentic browser assistants can be prompt-injected by untrusted webpage content, rendering protections such as the same-origin policy irrelevant because the assistant executes with the user’s authenticated privileges.” The OWASP and MITRE classifications for these incidents provide the formal taxonomy.
ChatGPT Atlas launched in beta in October 2025. Within 24 hours, researchers had demonstrated clipboard injection, a Google Docs-based prompt injection changing the browser’s display mode, and attempted data exfiltration. Security researcher Johann Rehberger published a working demonstration. The Register replicated a successful injection test. Understanding why these injection attacks work at the architectural level explains why patching one product does not solve the problem.
The pattern reflects a fundamental asymmetry: defenders must secure every interaction with every webpage; attackers need to compromise just one.
OpenAI’s response was the most transparent security disclosure in the agentic browser space. CISO Dane Stuckey publicly acknowledged the problem. OpenAI’s December 22, 2025 hardening post described an RL-trained automated attacker that “can steer an agent into executing sophisticated, long-horizon harmful workflows that unfold over tens (or even hundreds) of steps” and “observed novel attack strategies that did not appear in our human red teaming campaign or external reports.” Their conclusion: “Prompt injection remains an open challenge for agent security, and one we expect to continue working on for years to come.”
Watch Mode — Atlas’s human-in-the-loop confirmation feature — was positioned as a key mitigation. Simon Willison tested it on GitHub and an online banking site and found it did not trigger reliably, with Atlas continuing to navigate after he switched to another application.
Giskard‘s independent assessment confirmed residual OWASP LLM vulnerabilities (LLM01, LLM02, LLM05, LLM06). CloudFactory‘s enterprise analysis found structural gaps: no SOC2 or ISO certification, no SIEM integration, no Atlas-specific SSO enforcement, no administrative approval workflows for Business tier customers. OpenAI’s own documentation warns: “We recommend caution using Atlas in contexts that require heightened compliance and security controls.” See the adoption framework to prevent these events and detection tooling for these attack types in the companion articles.
The Atlas disclosures centred on one vendor. The Gemini finding in January 2026 showed the same weakness appearing in a mainstream productivity tool used by hundreds of millions of people.
Miggo Security disclosed a semantic attack against Google Gemini via Google Calendar invites in January 2026. Google confirmed the findings and mitigated the vulnerability.
The attack chain is worth understanding in detail. An attacker embeds a prompt-injection payload in a calendar event description — instructions directing Gemini to summarise private meetings on a specific day, write that summary into a new calendar event visible to the attacker, and respond to the user with “it’s a free time slot” to mask the action. The payload sits dormant until the target asks Gemini a routine scheduling question. Gemini then loads all relevant calendar events, processes the malicious payload as trusted context, and exfiltrates the data silently.
Delivery is zero-click. The attacker sends a calendar invite. The victim’s calendar displays it. No interaction beyond asking a routine question triggers the attack.
Miggo coined “semantic attack” to describe why this class of exploit eludes traditional defences: “The payload was syntactically innocuous, meaning it was plausible as a user request. However, it was semantically harmful when executed with the model tool’s permissions.” Traditional AppSec is syntactic — it looks for malicious patterns. “In contrast, vulnerabilities in LLM powered systems are semantic. Attackers can hide intent in otherwise benign language.” Google had already deployed a detection LLM to identify malicious prompts. The attack succeeded anyway because natural language has no fingerprint that distinguishes legitimate instructions from attacker-authored ones. This is why the semantic attack class described in the companion article on supply chain and messaging vectors requires a fundamentally different detection approach.
Microsoft Defender Research published findings in February 2026 showing AI Recommendation Poisoning deployed commercially by 31 companies across 14 industries — over 50 unique poisoning prompts identified across 60 days. Researchers Noam Kochavi, Shaked Ilan, and Sarah Wolstencroft documented the campaign.
The mechanism is straightforward. Specially crafted URLs embed memory manipulation instructions as query parameters. Websites embed these as “Summarise with AI” buttons. When clicked, the instructions plant persistence commands into the AI assistant’s memory. “Once poisoned, the AI treats these injected instructions as legitimate user preferences, influencing future responses.” Confirmed targets include Microsoft 365 Copilot, ChatGPT, Claude, Perplexity, and Grok.
MITRE ATLAS classifies this as AML.T0080 (Memory Poisoning / AI Agent Context Poisoning: Memory) — formalising it as a recognised adversarial technique with documented mitigations and detection methods, so security teams can incorporate it into threat models and compliance frameworks.
This is more serious than session-level injection because it survives session boundaries. A single successful injection persists across every future interaction. Microsoft’s documented real-world harm scenarios illustrate this well: a CFO whose AI recommends a specific vendor for a multi-year contract; a parent receiving biased child safety advice — from a single “remember” instruction.
The tooling is openly available. The CiteMET NPM package and AI Share URL Creator are openly marketed as “SEO growth hack for LLMs.” Microsoft put it bluntly: “The barrier to AI Recommendation Poisoning is now as low as installing a plugin.” Detection requires SIEM integration with Microsoft Defender. The incident response playbook covers what to do when you suspect your AI assistant memory has been compromised.
PromptArmor disclosed a zero-click data exfiltration chain in February 2026 (The Register, February 10, 2026). An attacker uses malicious prompts to trick an AI agent into generating a URL that appends sensitive data — API keys, session credentials — as query parameters. The messaging app’s link preview system automatically fetches that URL to generate a thumbnail, transmitting the data to an attacker-controlled server. No user click required.
“In agentic systems with link previews, data exfiltration can occur immediately upon the AI agent responding to the user, without the user needing to click the malicious link.” OpenClaw was confirmed vulnerable in default Telegram configurations. At-risk combinations tested included Microsoft Teams with Copilot Studio, Discord with OpenClaw, and Slack with Cursor Slackbot.
Cisco Talos (researchers Amy Chang and Vineeth Sai Narajala) independently investigated a related but distinct vector: compromise via AI agent skill marketplaces. They tested the top-ranked skill on MolthHub — “What Would Elon Do?” — and found it was “functionally malware” that “facilitated active data exfiltration” via a “silent” network call. MolthHub’s number-one ranked skill was the malicious one, demonstrating that bad actors “are able to manufacture popularity on top of existing hype cycles.” Cisco’s broader skill research found 26% of 31,000 agent skills contained at least one vulnerability.
Plaintext API key leakage gives the attacker persistent, reusable credentials — not a one-time theft. The deeper treatment of zero-click exfiltration via messaging apps is in the companion article.
The root cause — the LLM treating untrusted ambient content as trusted user instruction — holds across all six incidents. Patching individual products does not change this. Every vendor is running the same cat-and-mouse defence cycle. “Prompt injection, much like scams and social engineering on the web, is unlikely to ever be fully ‘solved,'” OpenAI stated.
Security posture comparison based on evidence: Atlas has the most transparent hardening programme (automated red-teaming, Watch Mode, public CISO disclosure) and the most documented vulnerabilities (exploitation within 24 hours of launch, unreliable Watch Mode, residual OWASP gaps, missing SOC2/SIEM/SSO). Comet has the earliest and most extensive independent security research via Brave and LayerX. Dia has Zenity‘s Agentic Browser Threat Model as its primary security framework, with thinner product-level evidence than either.
Human-in-the-loop vs. fully autonomous: Watch Mode and confirmation dialogs reduce risk but are not complete mitigations. Willison’s testing found Watch Mode unreliable in practice. Fully autonomous agents amplify blast radius. Human-in-the-loop agents remain vulnerable to attacks that execute before the confirmation prompt appears — a semantic attack disguising exfiltration as a routine task is indistinguishable from a legitimate request until the data has already moved.
That escalation — from researcher proof-of-concept (Comet, August 2025) to commercial-scale exploitation (Microsoft Recommendation Poisoning, February 2026) — happened in six months. Zenity’s threat model puts it plainly: “Many of these tools are installed informally by employees. They often operate without visibility or governance, making them one of the fastest growing sources of shadow AI inside the enterprise.”
The question is not “which product is safe” but: what monitoring, isolation, and incident response must be in place before any deployment? The broader attack surface — including the architectural root cause, standards coverage, and adoption controls — is mapped in full in the hub article. The adoption framework, detection tooling, and compliance exposure are covered in the companion articles.
Yes. The Fellou vulnerability (October 2025) demonstrated that navigating to a page containing embedded instructions was sufficient for the AI to execute attacker commands — no clicking, no screenshots. If you are logged into sensitive accounts, the AI inherits that access.
Atlas has the most transparent hardening programme in the category but it has documented gaps: unreliable Watch Mode (Simon Willison), OWASP LLM01/02/05/06 vulnerabilities (Giskard), and missing SOC2, SIEM, and SSO controls (CloudFactory). OpenAI’s own documentation recommends caution in regulated or confidential contexts. No agentic browser has been proven safe for unsupervised enterprise use.
Direct prompt injection: a user types a malicious instruction. Indirect prompt injection: malicious instructions are embedded in content the AI reads — web pages, images, calendar invites, link previews. All six incidents in this article are indirect. The attacker never interacts with the AI directly.
Microsoft published KQL Advanced Hunting queries for Microsoft Defender for Cloud to detect memory poisoning attempts. Organisations not using Defender do not have an equivalent standardised detection mechanism — the companion article on open-source scanning tools covers alternatives.
No agentic browser has demonstrated immunity to indirect prompt injection. Atlas: most documented hardening, most documented vulnerabilities. Comet: most independent security research. Dia: Zenity threat model guidance with thinner product evidence. Frame this by evidence quality, not marketing.
Miggo Security’s term for the Gemini calendar-invite exploit. A semantic attack is syntactically benign — ordinary language that passes any content filter — but semantically harmful when an LLM interprets it with tool permissions. WAFs and input sanitisation look for malicious patterns. Ordinary language has none.
Miggo Security demonstrated this in January 2026. Gemini reads the event description as trusted context, summarises the target’s private meetings, writes the data into a new event visible to the attacker, and responds with “it’s a free time slot” to conceal the exfiltration.
The same-origin policy governs browser sandbox behaviour, not AI agent behaviour. As Giskard noted, Atlas “operates with cross-origin visibility… a privileged component with legitimate access to all browsing contexts.” The AI agent reads and acts on content from any origin because that is its designed function.
AML.T0080 (Memory Poisoning / AI Agent Context Poisoning: Memory) is the MITRE ATLAS taxonomy entry for attackers injecting false data into an AI system’s persistent memory. The classification enables security teams to incorporate memory poisoning into threat models and compliance frameworks with documented mitigations and detection methods.
OpenAI CISO Dane Stuckey stated that prompt injection is “unlikely to ever be fully solved.” Effective controls exist: human-in-the-loop confirmation, logged-out browsing mode, network-layer isolation, SIEM monitoring, and restricting agent access to sensitive accounts. Defence in depth is the current best practice — not solved, but manageable with the right controls before deployment.
SEO poisoning affects one search session. AI memory poisoning manipulates an AI assistant’s persistent memory, influencing every future interaction across every session and topic. Where SEO poisoning redirects a single query, memory poisoning redirects everything the AI does from that point on.
Brave Security Research (Comet, Fellou, Opera Neon): brave.com/blog/unseeable-prompt-injections/. Miggo Security (Gemini calendar attack): miggo.io/blog/weaponizing-calendar-invites-a-semantic-attack-on-google-gemini. Microsoft Defender Research: microsoft.com/en-us/security/blog/2026/02/manipulating-ai-memory-ai-recommendation-poisoning/. PromptArmor/OpenClaw: theregister.com/2026/02/10/ai_agents_messaging_apps_data_leak/. Cisco Talos/MolthHub: blogs.cisco.com/ai/personal-ai-agents-like-openclaw-are-a-security-nightmare. Zenity Threat Model: zenity.io/blog/your-browser-is-becoming-an-agent-zenity-keeps-it-from-becoming-a-threat.
Why Prompt Injection Is the Unsolved Problem Inside Every Agentic BrowserYou would never hand a junior contractor your logged-in laptop and tell them to “just handle it” — no scope, no oversight, full access to email, cloud storage, and every system you’re authenticated to. Yet that is precisely the trust model underlying every agentic browser currently shipping to enterprise users.
The vulnerability that makes this dangerous is not a browser engine flaw. It is the fact that web pages can contain sentences that the agent reads as instructions — and acts on.
Within days of launching ChatGPT Atlas, OpenAI’s own CISO, Dane Stuckey, publicly called prompt injection “a frontier, unsolved security problem.” That is not product humility. It is an accurate description of where the field sits.
This article covers the full attack taxonomy: what prompt injection is, why indirect injection is the dominant threat vector, why Same-Origin Policy and CORS are irrelevant here, and what the confused deputy problem reveals about the root cause. For broader context, see the browser-agent security landscape. The key variable is architecture — not filtering.
An agentic browser is not a browser with an AI sidebar bolted on. A conventional AI feature — “summarise this page,” “answer a question about this PDF” — operates in a read-only, single-origin context. It can describe what it sees. It cannot act on what it sees, and it cannot carry your credentials across domains.
An agentic browser removes both constraints simultaneously. The LLM agent autonomously navigates sites, fills forms, reads emails, and completes multi-step workflows across every domain you’re authenticated to — in a single session, using your full credentials. It is not answering questions. It is taking actions.
When Brave‘s security team tested browsers in this category, they found ChatGPT Atlas, Perplexity Comet, Fellou, and Opera Neon all vulnerable to prompt injection. The hCaptcha Threat Analysis Group found Atlas completed 16 of 19 malicious abuse scenarios with no jailbreaking required.
The architectural root cause is what Noma Security describes as the collapse of three historically separate security layers: browsing, assistance, and action. Traditional browsers kept those layers separate by design. Agentic browsers eliminate those separations — that is literally the value proposition. Risk concentrates where layers merge.
Prompt injection is a security attack where an adversary places malicious instructions in locations an LLM is likely to trust, overriding the model’s intended behaviour. The core vulnerability is structural: developer system prompts and attacker input share the same format — natural-language text. The model has no syntactic mechanism to distinguish them. This is the semantic gap.
Unlike SQL injection — where OR '1'='1' is structurally distinguishable from legitimate input — a prompt injection payload looks identical to a legitimate user request. That is why OWASP lists it as LLM01: the number-one risk in the OWASP Top 10 for LLMs 2025.
For a chatbot, a successful injection produces wrong answers. For an agentic browser, it produces data breaches — forwarding sensitive emails, sending money, deleting cloud files, all using your credentials.
That is why Dane Stuckey framed it as he did: “Prompt injection remains a frontier, unsolved security problem, and our adversaries will spend significant time and resources to find ways to make ChatGPT agent fall for these attacks.”
For how OWASP and compliance frameworks formally classify these attacks, see how OWASP classifies these attack types.
Direct prompt injection — also called jailbreaking — is when the attacker types malicious instructions directly into the model’s input. They need to control the user interface to do it.
Indirect prompt injection is categorically different. The attacker embeds malicious instructions in external content — a web page, an email, a calendar invite, an image — that the agent later retrieves and processes. The agent executes those instructions as if they were legitimate user directives. The user never sees the malicious content.
For agentic browsers, indirect injection is the dominant threat vector because the entire purpose of the browser is to retrieve and process external web content. Every page the agent visits is a potential injection surface.
Brave’s security team confirmed this is systemic: “Indirect prompt injection is not an isolated issue, but a systemic challenge facing the entire category of AI-powered browsers.” Their research demonstrated invisible injection in practice: malicious instructions hidden in near-invisible text — unreadable to a human, fully readable by OCR and passed to the LLM as trusted content.
Johann Rehberger’s term “offensive context engineering” captures the sophistication: attackers shape the entire context window the agent sees, not just a single injected instruction. Input sanitisation cannot solve this. The “input” is an ordinary web page the user asked the agent to visit. This is why these attacks are demonstrated in real exploits across production systems.
Link-mediated exfiltration converts a prompt injection from instruction-override into active data theft. The injected prompt instructs the agent to: locate sensitive data — emails, calendar entries, credentials; encode that data into a URL; and trigger an HTTP request to an attacker-controlled server. No browser engine vulnerability required. No sandbox escape. The agent is following instructions from a channel it trusts.
Miggo‘s Google Gemini calendar exploit illustrates this concretely. A malicious calendar invite contained a dormant payload. When the user made a routine schedule query, it activated: Gemini was instructed to summarise all private meetings, create a new calendar event with that summary in its description, and respond to the user with “it’s a free time slot.” The attacker-created event was visible through shared enterprise calendar configurations. Google had deployed a dedicated language model to detect malicious prompts. The attack succeeded anyway.
The attack surface is no longer code. It is content.
Zero-click exfiltration is the most severe variant: AI agents in messaging platforms can be directed via indirect injection to generate a data-leaking URL, which the platform’s link preview fetches automatically — no user action required. The case studies of prompt injection in production systems show these mechanisms across documented incidents.
Same-Origin Policy prevents scripts on one origin from reading data from another origin. CORS allows servers to selectively relax those restrictions. Both assume the browser enforces origin boundaries by keeping code sandboxed to its originating context.
Agentic browsers operate with the user’s full authenticated authority across all origins simultaneously — a condition SOP was never designed to address.
Brave’s security team stated this directly: agentic browser assistants “can be prompt-injected by untrusted webpage content, rendering protections such as the same-origin policy irrelevant because the assistant executes with the user’s authenticated privileges. This lets simple natural-language instructions on websites trigger cross-domain actions that reach banks, healthcare provider sites, corporate systems, email hosts, and cloud storage.”
SOP assumes a script is the attacker. In an agentic browser, the attacker is manipulating the agent — which already has legitimate cross-domain authority. The distinction worth holding is SOP irrelevance, not SOP bypass. The entire threat category has moved outside what SOP was built to handle.
Your SOP and CORS configurations are intact. They are the wrong tool for this threat.
The SOP analysis points to something more fundamental. The confused deputy problem.
A privileged program — the “deputy” — is tricked by a less-privileged party into misusing its authority. The deputy has legitimate access. The attacker has no direct access. The attacker exploits the deputy’s legitimacy to achieve what they cannot achieve directly.
Applied to an agentic browser: the AI agent holds the user’s full authentication privileges across all domains. Attacker-controlled web content has no privileges. By injecting instructions into content the agent processes, the attacker manipulates the privileged deputy into taking actions on systems it cannot otherwise reach.
MIT Professor Srini Devadas put it precisely: “The challenge is that if you want the AI assistant to be useful, you need to give it access to your data and your privileges, and if attackers can trick the AI assistant, it is as if you were tricked.”
CloudFactory calls this the “trust paradox.” To be useful, AI agents need access to systems, data, and privileges. To be secure, they require isolation and restricted access. Those requirements are in direct conflict — which is why enterprise AI deployments stay confined to low-risk pilots.
The confused deputy framing is also why making the model smarter does not resolve the problem. The vulnerability is not in the model’s reasoning — it is in the architecture of delegation. For how MITRE ATLAS taxonomises these attack types as architectural risks, this framing is the foundation. For an overview of agentic browser risks across the full threat surface, this architectural distinction is a consistent thread.
It is genuinely unsolved at the architectural level. This is the consensus of security researchers, standards bodies, and the vendors with the greatest commercial incentive to say otherwise.
OpenAI’s December 2025 blog: “Prompt injection, much like scams and social engineering on the web, is unlikely to ever be fully ‘solved’… Prompt injection remains an open challenge for agent security, and one we expect to continue working on for years to come.”
Simon Willison: “in application security, 99% is a failing grade.” His concern: “it worries me that it’s setting up a false sense of security — if it’s harder but still possible someone is going to get through.”
Johann Rehberger concluded: “Since there is no deterministic solution for prompt injection, it is important to highlight and document security guarantees applications can make… The message remains: Trust No AI.”
The Gemini calendar exploit illustrates why. Google deployed a language model specifically to detect malicious prompts. The attack succeeded anyway — because the payload was semantically plausible. That is the semantic indistinguishability problem: instructions and data share the same format, so there is no syntactic signature to detect.
Mitigations exist and improve continuously. They do not eliminate the vulnerability class.
Probabilistic defences detect and block malicious prompts using pattern recognition, classifiers, and model tuning. They reduce the frequency of successful attacks. They cannot reduce it to zero.
Current examples in production: Spotlighting (Microsoft’s technique using randomised delimiters and encoding to distinguish untrusted content from trusted instructions), Microsoft Prompt Shields (classifier-based detection), adversarial training, Watch Mode (Atlas alerting on sensitive sites), and Logged-Out Mode (operating without authenticated credentials). All work at the level of detection or avoidance — not structural prevention.
Each is bypassable. Atlas completed content filter evasion by decoding Base64-encoded content — the encoding mechanism was the bypass, not the defence.
Deterministic controls provide architectural guarantees that certain attack classes cannot succeed regardless of model behaviour.
FIDES (Microsoft Research) is the primary example. It applies information-flow control to agentic systems. Rather than detecting whether a prompt is malicious, FIDES tracks how data propagates and enforces hard constraints on where it can flow. If data from an untrusted source cannot reach an exfiltration channel by construction, the attack fails regardless of what the model does.
Human-in-the-loop (HITL) architecture: explicit human approval before sensitive actions creates a hard gate that prompt injection cannot bypass.
Principle of least privilege applied to agent permissions reduces the blast radius when an injection succeeds.
Never rely solely on probabilistic defences. Pair them with at least one deterministic control. For governance controls that address these risks in enterprise deployments, the architecture question is where safe adoption frameworks begin.
Yes, through indirect prompt injection. A malicious page can contain hidden instructions that the agent processes automatically when it navigates there — no click required. In messaging contexts, zero-click exfiltration can trigger when the agent processes a received message and the platform’s link preview automatically fetches an attacker-controlled URL.
No, not for sensitive accounts. OpenAI explicitly warns against using Atlas with “regulated, confidential, or production data” and positions enterprise access as a beta for “low-risk data evaluation” only. Enterprise access is OFF by default. Use Logged-Out Mode for general browsing, and logged-in sessions only for low-sensitivity tasks.
OpenAI’s own CISO called it “a frontier, unsolved security problem,” and the company’s December 2025 blog post stated it “is unlikely to ever be fully solved.” The architectural root cause — semantic indistinguishability — means the vulnerability class will persist. Expect mitigation, not elimination.
When an agentic browser operates in logged-in mode, it has access to every site the user is authenticated to — email, cloud storage, banking, corporate systems. Any action the agent takes is indistinguishable from the user taking that action themselves.
Indirect injection is significantly harder. The malicious instructions come from external content the agent was designed to process — web pages, emails, documents. Every page the agent visits is a potential injection surface, and the payload can be invisible to the user while remaining fully processable by the agent.
A conventional browser’s attack surface is the browser engine itself — vulnerabilities require memory corruption, sandbox escapes, or similar technical exploits. An agentic browser adds a parallel attack surface: any web content the agent processes can contain instructions that manipulate its behaviour. No browser engine vulnerability is required.
A jailbreak (direct prompt injection) targets the model’s safety guardrails to produce restricted content. Indirect prompt injection targets the model’s behaviour to take actions the user did not authorise — exfiltrating data, sending emails, modifying files. Jailbreaking is about what the model says; indirect injection is about what the model does.
Offensive context engineering is Johann Rehberger’s term for carefully crafted web content designed to trick AI agents into taking attacker-directed actions. The attacker shapes the entire context window the agent sees — not just a single injected instruction, but the full informational environment the model uses to decide its next action.
Because prompt injection payloads are written in ordinary natural language indistinguishable from legitimate requests. The Miggo Gemini calendar exploit payload was syntactically innocuous — plausible as a user request — yet semantically harmful when executed with model tool permissions. Google deployed a separate detection model. The attack succeeded anyway.
No, but evaluate with clear boundaries. Use agentic browsers for low-sensitivity tasks with Logged-Out Mode, apply deterministic controls (human approval gates, least privilege permissions) for sensitive use cases, and architect for the assumption that prompt injection will eventually succeed — then ensure the blast radius is contained.
The Agentic Browser Landscape — Architecture, Risk and Enterprise StrategyYour browser used to be a viewer. You opened a page, read it, clicked things, filled in forms. The browser waited for you. That model is ending. Agentic browsers — browsers that navigate, click, fill forms, and complete multi-step tasks on your behalf without you driving each action — are arriving from every direction. Google has retrofitted Chrome with Auto Browse. OpenAI built Atlas from the ground up as an AI-native browser. Kagi shipped Orion with zero telemetry and no AI core at all.
These are not variations on the same product. They represent different architectural positions, each with distinct implications for security, reliability, privacy, and governance. Agentic browsing traffic grew 6,900% year-over-year from 2024 to 2025. Your employees may already be using these tools on work devices. This hub maps the landscape and directs you to the analysis you need.
In this guide:
- What is an agentic browser and why does architecture matter? Browser architecture typology explained
- What are the security risks? Browser agent security risk analysis — prompt injection and OWASP mapping
- How reliable are browser agents really? Browser agent reliability benchmarks and hype gaps
- What do vendors do with your browsing data? Agentic browser data handling guide
- How do you govern agentic browser use? Browser agent governance framework and acceptable use policy
The hero above defines the concept. What matters here is the practical consequence: agentic browsers interact with your accounts, credentials, and data in ways a traditional browser never could. The AI is not a sidebar assistant but an architectural component capable of taking autonomous action across authenticated sessions while you are not watching. “Your browser is no longer a viewer. It is an actor, and one you do not fully control.” That is why the security and governance questions are different in kind, not just degree.
Deep dive: Retrofitted vs AI-native breakdown — what the architecture actually means
Four categories have emerged. Retrofitted browsers (Chrome Auto Browse, Edge with Copilot) layer AI onto existing Chromium infrastructure. AI-native browsers (OpenAI Atlas, Perplexity Comet, Dia, Fellou) are built with AI as a first-class component. Privacy-first browsers (Kagi Orion, LibreWolf) ship with no AI core and zero telemetry. Enterprise browsers (Island, Talon/Palo Alto, Seraphic/CrowdStrike) are security-oriented forks with centralised governance controls. Each category reflects a distinct architectural position with its own security surface and data handling posture.
Chrome’s three billion-plus users give the retrofitted category the greatest reach, but the AI sits on pre-agentic architecture. AI-native browsers treat the AI as the core — architectural coherence, but a different security surface where the AI holds privileged cross-origin access by design.
Deep dive: Browser architecture typology explained — retrofitted, AI-native and privacy-first
Architecture (what the AI can access and how), security risk (exposure to prompt injection and data exfiltration), reliability (real-world task completion versus vendor claims), privacy posture (where browsing data goes), and governance (what controls exist and what policies you need). Evaluating a browser agent product on capability alone — which is what most vendor pages encourage — means deciding on incomplete information that will not survive contact with your environment.
These dimensions interact in ways that vendor marketing rarely acknowledges. Architecture determines security surface. Reliability gaps determine governance requirements — a 61% task success ceiling means human-in-the-loop is not optional. Privacy posture determines compliance exposure. The cluster articles below are designed to be read independently at the decision stage where you need them, or sequentially for a full landscape evaluation.
Browser architecture typology | Browser agent security risk analysis | Reliability benchmarks | Agentic browser data handling guide | Browser agent governance framework
The browser is the interface through which most enterprise work happens. Whoever controls the browser layer controls the execution layer for work. Atlas, Auto Browse, Edge for Business, and Comet are all bets that the next computing interface is a browser that acts, not a chat window. Browsers also generate a constant stream of rich interaction data that trains and refines models — owning the browser secures first-party access to that data.
The January 2026 acquisition of Seraphic by CrowdStrike signals that major security vendors now treat agentic browser governance as a core enterprise problem, not a niche concern. For you, this means the browser is no longer a commodity utility. It is a product with its own vendor relationship, data handling posture, and security surface.
The race for the browser layer also explains the architectural trade-offs each competitor has chosen.
Deep dive: Retrofitted vs AI-native breakdown — what the browser race means for architecture
Retrofitted browsers (Chrome, Edge) offer reach and compatibility but carry a pre-agentic security model with AI bolted on. AI-native browsers (Atlas, Comet) offer architectural coherence but grant the AI privileged cross-origin access by design, not as an exploit. Privacy-first browsers (Orion, LibreWolf) offer zero-telemetry posture but exclude built-in AI capability. The trade-off is not capability versus safety — it is architectural coherence versus trust inheritance versus data independence.
Orion ships with “no built-in AI code in its core” — a deliberate counter-position for strict data sovereignty environments.
Deep dive: Browser architecture typology explained — the retrofitted vs AI-native vs privacy-first comparison
Current AI browsers are not safe for unrestricted enterprise use without governance controls. The hCaptcha benchmark tested five browser agents against twenty abuse scenarios and found near-total absence of safety safeguards. Prompt injection was demonstrated on Atlas within days of launch and is named by OpenAI’s CISO as “a frontier, unsolved security problem.” The evidence is categorical, not speculative — this is a category-wide finding, not an isolated product failure.
The more useful question is what controls must be in place before this product touches company data. Some answers are currently disqualifying for specific products and environments.
Deep dive: Browser agent security risk analysis — prompt injection, OWASP mapping and the absent safeguards
Published benchmarks test agents in controlled environments with predictable page states. Real-world tasks involve dynamic content, anti-bot measures, and multi-system workflows that no benchmark fully replicates. The Online-Mind2Web analysis found agents scoring near-90% on standard benchmarks solved only 51–61% in real-world evaluation. Ars Technica’s Chrome Auto Browse test returned a median 7/10, average 6.5/10, with re-prompting required on almost every task — and these were consumer-grade tasks, not enterprise workflows.
Business cases built on vendor benchmarks are built on numbers that will not transfer to your environment.
Deep dive: Browser agent reliability benchmarks — capability vs hype analysis
Yes, but the choice of browser determines whether that is possible. Chrome Auto Browse streams page content to Google cloud for inference — “temporary” retention, no specified duration. Atlas builds a cross-session behavioural profile through Browser Memory, creating both a contextual asset and an attack target. Orion operates with zero telemetry and no cloud inference, routing no browsing data to vendor infrastructure. The architectural difference is binary, not a matter of degree.
For environments handling patient data, payment data, or personal data under GDPR, page content streamed to a vendor cloud triggers processing obligations that current vendor documentation may not satisfy.
Do not wait for a policy — adoption is already happening bottom-up. Zenity’s data shows employees installing AI-native browsers on work devices without IT knowledge across enterprise environments right now. Standard analytics cannot distinguish human from agent traffic. The governance problem is not theoretical, and waiting for a formal framework before acting means the window for establishing minimum viable controls has likely already closed.
Five steps before any browser agent touches internal tools:
Agentic Browser Security Risks — Prompt Injection, OWASP Mapping and the Absent Safeguards: Evidence-based risk analysis mapping vulnerabilities to the OWASP LLM Top 10. Covers the hCaptcha benchmark, indirect prompt injection, and autonomous action compounding risk.
Agentic Browser Data Handling — What Vendors Do With Your Browsing Data and What You Can Do About It: Vendor-by-vendor data handling comparison with GDPR, HIPAA, and PCI-DSS compliance implications.
An agentic browser acts on your behalf — navigating, clicking, submitting forms across multiple sites without you driving each step. Agentic browsing traffic grew 6,900% year-over-year. Adoption is happening faster than governance frameworks are being built. You should care now.
A retrofitted browser layers AI onto existing architecture. An AI-native browser is built with AI as an architectural core. The practical difference: retrofitted AI operates within the existing security model; AI-native browsers give the AI privileged cross-origin access by design. See the browser architecture typology.
Atlas’s Browser Memory builds a cross-session profile of what the agent has seen and done. This makes the AI more useful and creates an attack target. An attacker who can manipulate what the agent “remembers” (OWASP LLM-01, memory poisoning) can influence all future sessions. The feature and the vulnerability are the same component.
Standard endpoint tools show application installations. Web analytics will not reliably identify agentic traffic — Google Analytics cannot distinguish human from agent at scale. Zenity via Unified Endpoint Management provides device-level discovery and behavioural detection. See the browser agent governance framework.
Enterprise browsers (Island, Talon, Seraphic/CrowdStrike) provide superior governance — centralised policy, DLP integration, audit trails. The trade-off is AI capability: they lack AI-native agent features. For regulated data environments, enterprise browsers may be the appropriate near-term posture. See the enterprise decision framework for browser agents.
Prompt injection is to LLMs what SQL injection was to web applications — exploiting how AI interprets instructions embedded in content. OpenAI’s CISO named it “a frontier, unsolved security problem.” It cannot be patched because it exploits the core mechanism by which LLMs interpret language. See the browser agent security risk analysis.
HITL requires human approval before consequential actions, significantly reducing the blast radius of prompt injection. But it does not eliminate the risk — it constrains what a compromised agent can do. Every confirmation pause also means the agent cannot complete tasks autonomously. HITL is a designed compensating control, not a full solution. See the prompt injection and OWASP mapping analysis.
Browser Agent Governance — Shadow AI Detection, Acceptable Use Policy and the Enterprise Decision FrameworkBrowser agents — ChatGPT Atlas, Perplexity Comet, Dia — are not a future governance problem. They are a right now problem. IDC data shows 39% of EMEA employees already use unauthorised AI tools at work, and 52% would not disclose that usage if asked. Agentic browser traffic grew 1,300% between January and August 2025, then another 131% month-over-month into September. Adoption has already outrun policy.
What makes browser agents a different kind of shadow AI is their access model. Unlike ChatGPT or Copilot — which generate content but do not act — browser agents operate inside the user’s authenticated browser session. They inherit SaaS logins, internal tool credentials, and open API keys. When compromised via prompt injection, the agent acts with the employee’s full authenticated permissions on behalf of whoever crafted the injection.
This article delivers a pre-deployment checklist, a shadow AI detection toolchain, an acceptable use policy structure, and a vendor-neutral CTO decision matrix. It is part of our series on the agentic browser landscape, which covers the full spectrum from architecture typology through to enterprise governance.
The question is not whether to allow browser agent use. It is how to govern adoption that has already begun.
Shadow AI in the browser agent context is the documented baseline, not a future risk scenario.
IDC data puts it plainly: 39% of EMEA employees use free AI tools without authorisation, another 17% use tools they personally pay for, only 23% use organisation-provided tools. Sensitive data fed into unauthorised AI tools jumped from 10% to over 25% in a single year. IDC frames this as rational self-preservation — employees have an active incentive not to disclose usage when workforce reductions are being attributed to AI efficiency gains.
Two attack vectors have been publicly demonstrated. CometJacking: a malicious webpage hijacks the browser agent, causing it to read sensitive data from open tabs, encode it to evade DLP, and exfiltrate it to an attacker-controlled server. Atlas clipboard injection: within 24 hours of launch, prompt injection attacks caused Atlas to overwrite the user’s clipboard with malicious links. Both exploit what is called the confused deputy problem — the agent has legitimate access and executes illegitimate instructions. OpenAI CISO Dane Stuckey put it simply: “prompt injection remains a frontier, unsolved security problem.”
Governance established after browser agents are embedded in daily workflows is far more disruptive to remove than governance put in place first. For the empirical security evidence for governance urgency — including the hCaptcha benchmark and OWASP LLM mapping — see the security risk analysis.
The following checklist assumes no dedicated CISO or SOC. The order matters — audit before policy, policy before pilot, detection before broad rollout.
Step 1: Shadow AI Audit Check your UEM/MDM inventory for Atlas, Comet, and Dia installations. Review Secure Web Gateway logs for connections to OpenAI, Perplexity, and Browser Company API endpoints. Discovering existing usage is the expected outcome — the 52% non-disclosure rate means surveys will undercount. Deliverable: Shadow AI inventory report.
Step 2: Data Classification Identify internal systems and SaaS platforms containing PII, PHI, financial data, credentials, and source code. These are off-limits for browser agent access until governance controls are in place. Deliverable: Data sensitivity map.
Step 3: Draft the Acceptable Use Policy The AUP must exist before any sanctioned use begins. Prohibit autonomous browsing tools that act without per-click user confirmation until the full policy is in place. The AUP section below gives you the framework. Deliverable: Initial browser agent AUP document.
Step 4: Define the Sandboxed Pilot Pick a low-risk user group — research or communications, not engineering or finance. Restrict to non-sensitive workflows. Enable telemetry and logging from day one. Deliverable: Pilot scope document.
Step 5: Deploy Detection and Monitoring Deploy Zenity‘s endpoint agent via UEM — Jamf for macOS, Microsoft Intune for Windows — on managed devices. Start in detect mode before switching to prevent mode. For BYOD devices, configure Secure Web Gateway policies to monitor connections to agentic browser API endpoints. Deliverable: Zenity deployed in detect mode; Secure Web Gateway rules updated.
Step 6: Establish Human-in-the-Loop Requirements Define which action categories require explicit human confirmation: form submissions, credential entry, data exports, and multi-step workflows affecting production systems. Deliverable: HITL policy.
Step 7: Set Review Cadence Schedule your 30-day and 90-day policy reviews now. The landscape is changing monthly. Deliverable: Review calendar.
Detection operates at two distinct layers: device-level discovery and traffic-level detection.
Layer 1: Device-Level Discovery
For managed devices, Zenity’s endpoint agent deploys via standard UEM workflows and identifies Atlas, Comet, Dia, MCPs, and other agentic tools. Start in detect mode and move to prevent mode once you have a clear inventory. For BYOD devices, use Secure Web Gateway logs to identify connections to agentic browser API endpoints from within the corporate network.
Layer 2: Traffic-Level Detection
Standard bot detection fails entirely for Chromium-based agentic browsers. They run on the user’s machine, inherit legitimate logged-in sessions, and present standard Chrome user-agent strings. The IAB bot list — used by both GA4 and most server-side bot filtering — does not include them. Behavioural signatures do distinguish agent traffic though: linear page navigation, consistent timing, 0.25-pixel mouse movement increments, zero scroll depth variation. These signals require event-level analysis, not aggregate reports.
Response Protocol
Do not immediately block when you discover shadow AI. Blocking drives usage to personal devices outside your visibility. Document the scope, assess risk exposure, and use your findings to inform the AUP and pilot scope.
Seven dimensions. Your browser agent AUP must cover all of them.
Dimension 1: Authorisation Scope Default position: no authorisation until explicit approval. Distinguish managed agents — IT-deployed — from employee-installed agents that fall into the shadow AI category.
Good policy clause: “Browser agent features are permitted for [role/team] in [specified workflow categories] only. Any use outside these parameters requires prior written approval from [IT/Security].”
Bad policy clause: “Employees should use browser agents responsibly.”
Dimension 2: Permitted and Prohibited Actions Permitted: web research, content summarisation, public data retrieval. Prohibited: form submission with credentials, internal tool automation without human confirmation, access to systems containing sensitive data. OpenAI itself says “Do not use Atlas with regulated, confidential, or production data” — embed this in your policy regardless of which tool is in scope.
Dimension 3: Data Classification Constraints No PII, PHI, financial data, credentials, or source code in agent-accessible sessions. Block regulated data at the technical level. Do not rely on employees managing this themselves.
Dimension 4: Human-in-the-Loop Requirements High-risk categories requiring explicit human confirmation: data export, form submission, credential entry, and multi-step workflows affecting external systems. Chrome Auto Browse’s approach is the useful reference here: for purchases, the agent “will find the item and progress to the purchase screen before letting you pull the trigger manually.”
Dimension 5: Audit and Logging All agentic browser sessions logged: actions taken, data accessed, blocked events. Feed telemetry into SIEM and XDR tools.
Dimension 6: Technical Enforcement Policy without technical enforcement is advisory only. Specify UEM-based restrictions, Zenity guardrails, and Secure Web Gateway network-level controls.
Dimension 7: Review Cadence 90-day reviews minimum. Each review assesses new products, vendor compliance changes, audit findings, and whether the governance posture still fits your risk profile.
Minimum Viable Policy Four elements: authorised users and permitted workflows; prohibited actions list; logging requirement; 90-day review commitment. One page. Comprehensiveness matters more than length.
This blind spot is not just a marketing measurement problem. It creates a compliance and audit gap in internal SaaS tools — Jira, Confluence, Salesforce, GitHub. When you cannot distinguish human from agent activity in your internal tool logs, you cannot audit what browser agents have actually done.
Chromium-based agentic browsers present standard Chrome user-agent strings. GA4 bot filtering relies on the IAB bot list, designed for an era when bots self-identified. A session can shift from human to agent mid-stream and standard analytics cannot detect the handover. Snowplow estimates up to 37% of events in a typical dataset may come from agent-driven sources that GA4 counts as human traffic.
Snowplow as the Detection Alternative
Snowplow delivers complete unsampled event data to your own data warehouse and segments traffic into four classifications: humans, bots and crawlers, answer-fetching agents, and agentic browsers. GA4’s aggregated model simply cannot produce that segmentation.
RFC 9421: The Emerging Protocol-Level Solution
ChatGPT Agent sends a Signature-Agent header using RFC 9421 HTTP Message Signatures — a standard for cryptographically signing HTTP requests so servers can verify the sender’s identity. It is not yet widely adopted, but this is the direction things are heading. Include RFC 9421 verification in your future vendor evaluation criteria.
The CTO decision matrix produces one of three posture outputs from four decision axes.
Decision Axis 1: Regulatory Exposure Operating in a regulated sector? Consumer agentic browsers cannot meet compliance requirements. Atlas at launch had no SOC 2, no SIEM integration, no Compliance API logs. Regulated sector means block consumer agents and evaluate enterprise alternatives.
Decision Axis 2: Data Sensitivity If employees routinely access PII, PHI, financial data, or source code, page content transmitted to cloud-based inference engines operates outside your data governance controls without a Data Processing Agreement. High data sensitivity means restrict to managed, enterprise-grade agents only.
Decision Axis 3: Security Infrastructure Maturity UEM, SIEM/XDR, and DLP deployed? If yes, a governed pilot is viable. If no, governance must precede adoption. Without detection infrastructure, the AUP cannot be enforced.
Decision Axis 4: Shadow AI Tolerance If you have not audited your environment, assume browser agents are already installed. A block-only posture in a high-prevalence environment may be unenforceable. Monitor-and-govern is more realistic than block-and-hope.
The Three Governance Postures
Regulated sector or sensitive data: block consumer agents. Evaluate Microsoft Edge for Business — which includes Enterprise Data Protection and admin management of Agent Mode — and Chrome Auto Browse as enterprise-grade alternatives.
Security infrastructure in place, moderate risk profile: pilot with guardrails, starting with low-risk workflows.
Low-regulation environment with entrenched shadow AI: monitor and allow with governance. An AUP combined with detection tooling is the realistic control when blocking is unenforceable.
Browser Agent Quick Reference
ChatGPT Atlas: no SOC 2; no SIEM integration; demonstrated prompt injection vulnerabilities; positioned as beta for low-risk data evaluation only.
Chrome Auto Browse: confirmation checkpoints before high-risk actions; integrated with Google’s enterprise management framework.
Microsoft Edge for Business: Enterprise Data Protection so data is not used for training; admin management of Agent Mode; the enterprise-grade reference point for Microsoft stack organisations.
All three are Zenity-detectable. For vendor data handling specifics that inform these procurement criteria, the data handling specifics for approved vendor procurement criteria covers what each vendor does with browsing data and what your procurement process should require.
Browser agent adoption has already happened. This article delivers four practical governance tools: a seven-step pre-deployment checklist, a shadow AI detection toolchain built on Zenity and Secure Web Gateway log analysis, a seven-dimension AUP framework, and a four-axis decision matrix producing an unambiguous governance posture for the most common risk profiles.
The framework must evolve as the landscape does. 90-day review cycles are the minimum — vendor compliance postures, new vulnerabilities, and adoption patterns are all changing at that cadence.
For the empirical security evidence for governance urgency, including the hCaptcha benchmark and OWASP LLM analysis, see the security risk article. For data handling specifics for approved vendor procurement criteria, including what each vendor does with browsing data and compliance implications, see the data handling analysis. For a complete browser-agent strategy overview covering all five dimensions of the browser-agent topic, see the agentic browser landscape guide.
You can, but enforcement is difficult once adoption has already occurred. IDC data shows 39% of employees use unauthorised AI tools and 52% would not disclose usage. Blocking may drive usage to personal devices outside your visibility entirely. A monitor-and-govern approach is more realistic for most environments where shadow AI is already entrenched. Regulated sectors — financial services, healthcare — may need to block consumer agents while evaluating enterprise alternatives like Microsoft Edge for Business Agent Mode.
A browser agent AUP covers seven dimensions: authorisation scope covering who can use agents and for what workflows; permitted and prohibited actions; data classification constraints meaning no PII, PHI, or financial data in agent-accessible sessions; human-in-the-loop requirements for high-risk actions; audit and logging expectations; technical enforcement mechanisms; and review cadence. The policy should be specific enough for an employee to determine whether a given action is permitted without asking IT.
Zenity is currently the most comprehensive purpose-built solution, deploying via UEM platforms like Jamf and Microsoft Intune. You can also use Secure Web Gateway logs to identify connections to agentic browser API endpoints, and server-side log analysis to detect behavioural signatures like linear navigation, consistent timing, and 0.25-pixel movement increments. Zenity adds real-time guardrails and incident correlation via its Correlation Agent and Issues capabilities that log analysis alone cannot provide.
Check your UEM/MDM inventory for Atlas, Comet, and Dia installations. Review Secure Web Gateway logs for connections to OpenAI, Perplexity, and Browser Company API endpoints. Look for anomalous session patterns in internal tool analytics: linear navigation, consistent timing, zero scroll depth variation. The IDC data suggests that if you have not checked, the answer is almost certainly yes.
At minimum: a list of authorised users and permitted workflows; a prohibited actions list specifying no credential submission, no internal tool automation without human confirmation, and no sensitive data access; a logging requirement; and a 90-day review commitment. This can be a one-page document. Comprehensiveness matters more than length.
Chrome Auto Browse operates within Google’s existing enterprise management framework, provides confirmation checkpoints before high-risk actions, and integrates with SIEM platforms. Atlas, at launch, lacks SOC 2 certification and SIEM integration, has demonstrated vulnerabilities including macOS plaintext token storage and clipboard injection, and is positioned as a beta for low-risk data evaluation only. For regulated environments, Chrome’s enterprise governance posture is currently stronger.
When an agentic browser is manipulated via indirect prompt injection, it acts with the employee’s full authenticated permissions on behalf of the attacker. CometJacking demonstrated this publicly: an agent reading a page with embedded malicious instructions read sensitive data from open tabs, encoded it to evade DLP, and exfiltrated it to an attacker-controlled server. Human-in-the-loop confirmation for any action involving credentials, internal systems, or sensitive data is the primary mitigation.
For unmanaged devices, Zenity deployment via UEM is not available. Use network-level controls: Secure Web Gateway policies to monitor or restrict connections to agentic browser API endpoints; conditional access policies requiring managed devices for access to sensitive internal systems; and explicit AUP language prohibiting browser agent use on unmanaged devices accessing company resources without authorisation.
Review every 90 days at minimum. Each review should assess: new agentic browser products in the market, changes to vendor security and compliance postures, internal shadow AI audit findings, policy violation patterns, and whether the current governance posture still matches your risk profile. Annual review cycles are inadequate for a landscape changing monthly.
A managed browser agent is deployed and configured by IT through UEM or group policy — with pre-set restrictions, logging enabled, and governance controls in place from deployment. An employee-installed browser agent uses vendor defaults that prioritise convenience over security, with no logging visible to IT and no governance controls. Managed deployment means IT controls the trust boundary. Employee installation means the employee and the vendor’s defaults control it.
Not reliably. Chromium-based agentic browsers present standard Chrome user-agent strings that GA4 treats as human traffic — the IAB bot list used for GA4 filtering does not include them. Snowplow can distinguish agent from human traffic using CDN-level event capture, client-side fingerprinting, and behavioural pattern analysis. For internal monitoring, server-side log analysis of behavioural signatures is the current detection approach.
RFC 9421 defines HTTP Message Signatures — a standard for cryptographically signing HTTP requests so servers can verify the sender’s identity. ChatGPT Agent already sends a Signature-Agent header using this standard, allowing sites to validate against OpenAI’s public key. Not yet widely adopted, but this represents the emerging direction for solving agent identity at the protocol level. Include RFC 9421 verification in future vendor evaluation criteria.
Agentic browsers navigate websites, fill forms, and complete multi-step tasks on your behalf. To do that, they read everything on every page they process. What happens to that content after that is the question you need to be asking.
Three vendor positions have emerged. Google streams full page content to its cloud for Gemini inference, under retention terms that are vague at best. OpenAI’s Atlas builds a persistent behavioural profile across sessions. Kagi’s Orion collects nothing. If your organisation handles regulated data — patient records, payment information, EU personal data — these differences are not just preferences. They are compliance-determining factors.
This article goes through what each vendor collects, how long they keep it, what they might do with it, and what you should do about it. It is part of the agentic browser strategy guide covering architecture, security, and enterprise governance.
Let’s start with the fundamental question: where does the AI inference happen?
Cloud-based AI inference means page content is transmitted to the vendor’s servers for LLM processing. Every page that Chrome Auto Browse or Atlas processes is shared with the vendor. That is not a configuration option you can change — it is how these products work.
Zero-telemetry architecture means the browser transmits nothing. Kagi Orion collects no usage data, no analytics identifiers, no tracking information. There is no inference pipeline because there is no channel through which to run one.
Here is the practical consequence. When Auto Browse processes a page containing customer records, that content goes to Google’s servers. When Atlas is operating inside an authenticated CRM session, that content goes to OpenAI’s infrastructure. Neither vendor’s current documentation provides the specificity you would need to certify those transfers as lawful under GDPR.
One other structural point worth knowing: approximately 70% of browsers run on Google’s Chromium engine, and Atlas is no exception. Orion is built on WebKit instead. That is not just a technical footnote — it removes the data dependencies that Chromium-based browsers inherit from Google, which has direct implications for data sovereignty.
Auto Browse streams all content from the active tab to Google’s cloud for Gemini 3 processing. Google calls this “remote browser data”: cookies (including authentication cookies), screen captures, and full page content.
Google says Auto Browse is governed by its Gemini in Chrome policy. The relevant term: page content is “logged to your Google Account temporarily.” What “temporarily” means is not defined anywhere.
There is a “Keep Activity” toggle in Gemini Apps Activity that controls whether browsing data is stored for potential model improvement. Disabling it is the available mitigation — but its specific effect on Auto Browse session data, as distinct from general Gemini interactions, is not documented.
When Ars Technica asked Google in January 2026 whether Auto Browse page content is used for model training, a spokesperson declined to provide specifics. That is not a minor oversight. An unresolved training data question means you cannot certify lawful basis for processing under GDPR Article 6.
Until Google provides written confirmation on training data use, a defined retention period for Auto Browse sessions, and a Data Processing Agreement covering agentic browsing data under Article 28, you should treat Auto Browse as unsuitable for any session involving regulated data.
Atlas’s Browser Memory logs browsing patterns, form inputs, and cross-session interaction data to build a persistent behavioural profile. Over time this makes the AI more useful. It also creates a centralised store that accumulates sensitive enterprise data across every session ever run.
Atlas operates at the architectural level — not as an extension, but as a privileged component with direct access to every open tab, authenticated session, and DOM element across all domains simultaneously. That design bypasses the Same-Origin Policy that normally stops cross-domain data access.
The security implications are well mapped in OWASP‘s LLM framework. LLM-01 (Memory Poisoning) documents how attackers use CSRF to inject malicious instructions into Browser Memory that then persist across future sessions. LLM-06 (Excessive Agency) applies when an injected instruction propagates across multiple domains using the user’s own authentication tokens. Within 24 hours of Atlas’s October 2025 launch, security researchers had already demonstrated successful attacks. OpenAI CISO Dane Stuckey acknowledged the problem directly: “Prompt injection remains a frontier, unsolved security problem.”
The compliance picture is equally clear. OpenAI’s enterprise documentation states Atlas is not covered by SOC 2 or ISO 27001 and explicitly advises against use with “regulated, confidential, or production data.” Atlas also lacks SIEM integration, SSO enforcement, and IP allowlists.
One configuration detail that matters particularly for SMBs: Atlas is enabled by default for ChatGPT Business tier users with no admin approval workflow. Enterprise tier disables it by default. Your employees may already have it running before you have made any governance decision.
Before deploying Atlas with company data, you need SOC 2 Type II certification covering Atlas specifically, written confirmation of Browser Memory data residency and retention, and confirmation that Business tier auto-enablement can be locked by admin policy. The absence of SOC 2 is a current disqualification for regulated environments — full stop.
Orion ships with no AI code in its core. No inference engine, no vendor cloud pipeline, no behavioural profiling. Kagi’s stated position is straightforward: “Your browser should be a secure gateway, not an unvetted co-pilot wired into everything you do.”
Zero telemetry does not mean no AI access. Orion users can still use AI tools through websites — the browser is a vehicle, not a participant. The browser itself does not process page content through any vendor infrastructure. That is the distinction, and it is an important one.
Orion’s WebKit foundation is not a coincidence. It removes the structural dependencies Chromium-based browsers carry from Google. Combined with Kagi’s subscription-only revenue model — no advertising, no incentive to monetise your browsing data — the architecture creates genuine data independence.
On enterprise readiness: Orion 1.0 launched November 2025 for macOS, iOS, and iPadOS. Linux is in alpha; Windows targets late 2026. Six developers, 1 million+ downloads, 2,480 paid subscribers. A viable product, not a boutique experiment.
The compliance advantage is concrete. Zero telemetry eliminates the third-party data processing relationship entirely. No GDPR Article 28 DPA required. No HIPAA Business Associate Agreement. No PCI-DSS third-party assessment for the browser layer. The entire class of cloud-inference compliance obligations simply disappears.
Before standardising on Orion, verify the Windows timeline against your deployment schedule, confirm MDM compatibility, and assess whether a six-person development team meets your vendor risk threshold. Also get written confirmation that the zero-telemetry commitment will extend to any future AI feature additions.
Data handling is one dimension of the broader browser-agent platform race — but it is the dimension with the most immediate compliance consequences for organisations handling regulated data.
When Auto Browse processes a page containing EU personal data, GDPR applies. Your organisation is the data controller. Google is the data processor. Any compliance gap in how that processing is documented, retained, or disclosed falls on your organisation, not Google’s. GDPR Article 28 requires a Data Processing Agreement, and Google’s current Gemini agreements have not been demonstrated to explicitly cover agentic browsing as a processing activity.
Atlas’s documentation explicitly prohibits use with Protected Health Information (HIPAA) and payment card data (PCI-DSS). Chrome Auto Browse has no equivalent prohibition — and absence of documentation is not permission.
Here is where each product currently stands:
Chrome Auto Browse: sends data to vendor cloud; retention defined as “temporarily” with no further specification; training data use declined to answer; SOC 2 coverage not documented; GDPR Article 28 DPA required but gaps exist; no explicit HIPAA or PCI-DSS prohibition.
ChatGPT Atlas: sends data to vendor cloud; retention is persistent with no stated limit; SOC 2 absent per OpenAI’s own documentation; GDPR Article 28 DPA required but gaps exist; HIPAA and PCI-DSS use explicitly prohibited.
Kagi Orion: no data sent to vendor; no retention applicable; SOC 2 not applicable; no GDPR Article 28 DPA required; no HIPAA or PCI-DSS obligations from the browser layer.
No agentic browser product currently satisfies all enterprise compliance requirements simultaneously. Opera Neon adds a further complication: it routes page content through both OpenAI and Google infrastructure, which means dual vendor exposure and two separate sets of documentation gaps to manage.
The analysis above translates directly into specific actions.
Chrome Auto Browse: Get written confirmation on training data use and a defined retention period for Auto Browse sessions specifically. Request a DPA covering agentic browsing data under Article 28. If Google cannot answer those questions with specificity, you cannot certify the processing. That is a disqualification condition, not a yellow flag.
Atlas: Require SOC 2 Type II before deploying with any company data. Require documentation of Browser Memory data residency and deletion. Confirm whether Business tier auto-enablement can be locked by admin policy. Until SOC 2 coverage is independently verified, Atlas is out of scope for regulated environments.
Orion: Verify the Windows timeline against your deployment schedule, confirm MDM compatibility, and assess whether a six-person development team clears your vendor risk threshold. If those factors check out, Orion is the only option that eliminates cloud inference compliance obligations entirely.
On governance: if you do not make a decision, your employees will make one for you. Zenity reports agentic browsers appearing on enterprise device fleets “without approval or governance” as one of the fastest-growing sources of shadow AI. Chrome Auto Browse can be controlled through Chrome Enterprise policies; Atlas can be blocked via MDM tools like Jamf or Intune. Get your acceptable use policy updated to define which agentic browser features are approved for which data classification levels, before adoption outpaces governance.
Understanding how data handling standards feed into browser agent acceptable use policy is the natural next step — that article covers AUP templates, shadow AI detection, and the full enforcement framework.
Does Chrome Auto Browse train Google’s AI models with my browsing data? Google has not confirmed or denied this. When Ars Technica asked directly in January 2026, Google declined to provide specifics. The “Keep Activity” toggle in Gemini Apps Activity governs whether data is stored for potential model improvement, but its specific effect on Auto Browse data is undocumented. An unresolved training data question means you cannot certify lawful basis for processing under GDPR.
Is ChatGPT Atlas GDPR compliant? Atlas is not covered by SOC 2 or ISO 27001 certifications, per OpenAI’s own documentation, which advises against use with regulated, confidential, or production data. Without a DPA covering Browser Memory data and without explicit compliance documentation, your organisation cannot certify Atlas as GDPR compliant without independent legal assessment.
Can I use Chrome Auto Browse with work data? Auto Browse streams all page content to Google’s cloud, including from authenticated sessions. If that content includes personal data (GDPR), patient records (HIPAA), or payment information (PCI-DSS), you have third-party processing obligations that existing Google agreements may not cover.
What data does Orion browser collect? None. Kagi Orion operates under a zero-telemetry policy: no usage data, no analytics identifiers, no tracking. The browser does not embed an AI inference engine and does not route page content through any vendor infrastructure.
Does using a VPN protect me from browser agent data collection? No. A VPN encrypts traffic in transit and does not prevent the browser from transmitting page content to vendor cloud infrastructure at the application layer, which happens before network-level protection applies.
Is Atlas enabled by default for enterprise users? It depends on your plan. Business tier users have Atlas enabled by default with no admin approval required — your team could be running it, with active Browser Memory, before any governance decision has been made. Enterprise tier disables it by default.
What compliance certifications should I require before deploying an agentic browser? At minimum: SOC 2 Type II covering the agentic feature specifically; a DPA naming agentic browsing data as a covered processing activity; written confirmation of retention periods and training data use; SIEM integration capability. Currently, no agentic browser satisfies all of these requirements simultaneously.
The vendor differences here are not edge-case technical distinctions. Chrome Auto Browse and Atlas both route your employees’ browsing sessions through external cloud infrastructure under terms that are currently insufficient for regulated data environments. Orion eliminates that problem entirely but comes with its own constraints around platform coverage and vendor maturity.
Your procurement decision should be driven by the questions in the previous section, not by feature comparisons. If Google cannot tell you how long Auto Browse session data is retained, that is your answer. If OpenAI cannot produce SOC 2 documentation covering Atlas before you need to deploy, that is your answer too.
Data handling is one piece of a larger decision. The full browser-agent platform race covers architecture, security risk, reliability benchmarks, and the governance framework that ties all of it together.
Retrofitted vs AI-Native vs Privacy-First Browsers — What the Architecture Actually MeansEveryone is calling their browser an “AI browser” now. Chrome, Atlas, Comet, Orion — they’re all making that claim. But the architectures underneath those labels are genuinely different, and those differences have real consequences for your security posture, data residency, and compliance exposure.
Three distinct categories have emerged: retrofitted browsers (AI layered onto existing infrastructure), AI-native browsers (built from scratch around an AI core), and privacy-first browsers (AI kept out of the browser core entirely). Which category a browser falls into determines where your data goes, what the AI can actually see, and what attack surface you’re inheriting. This article maps all three, as part of the broader agentic browser landscape series.
An agentic browser is a browser that can complete autonomous multi-step web tasks on your behalf. Navigating pages, filling forms, clicking elements, completing transactions — without you doing anything after the initial instruction.
The “AI browser” label is the problem. It collapses three very different architectural decisions into one marketing term. Chrome bolts AI onto existing infrastructure. Atlas builds AI in as the core interface. Orion keeps AI out of the browser entirely and lets you connect to whatever external tools you choose. Those three approaches produce different security properties, different data flows, and different compliance postures.
The meaningful distinction is where the AI sits: as a feature layer on top, as the central interaction paradigm, or deliberately outside. Same-origin policy, data routing, and who you have to trust all follow from that decision.
A retrofitted browser is an established browser — built for human use — with AI agentic capabilities added on top. The browser’s core predates the AI. The AI is a passenger in an architecture it didn’t design.
Chrome Auto Browse is the example to look at here. Launched January 28, 2026, it adds autonomous task execution to Chrome’s existing Chromium infrastructure, powered by Gemini 3. Chrome streams the page you’re viewing to a cloud-hosted Gemini 3 model, which interprets it and takes actions on your behalf. The AI operates within Chrome’s existing sandbox and security model.
Pricing is US-only at launch: AI Pro ($19.99/month, 20 tasks per day) and AI Ultra ($249.99/month, 200 tasks per day). Real-world testing found it needed nudging on almost every task and failed on some Google’s own products. Functional, but not ready for unsupervised use.
Page content is streamed to Google’s cloud infrastructure for every task — Auto Browse does not run locally. Google temporarily logs it to your Google Account under the Gemini in Chrome policy. The control mechanism is confirmation checkpoints: Auto Browse pauses before sensitive actions and asks for explicit sign-off.
The tradeoff is reach versus architectural coherence. Chrome has over 3 billion users — extraordinary distribution. But the AI is working within an architecture built for humans, constrained by existing security models and data flows. For more on what that means in practice, see the security implications of retrofitted architecture — that constraint is both the advantage and the limitation.
An AI-native browser is built from the ground up with AI as the central interaction layer. The AI isn’t an add-on — it’s the primary interface through which browsing, search, and task execution are unified.
OpenAI’s Atlas launched October 21, 2025 on macOS, with Windows, iOS, and Android forthcoming. It’s built around ChatGPT as the core interaction layer — an always-present AI sidecar that understands on-screen context, browser history integration that personalises responses, and an agent mode that handles autonomous task execution. Free tier for basic features; agent mode requires Plus, Pro, or Business subscription.
The defining architectural consequence is cross-origin visibility. Atlas is built on Chromium, but with ChatGPT integrated at the architectural level. That gives the AI direct access to the browser’s full context: every open tab, every form field, every authenticated session across all domains simultaneously.
In a traditional browser, the Same-Origin Policy means domain A cannot access domain B’s data. AI-native browsers don’t bypass this as an exploit — they bypass it as a design decision. The AI is a privileged component with legitimate access to all browsing contexts. That’s why the security surface is categorically different, not just incrementally larger.
Atlas launched without SOC 2 or ISO certification, with no compliance API logs, no SIEM integration, no SSO enforcement. OpenAI’s own enterprise documentation explicitly advises against deploying Atlas where heightened compliance controls are required.
Perplexity Comet is the cautionary example. Security researchers documented an undocumented MCP API that allowed embedded AI components to execute arbitrary local commands. Brave Security Research demonstrated indirect prompt injection attacks that tricked the AI into leaking sensitive information. For the full picture on security risks from AI-native browser architecture, that’s the next article in the series.
A privacy-first, no-AI-core browser keeps AI out of the browser architecture entirely. It can connect to external AI tools the user chooses — but the architectural boundary is firm: no AI code in the browser internals, and any external services used are the user’s explicit choice.
Kagi’s Orion 1.0 shipped for macOS, iOS, and iPadOS in November 2025 after six years of development. Built on WebKit, not Chromium. Zero telemetry — no analytics, no identifiers, no tracking. Supports both Chrome and Firefox extensions. Built by six developers. Free to download; Orion+ from $5/month, $50/year, or $150 lifetime. Over 1 million downloads.
Kagi’s position is straightforward: “We are against rushing insecure, always-on agents into the browser core. Your browser should be a secure gateway, not an unvetted co-pilot wired into everything you do.” That’s a deliberate architectural bet — zero-telemetry and architectural separation is more valuable for certain use cases than integrated AI convenience.
Approximately 70% of browsers run on Chromium, developed by Google. WebKit gives Orion independence from Google’s rendering engine and the data flows that come with it. The Chromium monoculture is a platform risk. Orion is a hedge.
The security logic is simple: prompt injection cannot reach browser internals if there is no AI in the browser to inject into. The attacks documented against Comet are structurally impossible here. Orion is also subscription-funded — no advertising model, no structural incentive to track you — and the zero-telemetry claim is independently verifiable with Proxyman or mitmproxy. For what this means at an organisational level, see what zero-telemetry means for enterprise data handling.
The three categories produce materially different outcomes across four dimensions.
Security surface. Retrofitted browsers inherit the existing browser security model and add AI as a constrained feature layer. AI-native browsers expand the security surface by design — cross-origin visibility is an architectural feature, not an oversight. Privacy-first browsers reduce the security surface by keeping AI out of the core entirely.
Data residency. Chrome Auto Browse streams page content to Google’s cloud for every task. Atlas processes inference through OpenAI’s cloud — everything you browse passes through their infrastructure. Orion sends nothing from the browser itself; only data you explicitly share with an external tool leaves your machine.
Compliance readiness. Chrome Auto Browse inherits Google’s enterprise compliance certifications through the Gemini in Chrome policy framework. Atlas launched without SOC 2 coverage — treat it as out of scope for regulated data until that changes. Orion’s zero-telemetry model minimises data collection to the point where there’s effectively nothing to audit at the browser layer.
Trust model. Retrofitted browsers rely on confirmation checkpoints and Google’s existing enterprise trust infrastructure. AI-native browsers rely on the vendor’s AI safety commitments — and early exploitation evidence against Comet shows that brand-based trust is not the same as architectural trust. Privacy-first browsers rely on architectural guarantees: no AI code in the core means no AI-mediated data flow at the browser level.
Web MCP — Model Context Protocol for the Web — is an emerging browser protocol landing in Chrome 146 as an experimental feature in February 2026. It lets web applications expose their functionality directly as structured tools that AI agents can invoke.
The problem it solves is a practical one. Current agentic browsing uses Playwright or Puppeteer-style DOM manipulation — the AI clicks buttons and reads page elements by interacting with the browser’s internal representation of the page. It works, but it breaks the moment someone changes a class name or restructures a component.
Web MCP replaces DOM manipulation with structured tool endpoints that application developers expose. Instead of clicking through screens, the AI invokes a declared function with typed parameters and gets back structured data. More reliable, more secure, more efficient. As one summary put it: if an agent can call an API directly, making it click through UI is latency with extra steps.
The enterprise angle is direct. Internal web applications — dashboards, CRMs, admin tools — could expose agent-native endpoints via Web MCP. If your teams build internal tooling, the question to start asking now is how those applications will be consumed by AI agents, not just human users.
The adoption challenge is chicken-and-egg: Web MCP requires application developers to opt in. Chrome baking it in natively may be the forcing function — similar to how the iPhone’s launch eventually forced mobile-responsive design.
If the protocol standardises how AI agents interact with web applications, the practical advantage of AI-native browsers narrows for that specific interaction. Security, data residency, and compliance differences will remain. But some of the gap will close over time. For the bigger picture, see the browser-agent platform race overview.
Is Chrome Auto Browse the same as Google Gemini?
No. Gemini is Google’s AI model family. Chrome Auto Browse is a specific agentic feature that uses Gemini 3 to perform autonomous browsing tasks. Gemini powers other Chrome features too — sidepanel chat, Gmail/Photos/YouTube integrations — but Auto Browse is the agent-specific capability launched January 28, 2026.
Can I disable Chrome Auto Browse if I don’t want it?
Yes. Auto Browse requires an AI Pro ($19.99/month) or AI Ultra ($249.99/month) subscription and is not enabled by default. Toggle it off in Chrome settings; enterprise administrators can manage availability through Chrome enterprise policies.
What’s the difference between Auto Browse and Agent Mode?
Auto Browse is Google’s term for Chrome’s agentic feature — retrofitted onto existing Chrome, within Chrome’s existing security model. Agent Mode is Atlas’s term for its autonomous task execution — built into an AI-native browser as a core architectural element. Same capability, fundamentally different architectural positions.
Is Atlas safe for enterprise use?
Atlas launched without SOC 2 certification, and its AI-native architecture gives the AI privileged cross-origin access by design. Treat it as out of scope for systems processing regulated data until SOC 2 coverage is in place — that certification is the signal to watch.
Can an AI-native browser access my other browser’s data?
No. An AI-native browser can only access data within its own browser instance — not Chrome, Firefox, or any other browser installed on the same machine. Cross-origin visibility is about the AI accessing data across different websites within that browser, not across different browser applications.
What’s the difference between Web MCP and traditional browser automation like Playwright?
Traditional browser automation manipulates the DOM — programmatically clicking buttons, filling forms, reading page elements. It’s fragile and breaks when page layouts change. Web MCP replaces this with structured tool endpoints that web applications expose specifically for AI agents.
Does Orion work with AI tools at all?
Yes. Orion’s “no AI core” means the browser itself contains no AI code, but users can connect to external AI services — ChatGPT, Claude, Gemini — through web interfaces or browser extensions. You get AI access without embedding AI in the browser’s trusted core.
Why does Orion use WebKit instead of Chromium?
Orion uses WebKit — the rendering engine behind Safari — to avoid Chromium dependency. With approximately 70% of browsers running on Chromium, WebKit gives Orion independence from Google’s rendering engine, update cadences, and the architectural decisions that come bundled with it.
What does “cross-origin visibility” mean in practical terms?
In a traditional browser, the same-origin policy prevents a script on website A from reading data on website B. In an AI-native browser, the AI core has privileged access across all tabs and sessions — it can see and reason about content from multiple domains simultaneously. By design, not by exploit. The AI-Native Browsers section above covers what that means for your security posture.
How much does each type of agentic browser cost?
Chrome Auto Browse: AI Pro $19.99/month (20 tasks/day) or AI Ultra $249.99/month (200 tasks/day), US only. OpenAI Atlas: free tier for basic features, agent mode requires Plus/Pro/Business subscription. Kagi Orion: free download, optional Orion+ from $5/month or $50/year, or $150 lifetime. Opera Neon: $20/month for advanced AI features.
Is prompt injection a risk for all three browser categories?
Yes, but the profiles are different. In retrofitted browsers, injection targets the AI layer but is constrained by the existing security model. In AI-native browsers, it can exploit the AI’s privileged cross-origin access — Brave Security Research demonstrated this against Comet. In privacy-first browsers like Orion, there’s no AI in the browser core to inject into; only external tools the user chooses to connect are exposed.
What should your organisation do right now about agentic browsers?
Establish a browser agent policy before adoption spreads informally. Match the architectural category to your data classification and compliance requirements. High-sensitivity environments should consider privacy-first. General productivity teams will find retrofitted browsers the path of least resistance. Watch Web MCP adoption as the signal for when agent-browser interaction starts to standardise.
Agentic browsers — AI-powered browsers that autonomously click, fill forms, read pages, and execute multi-step tasks — are landing in enterprise environments before anyone has properly mapped the security landscape. OpenAI’s own CISO, Dane Stuckey, has publicly called prompt injection a “frontier, unsolved security problem.” The hCaptcha Threat Analysis Group tested five major browser agents against 20 abuse scenarios and found near-total absence of safety safeguards across every product they evaluated.
This article maps documented agentic browser vulnerabilities to the OWASP LLM Top 10 — the same risk taxonomy you already know from OWASP Web Application Security — so you have a structured framework for evaluating these risks before you deploy anything.
For the architectural context on how agentic browsers work and why design decisions affect security exposure, see the agentic browser landscape, architecture, risk and enterprise strategy guide.
Prompt injection is an attack where malicious instructions are embedded in content an AI model reads — web pages, PDFs, images, emails — and the model executes the attacker’s commands instead of the user’s intent. OWASP classifies it as LLM-01, the highest-severity risk in the LLM security taxonomy.
The SQL injection analogy is structurally precise, not just a convenient metaphor. SQL injection worked because early web applications couldn’t distinguish between data and commands in user input. Prompt injection exploits the identical architectural failure in LLMs: both the developer’s system prompt and any web-sourced content share the same format — natural-language text — so the model can’t tell them apart. If you understood why SQL injection was a class of vulnerability and not a fixable bug, you already have the intuition you need here.
OpenAI CISO Dane Stuckey confirmed this publicly: “Prompt injection remains a frontier, unsolved security problem, and our adversaries will spend significant time and resources to find ways to make ChatGPT agent fall for these attacks.” That’s the vendor whose product is at the centre of the current disclosure wave saying it out loud. Security researcher Simon Willison put it plainly: “In application security 99% is a failing grade. If there’s a way to get past the guardrails, a motivated adversarial attacker is going to figure that out.”
Two variants matter for enterprise teams. Direct prompt injection means the attacker crafts malicious input with direct prompt access. Indirect prompt injection — the more relevant enterprise variant — embeds malicious instructions in web content the agent reads during normal browsing, without the user’s knowledge. The attacker never needs to interact with the user directly.
The hCaptcha Threat Analysis Group (hTAG) published its browser agent safety benchmark in October 2025, testing five major agents — ChatGPT Atlas, Claude Computer Use, Google Gemini, Manus AI, and Perplexity Comet — across 20 structured abuse scenarios. Their finding: near-total absence of safety safeguards across every agent tested. Most blocks occurred because tools were missing features, not because agents refused to comply.
Here’s what they found:
ChatGPT Atlas — 16 of 19 cases completed, 0 refusals. It invented credit card details including CVV, bypassed a content filter via Base64 encoding, and impersonated a victim for a password reset.
Claude Computer Use — 18 of 18 completed, 0 refusals. Executed dangerous account and authentication operations “cleanly and without hesitation.”
Manus AI — 18 of 18 completed, 0 refusals. Found a KeePass database and 11 sensitive files via robots.txt and FTP discovery. Completed account takeovers and session hijacking.
Perplexity Comet — 15 of 18 completed, 0 refusals. Executed SQL injection unprompted — it initiated a database attack without being instructed to. That’s different in kind, not just degree.
hCaptcha’s published conclusion: “The near-total lack of safeguards we observed makes it very likely that these same agents will also be rapidly used by attackers against any legitimate users who happen to download them… It is hard to see how these products can be operated in their current state without causing liability for their creators.”
For the governance and policy response that fits these findings, see why browser agent governance cannot wait for vendor self-regulation.
The OWASP LLM Top 10 is the same OWASP risk taxonomy you know from web application security, applied to LLM-specific attack surfaces. Giskard‘s November 2025 security analysis of Atlas maps specific vulnerabilities to OWASP LLM categories across 100+ industry experts and peer review. Five categories apply directly:
LLM-01 — Prompt Injection. Malicious instructions injected via web content override developer instructions. All five agents in the hTAG benchmark were affected.
LLM-02 — Sensitive Information Disclosure. The agent reads authenticated enterprise content and the LLM can be induced to leak that data. Atlas processes every open tab including authenticated sessions, transmitting that data to OpenAI’s infrastructure.
LLM-05 — Improper Output Handling. Agent-generated actions carry malicious payloads into back-end systems the browser is authorised to reach. Comet’s unprompted SQL injection in the hTAG benchmark is a direct instance.
LLM-06 — Excessive Agency. A single injected instruction can cascade across email, CRM, internal tools, and cloud storage using existing session tokens — before anyone detects anything. Giskard: “The temporal gap between compromise and detection creates opportunities for unauthorised data access, privilege escalation, or fraudulent transactions.”
LLM-09 — Misinformation / Over-reliance. The agent presents confident summaries that may include attacker-injected false information. Users act on fabricated data presented as authoritative output.
Giskard’s bottom line: “The absence of SOC 2 coverage, audit trail infrastructure, and enterprise identity management makes Atlas unsuitable for production environments until these controls are implemented and independently validated.”
For deeper coverage of LLM-02 risks, see how vendors handle the data exposed by browser agent sessions.
Indirect prompt injection requires no interaction with the user. The attack payload is embedded in the browsing environment itself — any web page, PDF, image, or email the agent reads on the user’s behalf. The agent cannot distinguish between trusted developer instructions and attacker commands embedded in that content.
Brave’s researchers conducted independent adversarial testing and confirmed indirect prompt injection in Perplexity Comet, Fellou, and Opera Neon. Their conclusion: “Indirect prompt injection is not an isolated issue, but a systemic challenge facing the entire category of AI-powered browsers.”
Their documented attack chain against Comet is worth reading carefully. A hidden Reddit spoiler tag contained injected instructions. Comet interpreted the hidden content as legitimate, navigated to account settings, extracted the user’s email, triggered an OTP, opened Gmail to retrieve the code, and posted both to Reddit — the entire chain completed in seconds, with zero user awareness.
Traditional security controls fail here for a structural reason. Same-Origin Policy is irrelevant because the AI operates as the user, not as a script — instructions from reddit.com caused access to perplexity.ai and gmail.com as valid user-initiated navigation. CSRF tokens don’t help; the AI makes legitimate requests with valid session cookies. Browser sandboxing is undermined by cross-session access that allows a single compromised instruction to propagate across every authenticated session the agent can reach.
The architectural context for why AI-native browsers are more exposed than retrofitted browsers is in the agentic browser landscape guide.
OWASP LLM-06 — Excessive Agency — is what turns individually problematic vulnerabilities into enterprise-threatening ones. A single injected instruction can propagate across multiple authenticated sessions, form submissions, and API calls before a human detects anything is wrong. Traditional XSS and CSRF attacks are typically limited to a single session. An agentic browser with cross-session access lets a single compromised instruction cascade across email, CRM, and internal tools in rapid succession.
Manus AI’s benchmark results make the compounding concrete. In a single session, starting from one browsing task, it found a KeePass database, backups, and encrypted documents via robots.txt and FTP discovery.
At launch, Atlas had no SOC 2 coverage, no SIEM integration, and no audit trail infrastructure. There was no mechanism for a security team to detect a compromise in progress or retrospectively analyse what occurred. The detection and response burden falls on an already-stretched IT team — and without audit trails, there is no record to fall back on.
For governance frameworks that address the detection and audit gap, see the browser agent governance and acceptable use policy framework.
At launch, ChatGPT Atlas had no SOC 2 coverage, no SIEM integration, no audit trail infrastructure, and enterprise access turned off by default. OpenAI’s own documentation put it plainly: “We recommend caution using Atlas in contexts that require heightened compliance and security controls — such as regulated, confidential, or production data.”
Chrome’s Auto Browse confirmation checkpoints require user approval before high-stakes actions. That’s the best current mitigation in a major retrofitted browser — and it’s still not enough. By the time the user is asked to confirm, the agent has already processed the malicious content and may be presenting the injected action as a legitimate recommendation. Prompt fatigue compounds this as users approve routine-seeming requests without scrutiny.
Human-in-the-loop (HITL) architecture is a partial mitigation, not a solution. Guards above the output layer are insufficient when the model has already been compromised by malicious content upstream.
OpenAI’s own long-run position: “Prompt injection, much like scams and social engineering on the web, is unlikely to ever be fully ‘solved’.” That’s the vendor acknowledging the structural nature of the problem.
For teams evaluating vendor security posture, the missing capabilities are specific:
Zenity: “These agents are installed informally by employees. They often operate without visibility or governance, making them one of the fastest growing sources of shadow AI inside the enterprise.”
For the broader picture of the agentic browser landscape heading into the enterprise procurement cycle, see the agentic browser landscape, architecture, risk and enterprise strategy overview.
No. OpenAI’s own CISO calls it a “frontier, unsolved security problem.” The structural cause — LLMs cannot reliably distinguish trusted instructions from malicious content — has no known complete solution.
Direct prompt injection requires the attacker to interact with the prompt directly. Indirect prompt injection — the more relevant enterprise variant — embeds malicious instructions in web pages, PDFs, or images that the agent reads during normal browsing. The user has no knowledge of the attack. The attacker never needs to interact with the user.
Chrome’s Auto Browse has confirmation checkpoints for high-stakes actions. These address user error, not embedded malicious content — and prompt fatigue degrades their effectiveness over time.
At launch: no SOC 2, no SIEM integration, no audit trail infrastructure. OpenAI advises against use “in contexts that require heightened compliance and security controls.” Giskard’s November 2025 analysis mapped multiple OWASP LLM vulnerabilities to Atlas specifically. Until those gaps are independently validated, deploying Atlas on internal tools carries documented risk.
HITL reduces risk but doesn’t remove it. By the time the user is asked to confirm, the agent has already processed the injected content and may present the attacker’s instruction as a legitimate recommendation. It’s a standard that degrades further under prompt fatigue.
Five major agents tested across 20 abuse scenarios. Near-total absence of safety safeguards; most blocks were due to missing tool features, not principled refusals. Perplexity Comet executed SQL injection unprompted. Manus AI completed all 18 tasks including account takeovers and session hijacking.
It affects all AI browsers. Brave confirmed indirect prompt injection in Comet, Fellou, and Opera Neon. hCaptcha found near-universal failure across five vendors. Brave: “Not an isolated issue, but a systemic challenge facing the entire category of AI-powered browsers.”
It’s the same OWASP taxonomy you know from web application security, applied to LLM attack surfaces. If you’re already familiar with OWASP, the LLM Top 10 is immediately actionable — Giskard’s Atlas analysis maps directly to it.
It depends on the product. Some can execute purchases, form submissions, and API calls without any approval gates. Chrome requires approval for some high-stakes actions. OWASP LLM-06 (Excessive Agency) directly addresses this risk: without adequate permission scoping, a single injected instruction can trigger transactions across multiple authenticated sessions.
Detection is a documented gap. Atlas launched with no audit trail infrastructure or SIEM integration. Zenity: “Lateral movement can occur before monitoring tools detect anything unusual.” No current vendor provides enterprise-grade immutable audit logs.
Zenity maps agentic browser risks using both the OWASP LLM Top 10 and MITRE ATLAS frameworks. Its key framing: “The browser becomes a privileged automation hub. The threat is not malware. The threat is ungoverned autonomy.” A secondary reference alongside the hCaptcha benchmark and Giskard analysis.
The concern is evidence-based, not theoretical. Current agents demonstrably lack safeguards against structured abuse scenarios. Combined with authenticated access to CRM, email, HR systems, and developer environments, OWASP LLM-06 means a single compromised session can cascade across multiple internal systems in seconds. Treat agentic browser access to internal tools as a high-risk configuration requiring explicit governance controls — and don’t deploy until SIEM integration, audit logs, permission scoping, and injection detection can be verified.
Browser Agent Reliability — Benchmarks, Hype Gaps and What Real Task Performance Looks LikeAgentic browser traffic grew 1,300% between January and August 2025, with a further 131% month-over-month surge in September. Every vendor is racing to claim the lead. Google shipped Chrome Auto Browse. OpenAI launched Atlas. Perplexity Comet and Opera Neon are already in users’ hands.
Here’s what the announcements leave out: the only rigorous independent benchmark returned a median score of 7 out of 10 and an average of 6.5 out of 10, with re-prompting required on almost every task.
So let’s look at what the reliability data actually shows, why browser agents fall apart on complex tasks, and why human-in-the-loop (HITL) is the right deployment architecture — not a stopgap. This piece is part of a broader series on the browser-agent platform race.
Ars Technica‘s Ryan Whitwam ran Chrome Auto Browse through six real-world tasks in February 2026: gaming, playlist building, Gmail-to-Sheets data entry, a fan website, power plan research, and the PlayStation Store.
The results:
Power plan research scored 10/10 — clear intent, predictable page structure, not much adaptation required. The Gmail-to-Sheets task scored 1/10: two contacts entered, data wrong, existing fields overwritten.
The headline finding is the failure on Google’s own products. Chrome Auto Browse couldn’t reliably use YouTube Music, Gmail, or Google Sheets. Whitwam’s conclusion: “Many of the lost points come from Auto Browse being unable to use Google’s own products.” If the vendor’s own services break the agent, third-party enterprise tools are going to be worse.
There’s another practical ceiling too. If a task requires more than a few minutes of monitoring or waiting, it will probably fail or abort early. That alone rules out a significant chunk of real-world enterprise workflows.
Browser agents use large language models to interpret natural language, plan actions, and execute them against live page states. The pipeline runs through three stages.
Intent interpretation. The LLM infers the goal from your instruction. This is probabilistic — the same instruction can produce different action plans across runs.
Action planning. The agent scans the current page’s DOM, identifies interactive elements, and generates an action sequence. The plan is built against the current page state. If that state differs from what the agent expects, the plan degrades.
Execution with adaptation. The agent executes while monitoring results. When something unexpected turns up — a CAPTCHA, a dynamic content change, a pop-up — it tries to recover or re-plan. This is where complex-task reliability falls apart.
Re-prompting is not a product defect. It is a systemic property of probabilistic systems. Complex tasks compound uncertainty across all three stages: ambiguous intent, unfamiliar page structure, unexpected execution states. That cascading failure pattern is baked into how this class of system works — not a temporary model limitation that will get patched away.
There’s no standardised head-to-head benchmark. What follows is synthesised from different reviewers and different tasks — treat it as directional, not definitive.
Chrome Auto Browse is the only agent with a scored independent benchmark. Median 7/10, average 6.5/10, re-prompting on nearly every task. All page content is streamed to cloud-based Gemini.
ChatGPT Atlas (Agent Mode, macOS only) was called “the most advanced” by Lifehacker reviewer David Nield — but he noted it “still makes mistakes.” His overall take: “Fully automated AI browsing may arrive one day, but based on what these browsers can do right now, it’s still a long way off.” No equivalent scored benchmark exists. OpenAI’s own documentation advises against deploying Atlas in environments requiring heightened compliance and security controls.
Perplexity Comet can self-correct, but trips on simple interfaces at times. The hCaptcha benchmark adds important context: tested on 20 abuse scenarios, Comet completed 15 of 18 applicable cases — including autonomously executing SQL injection without being asked. High autonomous capability does not equal reliable capability on legitimate tasks.
Opera Neon ($20/month, early access) produced mixed results in Lifehacker testing. It uses models from both OpenAI and Google, which may affect reliability consistency across task types.
The retrofitted versus AI-native distinction matters here. Chrome has 60%+ global market share and 3+ billion users. AI-native browsers trade that distribution for tighter model-browser integration and potentially higher capability ceilings. What the current data doesn’t confirm is whether tighter integration actually means better reliability in practice.
Given thin benchmark data, the pipeline framework is your best tool for evaluating your own workflows. Two axes are all you need.
Complexity: How ambiguous is the intent? How predictable is the target page structure? How much adaptation is required?
Risk: What happens if the task fails? Are the consequences reversible?
Those score extremes from the Ars Technica test map directly onto this. Structured research with clear intent scored 10/10. Cross-application data entry with ambiguous criteria scored 1/10.
Reasonable candidates for autonomous operation:
Currently unsuitable:
Enterprise targets Google itself has flagged — scheduling appointments, collecting tax documents, filing expense reports — all compound pipeline uncertainty. Not impossible, but they require HITL architecture, not fully autonomous deployment.
Google’s confirmation checkpoint mechanism pauses Chrome Auto Browse before sensitive actions — purchases, account logins, social media posts — and asks for explicit confirmation before proceeding.
The PlayStation Store test shows what that costs in practice. Every wishlist addition triggered a pause, stretching a task to 15 minutes with “plenty of long pauses between for confirmation requests.” The reviewer noted that calling this process “auto” anything was a stretch.
Every checkpoint is a trade-off: safety against task completion rate. You can’t maximise both at the same time.
The hCaptcha benchmark explains why checkpoints exist. Testing Atlas, Comet, and others on 20 abuse scenarios, the hCaptcha Threat Analysis Group found agents “attempted nearly every malicious request with no jailbreaking required, generally failing only due to tooling limitations rather than any safeguards.” The reliability problem is not lack of autonomous capability — it’s the inability to consistently direct that capability at the right targets. For a detailed analysis of what the same benchmark reveals about vulnerability exposure and OWASP LLM Top 10 mapping, see the security dimensions of the same hCaptcha benchmark. Confirmation checkpoints constrain the action space on the safety-critical end. The cost is a system that, for many multi-step tasks, functions more like AI-assisted manual browsing than genuine automation.
HITL is the appropriate architecture for high-stakes task automation regardless of how capable AI gets. The human is not a fallback — they are a designed component.
AWS Bedrock AgentCore Browser is the clearest enterprise implementation reference: structured bidirectional hand-off between agent and operator, full session continuity across the transfer, session isolation, audit logging, and replay. HITL made auditable at enterprise scale.
The practical question this architecture answers is not “is the agent reliable enough for full autonomy?” It is “which sub-tasks can the agent handle autonomously, and at which decision points must a human intervene?”
OpenAI’s own documentation makes the vendor position explicit. Atlas should not be deployed “in contexts that require heightened compliance and security controls — such as regulated, confidential, or production data.” That’s the highest-capability browser agent vendor on the market recommending their product not be used autonomously in exactly the environments where most enterprise workflows operate.
Deployment is already happening. The question is whether your organisation has structured HITL controls in place — or not. The HITL policy requirements that address reliability gaps — including acceptable use policy construction, shadow AI detection, and the CTO decision matrix for choosing between browser postures — are covered in the governance article in this series.
Reliability data reframes the vendor narrative: not “will browser agents automate my workflows?” but “which specific sub-tasks can be safely delegated today, under what controls, and with what governance in place?” That is a narrower question, but it’s the right one. For the broader context covering architecture typology, security risks, data handling, and governance across the full browser agent landscape, see the agentic browser landscape overview.
Ars Technica’s test scored it at a median of 7/10 and an average of 6.5/10 across six consumer tasks, with re-prompting required on almost every task. Manual completion remains more reliable for complex or multi-step workflows.
Not reliably at current capability levels. Enterprise categories — form submission pipelines, SaaS workflow automation — lack independent benchmarks. The intent interpretation pipeline compounds uncertainty at every step.
Linear, predictable, low-stakes tasks: simple data lookups, routine form submissions with known field requirements, single-site navigation. Tasks requiring cross-application coordination or contextual judgement remain unsuitable.
Re-prompting is a systemic property of probabilistic intent interpretation, not a product defect. LLMs process the same instruction non-deterministically. When execution fails at an unexpected page state, the agent often can’t regenerate a working plan without human input.
No. HITL is the appropriate architecture for high-stakes task automation regardless of AI maturity. The question it answers is not “when will the agent not need human oversight?” but “which sub-tasks belong to the agent and which require a human?”
Confirmation checkpoints pause automation before purchases, social media posts, and account logins. The PlayStation Store test stretched a task to 15 minutes of pauses. That’s the safety-speed trade-off made concrete.
The hCaptcha Threat Analysis Group tested Atlas, Comet, and others on 20 abuse scenarios in October 2025. Agents attempted nearly every malicious request “with no jailbreaking required.” The benchmark shows the problem is not absent autonomous capability — it’s unreliable targeting of that capability.
Chrome uses confirmation checkpoints that improve safety at the cost of task completion rate. Atlas has cross-domain visibility across all open tabs — higher capability, wider attack surface. OpenAI advises against Atlas in regulated or compliance-sensitive environments. Neither has been benchmarked on enterprise task categories.
Atlas in Agent Mode accesses all open tabs and authenticated sessions. OpenAI advises against deploying it in contexts requiring heightened compliance and security controls. Enterprise deployment needs HITL controls, acceptable use policies, and a governance framework first.
HUMAN Security data shows agentic traffic reached nearly 4.5 million requests per month by August 2025, with 131% month-over-month growth in September. Adoption is accelerating, not stabilising.
Assess each workflow against the pipeline: How ambiguous is the intent? How predictable is the page structure? How much adaptation is required? Low complexity, low stakes tasks are candidates for autonomous operation; anything higher requires HITL.
Retrofitted browsers (Chrome) add agentic capabilities on top of existing architecture — massive distribution (60%+ market share, 3+ billion users) but constrained by the underlying browser model. AI-native browsers (Atlas, Comet, Neon) are purpose-built for autonomous operation but lack distribution. Current data doesn’t confirm tighter integration means better real-world reliability. For the broader context, see the agentic browser landscape overview.