Topic starter
11/06/2026 11:57 pm
TL;DR: Phishing-blocking performance was only 7% for Perplexity's Comet and Genspark across 100 tested phishing sites, compared with 47% for Chrome and 54% for Edge, according to LayerX Security, showing that AI browsers can inherit Chromium while still missing the web protections enterprises expect. Browser-mediated AI access creates a new control plane that reputation-based defenses were never designed to govern, and the gap becomes more dangerous when AI can act on authenticated sessions.
Editorial analysis by NHI Mgmt Group, based on content published by LayerX Security: “LayerX Finds that Perplexity’s Comet Browser is Up To 85% More Vulnerable to Phishing and Web Attacks Than Chrome”.
Key questions
Q: What breaks when AI browsers rely only on URL reputation for phishing defence?
A: Known-bad URL lists lag behind fast-moving phishing infrastructure, so newly registered or rapidly rotated pages can reach users before the blocklist updates.
Q: Why do AI browsers create more phishing risk than standard browsers?
A: AI browsers can process page content and take actions inside authenticated sessions, which means malicious instructions can influence both what the user sees and what the browser does.
Q: How can security teams tell whether an AI browser is actually protected against phishing?
A: They should test the browser against known malicious URLs, zero-day style domains, and insecure certificate scenarios, then confirm whether the browser blocks, warns, or silently passes each case.
Practitioner guidance
- Inventory AI browsers in sanctioned access paths Identify where Comet, Genspark, Edge Copilot, and similar browsers are used to reach enterprise applications, then classify those sessions as access pathways that need explicit governance.
- Test browser phishing controls directly Validate whether safe browsing, malicious URL blocking, and insecure connection warnings are actually enabled in each browser build, rather than assuming Chromium parity.
- Treat authenticated browser sessions as privileged Apply tighter policy to browsers that can act inside logged-in email, finance, and admin sessions, including stronger monitoring and stricter device trust assumptions.
Bottom line: AI browsers are creating a browser trust problem that now overlaps with identity and access governance, not just endpoint security.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
12/06/2026 8:53 am
Browser trust is becoming an identity control problem, not a desktop preference. When the browser can mediate authenticated access to business systems, phishing protection becomes part of access governance rather than endpoint hygiene. Enterprises that treat AI browsers as interchangeable with standard browsers miss the fact that the control boundary has moved. The practical conclusion is that browser selection now belongs in identity risk management.
A few things that frame the scale:
- The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.
A question worth separating out:
Q: Should enterprises treat AI browsers like ordinary browsers in access policy?
A: No. If a browser can mediate authenticated sessions and assist with page interactions, it belongs in the access path and should be governed accordingly. Enterprises should decide whether that browser is permitted for sensitive workflows, what protections must be active, and when alternative browsers are required for higher-risk use cases.
👉 Read our full editorial: AI browsers expose a new phishing control gap for enterprises
This post was modified 1 day ago by NHI Mgmt Group