AI browser agents expose browser runtime gaps in enterprise IAM

At a glance

What this is: AI browser agents act with delegated user authority across authenticated sessions, and the key finding is that traditional enterprise security tools cannot reliably see or govern their runtime behavior.

Why it matters: IAM, NHI, and autonomous control teams need to treat browser agents as identity-bearing actors because delegated access, session inheritance, and hidden runtime actions break assumptions across all three programmes.

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.

👉 Read WitnessAI's analysis of AI browser agent security risks and controls

Context

AI browser agents are software entities that act inside a logged-in browser session, using the same access a human user already has. The governance gap is that they can execute actions across SaaS, email, source code, and internal tools while existing controls still assume the browser is being operated by a person.

That breaks the normal IAM model because delegated access is no longer just a session token or a single app grant. In practice, the agent becomes a cross-application identity broker with machine-speed decision-making, which means policy, visibility, and accountability all need to move into the browser runtime.

Key questions

Q: How should security teams govern AI browser agents that use existing user sessions?

A: Security teams should treat AI browser agents as delegated identity actors, not as normal browser users. That means applying session-level monitoring, action logging, input filtering, and explicit policy boundaries before the agent can move across SaaS applications. The key is to govern what the agent can do inside authenticated sessions, not just what the browser can load.

Q: Why do AI browser agents create more risk than standard browser automation?

A: AI browser agents create more risk because they decide what to do next at runtime, rather than following a fixed script. That makes their behaviour harder to predict, harder to review, and easier to steer with malicious content. They also inherit the user’s current access, which turns one compromised task into a multi-application exposure path.

Q: What breaks when indirect prompt injection targets an AI browser agent?

A: Indirect prompt injection breaks the boundary between content consumption and action execution. The agent can read hostile instructions embedded in an otherwise legitimate page or email and then act on them with real permissions. That is why traditional trust assumptions about documents, webpages, and user intent do not hold inside agent-driven sessions.

Q: Who is accountable for actions taken by a browser agent inside an authenticated session?

A: Accountability should remain with the human who initiated the task and the organisation that allowed the agent to act under delegated access. The programme must retain immutable evidence of prompts, actions, and outputs so reviewers can reconstruct what happened. Without that, the agent becomes operationally useful but forensically opaque.

Technical breakdown

How browser-agent execution loops create identity and access risk

AI browser agents work in a loop: observe the screen, interpret context, choose a tool action, and repeat. Each step is a fresh model inference, which means the agent can chain many decisions inside one authenticated session without a human review point between them. This is different from scripted automation because the action sequence is not fixed in advance. The identity implication is that the agent inherits the user’s current cookies, tokens, and session state, then uses them across multiple applications as if it were the user. That makes access scope harder to reason about than in normal service-account or API-key models.

Practical implication: treat browser-agent sessions as identity-bearing execution environments, not as ordinary user sessions.

Indirect prompt injection and hidden instruction delivery

Indirect prompt injection happens when malicious instructions are embedded in content the agent is supposed to read, such as a page, email, or document. The agent cannot reliably separate trusted instructions from untrusted text when both arrive as natural language. Attackers can also hide payloads with invisible Unicode, CSS tricks, or image-based instructions that humans do not notice but vision-language models still process. The result is not just a bad answer. The agent can be manipulated into taking real actions with real credentials, because the attack lands before the action is executed, not after data leaves the system.

Practical implication: inspect and constrain agent inputs before inference, especially content that can influence downstream action.

Why legacy DLP, CASB, and endpoint controls miss agent behavior

Most enterprise controls were built to watch network flows, endpoint activity, or SaaS boundaries, not autonomous decision-making inside the browser runtime. DLP may see egress but miss copy-paste and prompt-level leakage. CASB may monitor app boundaries but not cross-tab synthesis inside one session. Firewalls see ordinary HTTPS traffic and cannot tell whether the request is a normal user query or source code exfiltration. The same pattern applies to enterprise browsers: they can enforce browser security boundaries, but not govern an agent that sits above the page and uses the browser as a bridge between contexts.

Practical implication: place detection and policy enforcement at the session layer, not only at the network or endpoint layers.

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

AI browser agents turn delegated session access into a cross-application identity problem. The security issue is not simply that they can click faster than humans. It is that they inherit the authenticated user’s access and can move across email, code, SaaS, and internal tools without a separate identity boundary for each action. That collapses the old assumption that browser sessions are governed by a human operator sitting behind every decision. Practitioners should treat browser-agent governance as identity control, not as browser hardening alone.

Indirect prompt injection is the defining control failure because the attack lands before the action boundary. The agent consumes untrusted content as part of a legitimate task, then may execute attacker-shaped instructions with valid permissions. That means the failure mode is not credential theft first and action second. The failure mode is content-to-action conversion inside the trusted session. Organisations need to recognise that legacy trust models for document and page content do not survive when the reader can act autonomously.

Same-Origin Policy collapse is the named concept that captures why browser-native controls stop being sufficient. SOP was designed for page-level code isolation, not for an autonomous actor that can read one context, carry it into another, and act across domains. The browser still enforces origin boundaries, but the agent becomes the bridge that moves information between them. The implication is that origin-based security assumptions no longer describe the true trust boundary once the browser is controlled by an agent.

Runtime governance for browser agents now belongs in the same category as NHI control, not just AI policy. These agents hold delegated access, use existing sessions, and can create audit and compliance exposure without ever looking like a traditional API integration. That puts them alongside other non-human identities that need lifecycle, visibility, and action tracing. Practitioners should align browser-agent oversight with NHI governance, because the access pattern is machine-executed even when the session began with a human login.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI, according to the same survey, which is why browser-agent governance cannot be deferred to a later programme phase.
• For a broader framework lens, review OWASP Agentic AI Top 10 alongside NIST AI Risk Management Framework when defining browser-agent policy and oversight.

What this signals

Browser-agent governance is converging with NHI governance, because the same access chain now spans human login, delegated session, and autonomous action. With 70% of organisations already granting AI systems more access than human employees, per The 2026 Infrastructure Identity Survey, the programme risk is no longer experimental. Teams should expect browser-agent controls to sit alongside lifecycle, audit, and least-privilege design rather than inside a separate AI pilot lane.

The next governance pressure point is evidence quality. If agent actions are not tied to a human initiator, investigators will inherit activity without a defensible chain of accountability, which is a compliance problem as much as a security one.

A useful working concept here is session inheritance debt: the longer a browser agent can reuse an authenticated session, the more the organisation accumulates hidden access risk that traditional reviews cannot easily see. That debt grows fastest where identity governance still assumes humans, not agents, are the primary session operators.

For practitioners

• Establish session-layer controls for browser agents Monitor agent activity where decisions are made inside the browser runtime, not only at the endpoint or network edge, so policy can evaluate actions before they chain across apps.
• Classify agent-processed content as untrusted by default Apply pre-execution review for pages, emails, and documents that may contain instructions the agent could follow, and separate task content from control instructions wherever possible.
• Tokenize sensitive data before it reaches an agent Replace credentials, PII, and financial values with placeholders before prompts or inputs enter the agent workflow, then restore originals only on controlled return paths.
• Bind every autonomous action to a human initiator Require immutable logs for prompts, tool invocations, and key decision steps so investigations can attribute browser-agent activity to the person who started the task.

Key takeaways

• AI browser agents are identity actors, not just productivity tools, because they inherit user privileges and act across multiple SaaS environments.
• The main failure mode is content-driven action inside the browser runtime, where indirect prompt injection bypasses traditional perimeter and endpoint controls.
• Enterprises need session-level governance, immutable attribution, and runtime policy boundaries before browser agents can be deployed safely at scale.

Key terms

• AI Browser Agent: An AI browser agent is software that performs multi-step tasks inside a logged-in browser session by reading screen context and choosing actions at runtime. It differs from scripted automation because the sequence is not fixed in advance, which makes governance depend on delegated access, session visibility, and action attribution.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden in content an AI system is expected to read, such as a page, email, or document. The threat is dangerous because the agent may treat attacker content as legitimate task input and then execute it with valid permissions.
• Session Inheritance: Session inheritance is the transfer of a user’s active browser state, including cookies, tokens, and authenticated context, to an AI agent. In governance terms, it expands access beyond a single application and turns one login into a cross-application delegation boundary that must be controlled and audited.
• Same-Origin Policy Collapse: Same-Origin Policy collapse describes the point at which browser-origin boundaries stop providing meaningful protection because an autonomous agent can read from one context and act in another. The browser may still enforce technical boundaries, but the agent becomes the bridge that moves data and intent across them.

Deepen your knowledge

AI browser agent governance and delegated session risk are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for autonomous browser activity, it is worth exploring.

This post draws on content published by WitnessAI: AI browser agents, security risks, and a practical enterprise architecture. Read the original.