Browser Agent Security May Never Be "Solved." Now What?

In late 2025, one of the largest AI labs in the world said the quiet part out loud: prompt injection in browser agents is a security problem that "may never be fully solved." Not "we're working on it." Not "fixed in the next release." Possibly never. The statement came alongside a real security update, after internal red-teaming uncovered a new class of attacks on their own browser agent. And the UK's National Cyber Security Centre issued a parallel warning the same week. If you're building, buying, or evaluating agentic AI that touches the open web, this is the most important admission the industry has made so far.

Key Takeaways

• A major AI lab publicly stated that prompt injection in browser agents is "unlikely to ever be fully 'solved,'" comparing it to social engineering and phishing: managed, never eliminated.
• Independent benchmarks confirm the problem is structural. Even the best-performing models still fail under repeated or adaptive attacks. The differentiator is not whether injection succeeds, but what happens when it does: blast radius, credential isolation, action reversibility.
• Competitors kept shipping agentic browsers to broad availability throughout 2025 and 2026, with documented vulnerabilities surfacing months after launch and taking weeks or months to patch.
• Model-level hardening helps, but product-level containment (permission scoping, sandboxing, human confirmation gates) is the layer that actually reduces real-world risk. If you're evaluating agentic tools, ask about architecture, not just benchmark scores.
• If you're building on top of agents that browse the web, "assume breach" is not pessimism. It is the stated position of the vendors shipping the agents.

What Exactly Did the Lab Admit?

The admission was unusually direct. In a December 2025 blog post, the lab wrote that "prompt injection, much like scams and social engineering on the web, is unlikely to ever be fully 'solved.'" The post detailed how the company was hardening ChatGPT Atlas, its browser agent, against attacks. It also conceded that "agent mode" in ChatGPT Atlas "expands the security threat surface."

This was not a one-off. When ChatGPT Atlas launched in October 2025, the lab's own Chief Security Officer, Dane Stuckey, had already flagged the issue, calling it "an unsolved problem" despite existing safeguards. The December post followed internal automated red-teaming that uncovered a new class of prompt injection attacks, prompting the release of a newly adversarially trained model and enhanced security measures.

The same week, the UK's National Cyber Security Centre independently warned that prompt injection attacks against generative AI applications "may never be totally mitigated," putting websites at risk of data breaches.

Two institutions, one government and one commercial, both arriving at the same conclusion within days. That is not hedging. That is convergence.

Why Can't Prompt Injection Be Patched Out?

Prompt injection is structural, not incidental. The property that makes a browser agent useful (it reads web content and acts on instructions) is the same property that makes it vulnerable (it cannot reliably distinguish between the user's instructions and instructions embedded in the content it reads). A malicious page, a hidden string in a Google Doc, a styled-away paragraph on an otherwise normal website: any of these can alter the agent's behavior.

After ChatGPT Atlas launched, security researchers quickly published demos showing that a few words hidden in Google Docs could change the browser agent's behavior. Brave, the browser company, published research warning that all AI-powered browsers are vulnerable to indirect prompt injection. Not some. All.

The analogy both the lab and the NCSC reached for was phishing and social engineering. Nobody expects phishing to be "solved." Organizations manage it through layered defense, monitoring, training, and incident response. Not through a single patch. Prompt injection, the industry now admits, works the same way.

How Bad Is It in Practice?

Bad enough that the numbers are worth quoting carefully.

Independent testing showed that Anthropic's most powerful model at the time fell for targeted prompt attacks more than three times out of ten attempts. That is not a rounding error. That is a coin flip plus change.

By mid-2026, Anthropic's successor model achieved a zero percent attack success rate across 129 browser-agent test scenarios per its system card. Impressive, until you read the fine print: that zero percent figure only holds with "Auto Mode" turned on in their product. Without that specific safeguard active, the underlying vulnerability persists.

Third-party benchmarking from security firm Gray Swan tells a more granular story. As of late July 2026, the leading frontier model showed a 0.2% single-attempt attack success rate versus 3.1% for one competitor model and 14.2% for another. After fifteen repeated attempts, the success probability for the leading model stayed at 2.0%, while it climbed to 20% for one rival and past 60% for others. Better, yes. Solved, no.

An analysis from Vellum put it plainly: even leading attack-resistance scores are "not foolproof, since determined attackers can still succeed through repeated or adaptive attempts." Their conclusion was that safer models help, but real security requires designing agentic systems that assume prompt injection is inevitable and enforce safeguards at the application level.

Did Competitors Stop Shipping?

No. They shipped faster. By mid-2026, industry trackers noted that ChatGPT Atlas, Perplexity Comet, and Dia all reached broad availability during 2025 and early 2026. Comet went free to all users in October 2025. Atlas launched on macOS the same month.

Security researchers confirmed that prompt injection cannot be fully patched in any of them. The property that makes these browsers useful is what makes them structurally risky. They shipped anyway.

And real vulnerabilities kept surfacing. In August 2025, researchers at LayerX identified "CometJacking," an attack vector against Perplexity's Comet that could potentially exfiltrate personal data. Perplexity issued patches and added a visual confirmation layer requiring explicit approval before sensitive actions.

Separately, Zenity Labs researchers discovered in October 2025 that Comet left the user's local file system unprotected, with no restriction stopping the AI agent from reaching the file system. That flaw was not fixed until January 23, 2026. Roughly three months from disclosure to patch, for a vulnerability that gave an AI agent unrestricted file system access.

Why Does Disclosure-to-Patch Latency Matter More Than Zero-CVE Marketing?

Because the "unsolvable" admission means every vendor will have incidents. Every single one. The differentiator is not a clean vulnerability count. It is the speed and transparency of the response process.

Three months from disclosure to fix for a file-system access flaw is a concrete, measurable data point. If you are evaluating agentic tools for your organization, that number tells you more than any benchmark score. Ask prospective vendors: what is your median time from responsible disclosure to deployed patch? What is your process for notifying affected users? If they do not have answers, the benchmark scores are marketing.

Is This a Model Problem or an Architecture Problem?

It is an architecture problem. That is the most important technical point buried under all the coverage.

The industry conversation has largely focused on model-level hardening: adversarial training, instruction hierarchy, better system prompts. These help. The benchmark numbers prove they help. But a model that resists 99.8% of single-attempt injections still gets owned on attempt number 47. And an attacker with a script can run attempt number 47 before your user finishes reading the page.

The real differentiator is what happens after an injection succeeds. Blast radius. Credential isolation. Whether the agent can send an email, transfer money, or exfiltrate a file without a human confirmation gate. Whether those actions are reversible. Whether the session is sandboxed so a compromised page cannot reach the user's other tabs, cookies, or credentials.

The lab behind Atlas has started moving in this direction. Beyond model hardening, they have added a "logged out mode" that lets the agent act without account credentials, and a "Watch Mode" to help keep users aware and in control when the agent operates on sensitive sites. These are product-level containment measures. They matter more than the model's attack-resistance percentile.

Vendors racing to publish lower attack-success percentages are optimizing a real but insufficient layer. The question for builders is not "how often does injection succeed against this model?" It is "when injection succeeds, what can the attacker actually do?"

What Should You Actually Do If You're Building Agentic AI?

Assume breach. Not as a slogan. As a design constraint.

Every agentic system that touches the open web should be built with the assumption that prompt injection will succeed at some point. The architecture should limit what a successful injection can accomplish. Here is what that looks like in practice:

• Permission scoping. The agent should have the minimum credentials needed for the current task. Not your full session. Not your cookies for every logged-in site. The narrowest possible scope, granted per-task, revoked after.
• Sandboxing. A compromised page should not be able to reach the agent's context from a different tab, domain, or session. Isolation boundaries should be enforced at the product level, not left to the model's judgment.
• Human confirmation gates for irreversible actions. Sending an email, initiating a transfer, modifying a file: these should require explicit user approval, every time, regardless of how confident the model is. Convenience is not worth an unrecoverable action triggered by a hidden string on a webpage.
• Action reversibility. Where possible, design agent actions to be reversible by default. Draft instead of send. Stage instead of commit. Preview instead of execute.
• Monitoring and anomaly detection. Log what the agent does. Flag deviations from expected behavior. Treat the agent's actions the same way you would treat an employee's access to sensitive systems: auditable, bounded, monitored.

None of this is novel. It is the same layered defense approach that the security industry has used for decades against social engineering. The only new part is that the entity being socially engineered is a language model acting on your behalf.

What Does This Mean for Users Evaluating These Tools?

If a vendor tells you their browser agent is "secure," ask them what they mean. Specifically, ask:

• What happens when (not if) a prompt injection succeeds? What can the agent do without human approval?
• What is the blast radius of a compromised session?
• What is your median disclosure-to-patch latency?
• Can the agent access my file system, email, or banking sessions without per-action confirmation?

If the answer to any of these is vague, or if the vendor redirects to benchmark scores, you are looking at marketing, not a security posture.

Where We Stand (Honestly)

We build Selina. We run a stack of frontier models, routed per task. We deal with prompt injection as an operational reality, not a theoretical risk. It is a real attack surface, and we treat it as one.

We are honest about our own limits. Memory in Selina is protected and encrypted at rest, but memory is NOT end-to-end encrypted. A slice of each request reaches a frontier provider at inference. Files and transfers via SelinaSEND are end-to-end encrypted. Memory is not. We keep non-content operational metadata for a short retention window. We do not claim zero retention.

We scope permissions. We sandbox. We bound actions automatically. We monitor. And when we find something, we respond fast, because the admission from the largest labs in the industry applies to us too: this is managed, not eliminated.

The vendors making the loudest claims about solving prompt injection are the same ones whose own CSOs call it unsolved. The honest position is to build for a world where injection succeeds sometimes, and make sure "sometimes" does not mean "catastrophically."

That is the work. It does not end.

If you want to see how we approach it: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io