Agentic browsers expand the enterprise attack surface for IAM

At a glance

What this is: This is a Zenity analysis of how agentic browsers turn everyday browsing into an identity and access risk by combining user-like actions with deep enterprise reach.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to account for browser-driven actions that can access SaaS, local secrets, and internal systems without clear governance.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Zenity's analysis of agentic browser threat exposure

Context

Agentic browsers are browser-based AI tools that can interpret instructions, browse content, and take actions on a user's behalf. That changes the security model because the browser is no longer just a user interface; it becomes an execution layer with access to cloud sessions, local files, internal tools, and sensitive portals.

For IAM and identity governance teams, the problem is not only access volume but access ambiguity. When a browser agent can act like the user across SaaS, developer, and identity systems, standard controls built for human sessions, service accounts, or static privilege boundaries lose clarity about who or what is actually operating.

Key questions

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

A: Start by treating agentic browsers as a governed access path, not as ordinary endpoint software. Inventory where they run, what sessions they inherit, and which enterprise systems they can reach. Then apply policy controls to high-risk actions, especially identity, code, and data changes, so the browser cannot silently become a privileged automation layer.

Q: Why do agentic browsers create more risk than ordinary browser extensions?

A: They are not just reading pages; they are interpreting instructions and taking actions through authenticated sessions. That creates a larger blast radius because the browser can move from content consumption to system execution without a clear user-visible boundary. The risk increases when the agent can reach SaaS tools, local secrets, and identity systems.

Q: What breaks when indirect prompt injection reaches a browser agent?

A: The trust boundary breaks first. Security teams often assume web content is passive input, but an agentic browser may treat it as operational instruction. Once that happens, untrusted content can drive privileged actions inside enterprise systems, turning a normal page view into an access and data-governance issue.

Q: Who is accountable when an agentic browser changes data or permissions?

A: Accountability must sit with the organisation that allowed the browser agent to operate under enterprise trust. If the tool can act through human sessions, the control owner needs clear policy, logging, and approval rules before sensitive actions occur. Without that, incident response becomes forensic guesswork after the fact.

Technical breakdown

Why agentic browsers behave like privileged automation hubs

Agentic browsers collapse natural language, page interpretation, and execution into one runtime. They can read arbitrary web content, follow prompts embedded in pages, and use existing authenticated sessions to perform actions that look identical to user activity. That makes them different from ordinary browser extensions or scripted automation, because the agent is deciding in context what to do next. In practice, the browser sits at the intersection of identity, session state, and tool access, which is why compromise or misuse can spread across SaaS, code, and data systems quickly.

Practical implication: teams need to inventory browser-based agents as a distinct access path, not as ordinary endpoint software.

How indirect prompt injection turns web content into a control problem

Indirect prompt injection occurs when untrusted page content contains instructions that the agent treats as actionable. In an agentic browser, that means a webpage, document, or interactive element can influence tool use, data extraction, or downstream actions without a classic exploit chain. The security issue is less about code execution and more about instruction substitution inside a trusted runtime. Once the agent accepts the injected instruction, it can use existing permissions to access Jira, GitHub, Confluence, or identity portals in ways that bypass normal user intent.

Practical implication: web content and task context need policy enforcement before the agent can act on them.

Why lateral movement can happen through connected SaaS tools

Browser agents often sit inside a web of pre-authenticated services. If they can read local environment variables, tokens, or session data, they may gain deeper access than the original task required. From there, the agent can propagate actions across connected systems such as issue trackers, repositories, and admin consoles. This is not traditional malware-driven lateral movement. It is credential- and session-assisted movement that becomes dangerous because the browser already has enough trust to operate across multiple enterprise systems.

Practical implication: restrict what browser agents can read locally and what high-risk actions they can propagate across connected tools.

Threat narrative

Attacker objective: The attacker wants to turn a trusted browser-based agent into a hidden execution layer that can expose data, modify systems, or extend access across enterprise tools.

1. Entry occurs when an employee installs or uses an agentic browser that can read web content and act through existing enterprise sessions.
2. Escalation occurs when injected instructions or exposed local data cause the browser agent to use tokens, cloud sessions, or SaaS connections beyond the intended task.
3. Impact follows when those actions propagate across internal tools, identity systems, or developer environments before monitoring detects the abnormal sequence.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Agentic browsers are becoming a shadow AI problem with identity consequences. Zenity’s coverage shows that these tools are not just productivity add-ons. They can appear on managed and unmanaged devices, create unapproved access paths, and operate outside normal governance inventories. That means the control question is no longer only what the browser can do, but whether the enterprise knows it exists at all. Practitioners should treat browser-based agents as discoverable identities with operational reach.

Browser-mediated autonomy creates a governance gap that existing session controls were not built to absorb. Session management assumes a human operator remains visible behind the activity. Agentic browsers weaken that assumption because the user intent, the browser action, and the downstream system action can diverge in real time. The implication is not just more monitoring; it is a need to rethink where human accountability ends and machine-initiated execution begins.

Indirect prompt injection is a named concept teams should now track as a runtime trust boundary failure. The issue is not that the browser is hacked in the classic sense. The issue is that untrusted content can become instruction input for a privileged agent. That shifts security from perimeter filtering to runtime content governance, which is a different operating model for IAM, SOC, and endpoint teams.

Shadow AI inside browsers is especially dangerous because it mixes high trust with low visibility. Zenity notes that these agents often reach cloud sessions, internal tools, developer environments, and private portals. When that access is informal, the enterprise loses both inventory and accountability. The practitioner conclusion is simple: if the browser can act, it must be governed like an identity surface, not a convenience layer.

MITRE ATLAS and OWASP guidance are now relevant to browser-agent governance, not just model security. Zenity’s framing aligns with a broader shift in which AI risk is no longer confined to prompts or models. Security teams need to map browser behaviours to agentic threats such as tool misuse, identity abuse, and data disclosure. The practical takeaway is to align control design with runtime behaviour, not with software category labels.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• A separate finding from the same research shows that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader NHI governance lens, review Top 10 NHI Issues, which frames the control gaps that emerge when non-human access expands faster than governance.

What this signals

Agentic browsers should be treated as a new identity-adjacent execution surface, especially where unmanaged devices and shadow AI already complicate inventory. With 80% of organisations reporting AI agents acting beyond intended scope, per the AI Agents: The New Attack Surface report, the governance problem is no longer hypothetical.

Browser autonomy debt: this is the accumulated risk created when organisations allow browser-based agents to inherit user trust without defining the boundaries of acceptable action. That debt shows up later as incident ambiguity, weak attribution, and unclear approval paths when the agent behaves outside expectation.

The practical signal for programmes is to move browser-based agents into the same review rhythm as other sensitive non-human identities. If teams cannot say which browsers can act, what they can reach, and where they report, then the control surface is already too large for ad hoc governance.

For practitioners

• Inventory browser-based agents across the estate Identify agentic browsers on managed and unmanaged devices, then classify which ones can read local files, reach SaaS tools, or operate under user sessions. Put them into the same governance inventory you use for other high-risk non-human access paths.
• Restrict the actions agentic browsers can propagate Block or step up approval for high-risk actions such as permission changes, code edits, token exposure, and identity admin tasks when a browser agent is the actor. Use policy gates at the point of action, not only at install or login.
• Separate local read access from execution privilege Do not assume that a browser agent needs broad local visibility to complete a task. Limit access to environment variables, cached credentials, and private directories so the browser cannot turn local data into deeper enterprise access.
• Feed browser activity into incident and governance workflows Route browser-agent telemetry into SOC, IAM, and governance review processes so suspicious actions can be correlated with identity, device, and session context. Treat unexplained browser actions as access events, not just endpoint noise.

Key takeaways

• Agentic browsers combine user-like access with runtime decision-making, which makes them a distinct identity and access risk surface.
• The most dangerous failures are governance failures, especially when untrusted web content can steer privileged actions inside enterprise systems.
• Security teams should inventory, restrict, and monitor browser-based agents as if they were high-risk non-human identities with session power.

Key terms

• Agentic Browser: A browser-based AI tool that can interpret content and take actions on behalf of a user. In practice, it operates as an execution layer with inherited sessions and broad reach, which makes it closer to a governed identity surface than a normal browser extension.
• Indirect Prompt Injection: A technique where untrusted content contains instructions that an AI agent may follow as if they were legitimate task input. In browser contexts, it can turn web pages, documents, or fields into hidden control channels that influence privileged actions.
• Shadow AI: Unapproved or undiscovered AI tools and agents operating inside an environment. For identity teams, shadow AI matters because it hides both access and accountability, especially when the tool inherits user trust without formal review or lifecycle control.
• Runtime Trust Boundary: The point at which an AI system decides whether content, context, or instructions should be treated as safe to act on. For agentic browsers, this boundary is critical because policy has to control the action path in real time, not just the software install.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: Your Browser is Becoming an Agent. Zenity Keeps It From Becoming a Threat. Read the original.