Browser agent security risks expose shadow AI governance gaps

At a glance

What this is: Browser agents are software assistants that operate inside a user’s browser and can turn ordinary session access into shadow AI risk when controls are weak.

Why it matters: They matter because browser-based agents sit at the boundary of human IAM, NHI governance, and emerging autonomous access patterns, so teams need to understand how permissions, prompts, and approvals interact.

👉 Read Netwrix's blog on browser agent security risks and shadow AI

Context

Browser agents are software that can act inside a browser session on a user’s behalf, but the security model is not the same as ordinary browser automation. When those agents inherit the user’s permissions, they can reach internal systems, external SaaS, and sensitive data through the same authenticated session the human would use.

The governance problem is that existing IAM and browser trust models assume the person is the decision-maker at each step. Once an agent can follow prompts, interpret page content, and trigger actions inside that session, the security boundary shifts from human intent to runtime control, which is where shadow AI risk begins.

That creates an identity question as much as a browser question: who is actually acting, under what authority, and with what approval boundary. For security teams, the relevant issue is not whether the browser agent is convenient, but whether the access path is governed well enough to survive delegation.

Key questions

Q: How should security teams govern browser agents that act inside user sessions?

A: Treat browser agents as delegated access actors and assign each one an owner, purpose, and revocation process. Do not rely on the human login event alone, because the agent may browse, interpret, and act inside the session without separate approval. Governance should cover inventory, action logging, and restrictions on high-risk transactions.

Q: Why do browser agents increase shadow AI risk?

A: They increase shadow AI risk when they are deployed inside productivity tools or browser extensions without formal inventory or approval. Security teams then have an active actor operating under user permissions, but no governance record for who approved it, what it can do, or how it is disabled.

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

A: The boundary between content and instruction breaks. A malicious page, message, or form field can steer the agent into actions the user never intended, especially if the agent is allowed to fill forms, move data, or trigger transactions without separate confirmation.

Q: What controls should organisations put in place before approving browser agent use?

A: Require a named owner, a defined business case, least-privilege session scope, distinct logging for agent actions, and a clear kill switch. If the agent can make sensitive changes, add step-up approval and block it from operating on untrusted content by default.

Technical breakdown

How browser agents inherit user permissions

Browser agents usually operate inside an authenticated browser context, so they inherit the user’s active session, cookies, SSO state, and whatever application entitlements the user already has. That means the agent does not need separate credentials to become useful, which is exactly why it can also become risky. From an identity perspective, the control problem is delegated authority without a distinct identity boundary. The browser session becomes the access container, and the agent’s actions are constrained only by what that session can already do.

Practical implication: separate human approval from delegated browser execution and treat browser-session delegation as a governable identity path, not a convenience feature.

Prompt injection and browser agent misuse

Prompt injection in browser agents happens when malicious or misleading content steers the agent into taking actions the user did not intend. Because the agent can read page content and convert instructions into browser actions, a hostile prompt can become an execution signal. This is not the same as classic phishing alone. The attack chain includes content exposure, instruction hijacking, and action execution inside a trusted session. The browser agent becomes the translation layer between text and access, which makes content trust part of access control.

Practical implication: restrict what content browser agents can interpret and require explicit action confirmation for high-risk steps such as payments, data export, or privilege changes.

Shadow AI risk in browser-based delegation

Browser agents are a shadow AI problem when they are introduced without inventory, policy, or visibility. They may be embedded in productivity tools, extensions, or embedded assistants that security teams do not classify as identities. That creates a blind spot similar to unmanaged non-human identities: the organization has an active actor, but no governance record for it. The risk grows when the agent can persist across sessions, reuse logins, or chain actions across multiple web apps without a clear owner.

Practical implication: inventory browser agents as managed access actors and map each one to an accountable owner, approved use case, and revocation process.

Threat narrative

Attacker objective: The attacker’s objective is to turn a trusted browser session into an execution channel for unauthorized data access or harmful actions.

1. Entry occurs when a browser agent is granted access through an authenticated user session, extension, or embedded assistant that already has SSO-backed privileges.
2. Credential access or abuse happens when the agent reuses the user’s browser context, session cookies, and application tokens to act without a separate identity boundary.
3. Escalation occurs when prompt injection, malicious page content, or chained browsing tasks drive the agent into actions beyond the user’s intended scope.
4. Impact follows when the agent exposes data, alters records, or performs high-risk transactions inside a trusted session that security teams assumed was human-directed.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• 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

Browser agents create an access model that looks human on the surface but behaves like delegated machine execution underneath. That matters because the user’s session becomes the control plane, while the agent becomes the actor. Existing IAM processes often assume a person is the one interpreting context and deciding when to act. Practitioners should treat browser agents as delegated access actors, not as harmless UI helpers.

Shadow AI is the right governance frame for browser agents when teams deploy them without inventory or approval boundaries. The core issue is not visibility alone, but accountability for actions taken through a browser session that can span multiple applications. That makes ownership, revocation, and activity traceability part of identity governance, not just endpoint policy. Practitioners need a named owner and a defined business purpose for every browser agent in use.

Prompt injection turns content into an access-control problem. Browser agents do not just consume text, they can operationalise it. That means malicious page content can become a control-bypass mechanism if the agent is allowed to execute sensitive browser actions without separate confirmation. Practitioners should recognise this as a failure of trust segmentation between readable content and actionable instruction.

Delegated session authority: Browser agents expose a specific failure mode where a human’s authenticated session is assumed to remain under human timing and intent. That assumption weakens when a machine can browse, interpret, and act at runtime within the same session. The implication is that governance models built around direct human decision-making no longer describe what is actually executing.

Browser agent governance sits at the intersection of human IAM and NHI control patterns. The identity is not a user account, but it is also not a fully autonomous agent in most deployments. That makes classification discipline important: teams should not overstate autonomy, but they also should not ignore machine-driven action inside human-authenticated workflows. Practitioners need controls that reflect delegated runtime behaviour, not just the login event.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• 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.
• Browser agents should be evaluated with the same discipline applied to unmanaged non-human identities, especially where session reuse and delegated access create hidden control paths.

What this signals

Shadow AI should be expanded to include browser agents that inherit human sessions without separate governance. That is where delegated execution becomes hard to see and harder to revoke, especially when the agent can move across SaaS tools using the user’s existing access. The practical next step is to treat browser agents as inventoryable access actors and route them through the same owner, purpose, and revocation controls used for other non-human identities.

The control conversation should now shift from browser hardening alone to delegation design. If a browser agent can translate content into action, then confirmation boundaries, content trust boundaries, and session scope boundaries all need to be explicit. Teams that already have NHI governance in place will recognise the pattern: the actor is not a person, but the account and session still carry accountability, traceability, and blast-radius implications.

For practitioners

• Inventory every browser agent in use Create a register of browser extensions, embedded assistants, and workflow agents that can act inside authenticated sessions. Record the owner, business purpose, target applications, and revocation path for each one.
• Separate high-risk actions from ordinary browsing Require explicit confirmation before payments, data exports, privilege changes, or record updates. Keep those actions out of ambient browser automation so prompt injection cannot silently convert text into execution.
• Limit session scope and persistence Use short-lived browser sessions, tighter application entitlements, and step-up checks for sensitive transactions. The goal is to reduce how far a browser agent can move if it inherits the user’s access.
• Log agent-originated actions distinctly Tag browser agent actions separately from direct human actions so audit teams can distinguish delegated execution from user-driven activity. Without that separation, incident review will over-attribute actions to the person.

Key takeaways

• Browser agents blur the line between human access and machine execution, which creates a governance gap if teams treat them as simple productivity features.
• Prompt injection becomes an access problem when browser agents can convert page content into actions inside a trusted session.
• Security teams should inventory browser agents, constrain high-risk actions, and log delegated activity separately from human use.

Key terms

• Browser Agent: A browser agent is software that can interact with websites and web applications inside a live browser session. In identity terms, it acts through an existing authenticated context, which means its security posture depends on delegated access, session scope, and action boundaries rather than a separate login.
• Shadow AI: Shadow AI is an unmanaged or undiscovered AI actor operating inside an organisation without formal approval, inventory, or governance. In browser-agent contexts, it often appears as an embedded assistant or extension that can act using human permissions while remaining invisible to normal identity controls.
• Delegated Session Authority: Delegated session authority is the ability of a non-human actor to use a human-authenticated session to perform actions on that person’s behalf. The risk is that accountability and intent are assumed to remain human, while execution has already shifted to machine control.
• Prompt Injection: Prompt injection is the use of malicious or misleading content to influence an AI system’s behaviour. For browser agents, the problem is operational, because the content can be turned into browsing actions, form submissions, or transactions inside a trusted session.

Deepen your knowledge

Browser agent governance, session delegation, and shadow AI risk are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping browser-based delegation into an existing identity programme, the course gives you the governance vocabulary to do it consistently.

This post draws on content published by Netwrix: Browser Agents: What are their security risks? Read the original.