AI browsers expose a new phishing control gap for enterprises

At a glance

What this is: LayerX research shows that AI browsers, especially Comet and Genspark, have materially weaker phishing protection than mainstream browsers.

Why it matters: That matters because browser-based AI now sits inside identity workflows, where one malicious page can capture credentials, trigger unauthorized actions, or expand access across human and machine accounts.

By the numbers:

• LayerX found that Comet and Genspark blocked only 7% of known phishing pages and failed to block 93% of active phishing sites.
• 47%.
• Microsoft Edge had the best overall built-in phishing protection, with a 54% accuracy rate.
• LayerX’s built-in AI protections achieve a 98% accuracy rate in detecting phishing attempts.

👉 Read LayerX Security's analysis of AI browser phishing exposure and control gaps

Context

AI browsers are not just a new interface layer. They are becoming a control point where browsing, summarisation, authentication, and action execution converge, which means phishing risk now intersects directly with identity governance rather than sitting outside it.

The problem is that reputation-based blocking and URL-list defences were built for human browsing patterns. When an AI browser can act inside authenticated sessions, the security question changes from whether a page looks suspicious to whether the browser can safely distinguish trusted content from instructions meant to hijack user action.

Key questions

Q: How should security teams govern AI browsers in enterprise environments?

A: Treat AI browsers as an access layer, not just a client application. Restrict their use in high-risk workflows, apply browser and session policies to authenticated services, and test whether the browser can be induced to act on attacker-controlled content. Governance should focus on what the browser can do inside active sessions, not only on whether it opens web pages safely.

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. Standard reputation lists help against known bad URLs, but they are weaker against zero-day phishing, rotating links, and content-based prompt injection.

Q: How do organisations measure whether browser phishing controls are working?

A: Measure how often the browser blocks known malicious pages, how it handles zero-day phishing links, and whether it can resist hidden instructions inside web content. A strong control should detect both URL reputation failures and content-driven attacks before credential exposure occurs.

Q: Who is accountable when an AI browser enables credential theft or unauthorized access?

A: Accountability sits across endpoint security, identity governance, and application owners because the browser now participates in the access path. Organisations should assign ownership for AI browser policy, session containment, and acceptable-use enforcement before users adopt them broadly.

Technical breakdown

Why AI browsers weaken phishing controls

AI browsers such as Comet and Genspark embed model-driven interaction inside the browser session, which changes how trust is established. Traditional browser defences rely heavily on URL reputation, Safe Browsing lists, and certificate errors to block known malicious sites. That works reasonably well for static web threats, but it is weaker against fast-rotating phishing infrastructure and content-based attacks where the page itself is the payload. If the browser does not actively inspect page semantics or separate user intent from model-processed content, malicious instructions can slip through as ordinary web text.

Practical implication: security teams should treat AI browsers as a distinct control surface, not a Chrome replacement with a nicer interface.

Indirect prompt injection turns web content into an identity risk

Indirect prompt injection happens when malicious instructions are hidden inside web content that an AI system is asked to process. The browser or assistant then treats attacker-controlled text as if it were part of the task, which can redirect the model to reveal secrets, open accounts, or take actions the user did not intend. This is especially dangerous in browsers because the agent often operates with the user’s authenticated context. The security failure is not only phishing in the classic sense. It is the collapse of the boundary between content consumption and action authorization.

Practical implication: organisations need inspection and policy controls that evaluate model-parsed content, not just URL reputation.

Why browser protection is now part of identity governance

When an AI browser can access email, banking, or enterprise systems on a user’s behalf, phishing protection becomes an access-governance issue. The browser is no longer a passive client. It becomes an execution layer that can mediate identity sessions across multiple services, which means weak browser security can amplify credential theft and delegated access abuse. In NHI terms, the browser is increasingly part of the trust chain around tokens, session state, and authenticated workflows. That widens blast radius when protections fail.

Practical implication: identity and security teams should include AI browser risk in privileged access, session protection, and acceptable-use decisions.

Threat narrative

Attacker objective: The attacker wants to turn browser-mediated AI trust into credential theft, account takeover, or unauthorized data access.

1. Entry occurs when a user opens a malicious or compromised page inside an AI browser that processes the page content as part of its workflow.
2. Escalation follows when hidden instructions or phishing content are interpreted by the browser in the user’s authenticated context, allowing credential capture or unauthorized action.
3. Impact is achieved when the attacker uses stolen credentials or coerced browser actions to access accounts, exfiltrate data, or extend the compromise into other services.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI browsers are becoming a new identity control point, not just a new user interface. Once a browser can search, summarise, and act inside authenticated sessions, it starts to mediate access decisions that used to sit in the human layer. That changes the governance question from browser hardening alone to session trust, delegated action, and identity containment. Practitioners should treat browser choice as part of identity architecture.

URL reputation is no longer a sufficient trust model for browser-based AI. The LayerX results show that list-based blocking can miss the very web threats most likely to be used against fast-moving phishing infrastructure. This is a browser-side version of the larger identity lesson that static controls struggle when the threat surface is dynamic. Security teams need controls that evaluate content, context, and session intent together.

Browser-mediated AI widens the blast radius of credential compromise. A successful phishing page is no longer just a stolen password event when the browser can operate with full user privileges across multiple authenticated services. That increases the downstream impact on email, SaaS, banking, and enterprise systems. IAM and PAM teams should fold AI browser exposure into their session-risk model.

Content-based attack paths create a web security problem that identity teams cannot ignore. The malicious page is not merely a website, it is an instruction delivery mechanism aimed at an identity-bearing execution environment. That makes the boundary between web security and identity security much thinner than many programmes assume. Identity blast radius: this is the practical concept that matters here, because one compromised browsing interaction can now cascade across multiple accounts and sessions.

Enterprises should expect AI browsers to force convergence between web filtering, session controls, and identity governance. The category is moving toward higher autonomy in the browser, which means policy, detection, and containment must be evaluated together. Organisations that continue to classify browsers as simple endpoints will miss the way AI browsers alter authentication, authorisation, and user action paths. The next control gap is organisational, not just technical.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs.
• That visibility gap should push readers toward 52 NHI Breaches Analysis, where recurring compromise patterns show how hidden access turns into operational exposure.

What this signals

Browser-mediated AI is now part of the identity perimeter. The practical lesson for programmes is that session risk, browser policy, and delegated access need to be assessed together. If an AI browser can operate inside authenticated services, then web filtering alone is not enough to preserve identity trust.

The control gap here is not limited to phishing detection. It extends to whether your governance model can distinguish human intent from model-driven action once the browser has been allowed into sensitive workflows. Teams should expect browser selection to enter access governance discussions alongside SSO, PAM, and endpoint policy.

With 1.5 out of 10 organisations highly confident in securing NHIs, per The State of Non-Human Identity Security, the broader lesson is that identity programmes already struggle with non-human trust boundaries. AI browsers add another boundary that must be governed as part of the same control system.

For practitioners

• Classify AI browsers as a separate access channel Add AI browsers to endpoint, browser, and identity policy baselines so they are reviewed as a distinct control surface with their own acceptable-use and session-risk rules.
• Block browser-assisted access to high-risk sessions until controls exist Restrict AI browser use for email, finance, HR, and admin portals until you can enforce session monitoring, content inspection, and step-up controls for sensitive workflows.
• Test phishing resilience against content-based attacks Run purple-team exercises with malformed pages, hidden instructions, and rotating phishing URLs to see whether the browser blocks the page or lets the model act on it.
• Review delegated access pathways in authenticated sessions Map which accounts, tokens, and browser sessions can be reached if a user is tricked inside an AI browser, then reduce scope where the browser can act without further verification.

Key takeaways

• AI browsers change the trust model by combining content processing with authenticated action, which makes phishing a direct identity problem.
• LayerX’s results show a large protection gap between mainstream browsers and newer AI browsers, especially where controls depend on known-bad URL lists.
• Security teams should govern AI browsers as a distinct access channel and test them against content-based attacks before allowing broad enterprise use.

Key terms

• AI Browser: An AI browser is a web browser that integrates a model into navigation, summarisation, or action workflows. It is not just a browser with chat added. Because it can interpret page content and sometimes act inside authenticated sessions, it expands the trust boundary around web access and identity.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system later processes. In a browser context, the page itself becomes the payload. The risk is that the model follows attacker text as if it were part of the user’s task, leading to unsafe actions or data exposure.
• Identity Blast Radius: Identity blast radius is the amount of damage that can follow from a single credential, session, or delegated access failure. In browser-mediated AI environments, it grows because one compromised interaction can reach multiple accounts, applications, or services without a fresh approval step.
• Safe Browsing Reputation Model: A safe browsing reputation model blocks sites based on known malicious URLs, certificate problems, or threat feeds. It is useful against known bad destinations but weaker against new, rotating, or content-based attacks. That limitation matters more when the browser can act automatically inside a trusted session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws 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. Read the original.