Browser-based AI agents expose the unmanaged app identity gap

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Unixi's blog post: Browser-based AI agents amplify identity gaps in unmanaged applications by executing tasks through human sessions that identity teams cannot fully see or govern.

Why it matters: IAM, NHI, and AI governance teams need to treat delegated browser activity as a distinct control problem because authentication alone does not provide task-level authority, attribution, or auditability.

By the numbers:

• Federation covers just 20 to 50 percent of enterprise applications, according to Unixi.

Context

Enterprise identity programmes often stop at the applications that support SAML or OpenID Connect, while large parts of the business still depend on supplier portals, legacy web apps, and SaaS tools that never entered the federation estate. Those unmanaged applications create a governance gap because identity policy is not enforced consistently and access is often left to shared accounts or browser-stored passwords.

Browser-based AI agents widen that gap by acting inside the same sessions that humans already use. The issue is not that AI creates a new identity problem from scratch. It is that the browser now carries both human authentication and delegated machine action into applications the identity team may never have onboarded, so task-level authority and accountability become the missing controls.

Key questions

Q: What breaks when AI agents run outside enterprise-controlled browsers?

A: What breaks is visibility, containment, and reliable accountability. The agent may still complete tasks, but it does so with persistent credentials, broader reach, and weaker evidence of what happened. In practice, that creates shadow AI conditions where security teams cannot verify scope or enforce session-level boundaries.

Q: Why do browser-based agents increase risk in unmanaged SaaS and legacy web apps?

A: They inherit the user’s existing access in places where identity teams often lack policy enforcement, central logs, or app onboarding. That combination increases the chance of overprivileged actions, weak attribution, and incomplete audit evidence when the agent performs work through a legitimate browser session.

Q: How can security teams tell whether delegated browser activity is actually governed?

A: Look for separate identity records, task-level approvals, short-lived delegated authority, and logs that show the human owner, the agent, and the exact action taken. If the only evidence is a successful login, governance is still incomplete.

Q: What should organisations do when browser-based agents need access to business applications?

A: They should bind authority to the task, not to the whole user session. That means narrowing permissions, revoking access independently of the human account, and adding approval gates for actions that change records, share data, or trigger irreversible workflows.

Technical breakdown

Why unmanaged applications defeat federation coverage

Unmanaged applications are business systems that are outside the enterprise identity stack, even when the business relies on them daily. Federation standards such as SAML and OIDC only help when the target application supports them, which leaves a long tail of portals, legacy tools, and department-owned SaaS outside central control. In those environments, authentication may still happen through passwords, stored browser credentials, or shared accounts, but the identity team has little or no policy enforcement at the application layer. That is why the core problem is not login success. It is that access exists beyond the reach of the governance model that assumes every important application is federated.

Practical implication: Map unmanaged applications explicitly before adding browser-based automation or delegation on top of them.

Why browser-based agents break the human-session model

Traditional identity architecture assumes a human is the active decision-maker after login. Browser-based AI agents change that assumption by operating inside the authenticated session, reading page state, taking actions, and continuing work without a separate enterprise application identity in many cases. That means the session can contain more than one actor and more than one intent. A valid login no longer proves that the subsequent action was human, delegated, or authorized for that specific task. The browser becomes the point where the human principal, the agent, and the application all intersect, which is why session evidence alone is no longer enough to explain activity.

Practical implication: Treat the browser session as a shared execution context, not as proof of who performed each action.

Why broad privilege inheritance creates identity blast radius

When an agent inherits the user’s full browser context, it can act with far more authority than the task requires. That can expose overprivileged workflows, weak attribution, and poor audit trails, especially in unmanaged SaaS where central logs may be thin or absent. The underlying issue is privilege blast radius: the agent gets whatever the user can do rather than a bounded set of task-specific permissions. In practice, that turns convenience into governance debt because a simple request to summarise, update, or export can become a much broader operational action across records, reports, and external systems.

Practical implication: Scope delegated browser actions to the narrowest possible task and revoke them independently of the user account.

Threat narrative

Attacker objective: The objective is to use delegated browser activity to perform unaudited actions inside enterprise applications without clear ownership, scope, or evidence.

1. Entry occurs when a browser-based AI agent operates inside a human’s authenticated session in an unmanaged application that the identity team cannot fully see or govern.
2. Credential and privilege exposure occur when the agent inherits saved passwords, cookies, or the user’s full browser context instead of a bounded task grant.
3. Impact follows when the agent performs work such as updating records, sending emails, or exporting data in ways that leave weak attribution and incomplete audit evidence.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-mediated delegation is now an identity governance problem, not just an application usability problem. The unmanaged application gap existed before AI agents, but browser-based execution turns it into a dual-actor problem because the same session can now carry both human intent and machine action. That changes the governance question from “did the user log in?” to “which actor was authorised to do which task?” Practitioners should treat browser-level delegation as a first-class identity control surface.

Federation coverage is not governance coverage. SAML, OIDC, and OAuth still matter, but they only answer who authenticated, not whether the resulting action was appropriately delegated, attributable, or revocable. The identity model breaks when teams assume a successful assertion is equivalent to controlled execution. The real gap is between authentication and accountable task execution, and unmanaged apps make that gap visible at scale.

Task-level authority is the right unit of control for browser-based agents. A user role can be appropriate while the delegated task is not, which means coarse RBAC alone cannot govern this layer. The enterprise needs to reason about summarize, draft, export, update, and send as separate authorisation events. Practitioners should redesign policy around the action, not just the account.

Identity blast radius is the named concept this pattern exposes. Browser agents often inherit whatever the human user can access, so one delegated task can expand into broad session-wide authority across multiple tools. That is structurally different from ordinary automation because the blast radius is hidden inside a legitimate user session. The implication is that governance must narrow the scope of delegated execution before it spreads across unmanaged applications.

Browser-level governance is becoming the enforcement point for shadow AI. The browser is where unmanaged apps, agent behaviour, and enterprise identity all meet, which makes it the only practical place to observe and control many of these actions. That does not replace the IdP; it extends identity governance to the layer where browser-based agents actually do the work. Practitioners should expect browser control to sit alongside identity governance, not beneath it.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• Read next: Zero Trust for AI Agents

What this signals

Identity blast radius: When browser-based agents inherit a human session, the practical unit of risk becomes the task they can execute, not the account they signed in through. That shifts governance from user-centric access reviews to action-centric controls that can constrain export, send, update, and share operations before they occur.

Federation coverage is only part of the story because unmanaged applications still sit outside the identity team’s line of sight. The programme implication is that teams need browser-level enforcement and evidence capture for the long tail of apps that never supported SAML or OIDC in the first place.

For practitioners

• Inventory unmanaged applications first Build a list of supplier portals, legacy web apps, and SaaS tools that never entered federation so browser-based agents are not added into invisible workflows.
• Separate human and agent actors Create distinct identity records and audit evidence for the human principal and the browser-based agent so delegated actions do not collapse into one indistinguishable session.
• Scope delegated authority to tasks Limit browser-based agents to read, draft, export, update, or send actions only when the specific task requires it, and make the grant short-lived and revocable.
• Add approval gates for sensitive actions Require explicit confirmation before exports, external sharing, mass updates, privilege changes, or irreversible workflow steps that a browser agent could trigger inside a live session.
• Preserve action-level audit trails Log the human owner, the agent, the delegated task, and the application action so investigators can tell whether an outcome was human, delegated, or autonomous.

Key takeaways

• Browser-based agents do not create the unmanaged app problem, but they make it harder to ignore by operating through the same sessions humans use.
• The key evidence gap is between successful authentication and accountable delegated execution, especially where applications are outside federation coverage.
• Practitioners need task-level authority, separate agent identity, and browser-level policy enforcement if they want auditability in unmanaged applications.

Key terms

• Unmanaged application: An unmanaged application is a business system used by the organisation but not integrated into the identity team’s standard controls, such as SAML, OpenID Connect, or central lifecycle management. These systems often hide credentials, sessions, and actions from normal IAM visibility, making them high-risk for delegated automation.
• Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.
• Browser-based access governance: Browser-based access governance is the practice of enforcing policy, logging, and data controls at the browser layer rather than treating the browser as a neutral access tool. It matters when users move between consumer browsers, extensions, and desktop apps, because control consistency determines whether the organisation can prove and limit access effectively.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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 building or maturing an IAM programme, it is worth exploring.