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.
What Is Prompt Injection and Why Is It the SQL Injection of AI Browser Security?
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.
What Did the hCaptcha Benchmark Reveal When Researchers Tested Five Agents Against 20 Abuse Scenarios?
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.
How Does the OWASP LLM Top 10 Apply to Agentic Browser Risks?
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.
How Does Indirect Prompt Injection Make Enterprise Browser Agent Deployment Risky?
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.
Why Does Autonomous Action Compounding Risk Make Individual Exploits Enterprise-Threatening?
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.
What Do the Absent Safeguards Actually Mean — Atlas at Launch, Chrome’s Partial Mitigations, and What Is Missing?
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:
- Real-time SIEM integration — alerts on anomalous agent behaviour as it occurs
- Immutable audit logs — agent action records required for incident response
- Granular permission scoping per session — limiting agent access based on declared task context
- Injection detection mechanisms — content-layer analysis to flag potential injected instructions before execution
- Regulatory compliance mapping — documented coverage for GDPR Article 32, HIPAA, PCI-DSS
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.
Frequently Asked Questions
Can prompt injection attacks in agentic browsers be fully prevented?
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.
What is the difference between prompt injection and indirect prompt injection?
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.
Does Chrome Auto Browse have security safeguards?
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.
Is ChatGPT Atlas safe for internal business tools?
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.
Does using human-in-the-loop remove the security risk from browser agents?
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.
How bad were the hCaptcha benchmark results for agentic browsers?
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.
Is prompt injection risk limited to OpenAI Atlas or does it affect all AI browsers?
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.”
What is the OWASP LLM Top 10 and why should CTOs care about it?
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.
Can an AI browser make purchases or submit forms without user approval?
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.
How would I know if a prompt injection attack already occurred through a browser agent?
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.
What is Zenity’s agentic browser threat model?
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.
How worried should enterprise teams be about browser agents accessing internal tools?
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.
