Long before AI agents arrived, employees were already signing in to business systems their identity team could not see: supplier portals, regulatory and government websites, legacy web applications, and SaaS tools a department bought and never wired into SAML or OpenID Connect, often through shared accounts and browser-stored passwords. These are the enterprise’s unmanaged applications: systems the business depends on, where no one enforces identity policy and no one audits access. Traditional SSO, by design, reaches only the applications that support federation standards, which in most enterprises is a minority of the tools people actually use. Unixi, which built its universal SSO platform for this ungoverned layer, estimates that federation covers just 20 to 50 percent of enterprise applications.
AI agents do not create this problem. They amplify it. For years, the enterprise struggled to govern a single actor, the human user, operating inside this partially visible environment. Browser-based AI agents introduce a second actor that can perform work on behalf of that user in the very same ungoverned environment. They can open tickets, query CRMs, update records, run reports, and send emails through a human’s existing session, including in applications that identity governance never onboarded. Where the enterprise once failed to see what its people did in these apps, it now also fails to see what their agents do. Unixi’s Shadow AI research tracks this shift in the wild: unsanctioned AI tools working inside those same ungoverned applications.
It helps to separate two situations, because they raise different governance questions. When an application sits outside enterprise identity, the primary challenge is authentication coverage itself: the enterprise cannot see the application, the credential, or the session, and it may not see the autonomous agent acting inside them either. When an application is integrated with enterprise identity through SAML, OpenID Connect, or OAuth, that federation remains essential and does real work. But successful authentication answers one question: who logged in. It does not tell you which agent acted, who delegated what authority, who approved what task, or what the agent ultimately did. Those are governance questions that arise after authentication has already succeeded. The first challenge concerns authentication coverage; the second concerns delegated execution and accountability.
Abandoning SAML, OIDC, or OAuth solves neither challenge. Extending their reach solves both. The browser is the one place where both kinds of applications converge, because managed and unmanaged authentication and agent activity all pass through it. That makes the browser a uniquely positioned policy enforcement point: it can observe browser-based authentication and autonomous activity across the applications the identity provider governs and the applications it never sees, without replacing the identity provider or becoming a competing control plane. In that layer, an enterprise can bind authority to a task, restrict sensitive actions, attribute activity to a specific agent, and produce an audit trail that survives unmanaged SaaS and shadow AI. Unixi built its browser-level platform for this job: to elevate the existing IdP to every unmanaged application instead of competing with it.
Figure 1 explains the gap. A legacy IdP sees the human login and the managed SaaS assertion, but it often does not see the browser agent’s task intent, downstream UI actions, subagent delegation, or activity in apps that do not support enterprise SSO.
1. Agents Are Now Acting Inside Enterprise Apps
The first shift is behavioral. AI agents are moving from assistants that summarize information to actors that perform work. A browser agent can navigate a web application, fill a form, click a button, download a report, paste output into another system, or send a message from an authenticated workspace. In enterprise settings, that means agents increasingly sit between a human and the systems of record: CRM, ticketing, HRIS, support consoles, finance portals, marketing tools, analytics platforms, and document repositories.
This matters because many enterprise applications still expose their most important business functions through a browser UI. Even where APIs exist, knowledge workers often complete workflows through SaaS front ends. Browser agents inherit that surface. They do not need the target application to publish an agent API. They can operate by reading the page, interpreting UI state, and acting through the session that already exists.
The deeper issue is not whether these agents are useful. They are. The issue is that enterprise identity architecture historically treats the browser as the endpoint of authentication, not as an enforcement layer for delegated autonomy. Once a user authenticates, many controls assume a human drives every action that follows. Browser agents break that assumption. They create a new actor inside the authenticated session.
The strongest current identity guidance already points toward broader lifecycle visibility. NIST SP 800-63 emphasizes digital identity risk management, federation, authenticators, and lifecycle controls. OWASP’s agent security guidance stresses the same things: authorization boundaries, least privilege tool access, and monitoring for agent tool use (OWASP AI Agent Security Cheat Sheet). The missing enterprise step is to apply those principles not only at login, but at the moment an agent converts a human session into machine action.
2. Human SSO Does Not Fit Agent Behavior
Human SSO assumes a recognizable pattern: a user authenticates, a relying party receives an assertion or token, the application maps that user to a role, and the session proceeds. SAML and OpenID Connect solve real federation and authentication problems. OASIS SAML Technical Overview describes a framework for communicating security assertions, while OpenID Connect Core defines an identity layer on top of OAuth 2.0. These standards are necessary, but they do not fully answer the agent question.
The question is no longer only, “Who is the user?” The agentic question is, “What exactly was delegated, to which agent, for what purpose, against which application, under what constraints, and with what evidence?” A conventional login trail does not answer that. It may show that Alice authenticated to a CRM at 9:02 AM. It may not show that Alice’s browser agent exported a pipeline report, summarized accounts, updated five opportunity records, and sent follow-up emails through a connected sales engagement tool.
The mismatch becomes sharper with unmanaged SaaS. Business teams run tools that never connect to enterprise SSO. Some support only password login. Some came in on a department credit card. Some are trial products. Some are browser-only tools that never enter the identity team’s integration backlog. Yet browser agents can still operate inside them if the user has access. This means the identity provider may not even know the application exists, while the agent can still act inside it. Unixi’s research on shadow SaaS sprawl documents how routinely these tools accumulate outside the identity team’s view.
Agent behavior also breaks the time model of SSO. A human session is usually synchronous and interactive. Agents may run asynchronously, queue tasks, invoke subagents, retry operations, or continue acting after the initial human instruction. They may combine evidence from multiple tabs and tools. They may operate across several applications under a single human session. Traditional SSO does not provide a native vocabulary for this chain of delegation.
Figure 2 shows the core failure mode. If the agent receives the user’s whole browser context, the agent can perform many actions that were never specifically delegated.
3. The Biggest Risk: Broad Privilege Inheritance
The biggest risk is broad privilege inheritance. In many agent deployments, the agent does not receive a scoped mandate. It receives the user’s session, saved credentials, cookies, extension context, or locally available files. The agent can then act with whatever access the user already has. From the agent’s perspective, this is convenient. From a governance perspective, it is excessive authority.
This is not just an AI safety problem. It is a non-human identity problem. Modern cloud and SaaS environments already struggle with service accounts, automation accounts, API keys, tokens, and workload identities. Microsoft Entra workload identities describes workload identities as identities assigned to software workloads rather than humans. OWASP’s 2025 Non-Human Identities Top 10 calls out overprivileged identities, long-lived secrets, improper offboarding, and human use of non-human identities as recurring risks (OWASP NHI Top 10). Browser agents intensify those risks because they can convert human privilege into autonomous action without always creating a separate, governable workload identity.
Broad inheritance causes three governance failures.
First, it creates overprivileged workflows. A user may have access to a whole CRM, but the agent only needs authority to summarize three accounts. A user may be able to send email, but the agent only needs authority to draft a message. A user may be able to download reports, but the agent only needs a filtered metric. If the agent receives full session authority, every task becomes a potential privilege expansion.
Second, it weakens accountability. When an agent changes a record, the application may log the human user. The browser may show that the user was active. The identity provider may show a valid login. None of those facts explain whether the action was human, agentic, delegated, automated, retried by a subagent, or caused by a prompt injection hidden in application content.
Third, it produces weak audit trails in shadow SaaS. Managed applications may provide admin logs, API logs, and SSO events. Unmanaged applications often do not. If an agent acts in an unmanaged SaaS tool, the enterprise may have no central event showing that the app was used, what data was touched, or what policy should have applied. Unixi’s findings on shared accounts sharpen the point: when several humans already share one credential, adding autonomous agents to that credential makes attribution nearly impossible.
The practical rule: agents should not inherit the user. They should receive task-specific authority. That authority should be short-lived, revocable, attributed, and bounded to a specific objective.
4. What Agent-Aware Identity Requires
Agent-aware identity begins with a distinct actor model. A user remains a human principal. The agent becomes a separate actor. The delegation between them must be explicit. The audit trail should record the human, the agent, the delegated task, the application, the action, and the evidence used to justify the action.
OAuth already has a useful building block for this mental model. IETF RFC 8693 defines OAuth 2.0 token exchange, including patterns for representing delegation and “on behalf of” relationships. Enterprises do not need to copy that standard word for word into every browser workflow, but they should borrow the principle: do not collapse the human and the agent into one indistinguishable session. Represent delegation as a first-class event.
Figure 3 shows the target identity pattern. The human authenticates, grants a bounded task, the agent receives its own identity and policy, and any downstream action uses a short-lived, app-bound authority.
Agent-aware identity comes down to six controls.
First, unique agent identities. Each enterprise agent should be identifiable as an actor, not merely as the human who launched it. The identity does not have to be a permanent service account for every task, but the system must be able to distinguish human action from agent action.
Second, scoped and short-lived authority. The agent should receive the least authority needed for the task: read only, draft only, update a particular record, export a specific report, or send only after approval. The grant should expire on its own, and security teams should be able to revoke it without touching the user’s main session.
Third, on-behalf-of attribution. Logs should show that the agent acted on behalf of a human or business owner. This avoids the two bad extremes: treating the action as purely human, or treating the agent as an unaccountable automation.
Fourth, task-level permissions. Role-based access control is not enough because the same user may delegate safe and unsafe tasks in the same application. The governance layer needs to evaluate the actual instruction and intended operation: summarize, draft, approve, export, update, delete, invite, purchase, or send.
Fifth, approval gates for sensitive actions. Exports, external sharing, mass updates, privilege changes, financial actions, deletion, and irreversible workflow triggers should require explicit confirmation or a separate approval path. The gate should attach to the action, not merely to the application login.
Sixth, revocation at the agent and workflow level. If an agent is compromised, overbroad, obsolete, or created by an employee who has changed roles, security teams need a way to disable that agent or task without disabling the human’s entire account. This mirrors the residual-access problem Unixi tackles through automated lifecycle management for human accounts: authority that outlives its purpose is a liability whether the actor is a former employee or an obsolete agent.
5. The Browser Becomes a Governance Enforcement Point
The browser is where managed identity and shadow AI collide. It is also the only practical control point for many unmanaged applications. A browser-level governance layer can observe the application surface, classify user and agent actions, enforce policy before high-risk clicks or form submissions, and record evidence that the IdP and SaaS application may never see.
This does not mean the browser replaces the identity provider. It means the browser becomes an enforcement extension of identity governance. Chrome Enterprise and other enterprise browser management models already recognize the browser as a managed enterprise surface for policy, extension control, and browser security posture (Chrome Enterprise Browser Cloud Management). Agentic work makes that surface more important because the browser is where delegation becomes action. Unixi demonstrates this model in production today: its patented browser extension delivers passwordless, IdP-anchored authentication and policy control for non-SAML applications with no application-side integration, extending the identity provider to apps federation could never reach.
Figure 4 illustrates the governance architecture. The browser-level layer observes agent interactions, checks policy, requires approval for sensitive actions, and logs evidence across both managed SaaS and shadow SaaS.
Interaction-layer governance works even when the target application does not support SAML, SCIM, fine-grained APIs, or enterprise audit logs. It can still detect that an agent is about to export customer data, paste sensitive content into a third-party site, update a production ticket, or submit a privileged configuration change. It can still enforce scope: this agent was authorized to summarize, not send; to draft, not approve; to read this record, not export the full dataset.
Stop shadow AI where it acts: not at procurement, not at login, not in network logs, but at the point where an agent turns user intent into application action.
6. Closing Argument: SSO Must Evolve
SSO is not obsolete. It remains a foundation for enterprise identity. But the identity stack has to evolve beyond basic SAML and OIDC login events. Enterprises now have to govern humans, shadow apps, workload identities, service accounts, browser agents, and autonomous workflows as distinct actors with different risk profiles.
The future identity question is not whether a user logged in. It is whether the right actor had the right delegated authority for the right task at the right time, with the right evidence and revocation path. That answer cannot come from legacy IdP logs alone.
None of this means AI created a new category of identity risk. Unmanaged applications, partial authentication coverage, and weak accountability all existed long before autonomous agents. What AI changed is scale and speed: it introduced a second, autonomous actor into an authentication landscape that was already only partially governed, and it made the existing gap impossible to ignore. Browser-based agents make that gap visible because they act where identity is weakest, inside sessions, across unmanaged apps, and at the interaction layer. Enterprises that want to adopt AI agents safely do not need to replace their identity stack; they need to extend it to that layer, with browser-level visibility, scoped delegation, and interaction-layer governance across both managed and unmanaged applications, before autonomous activity turns partial coverage into machine-scale overreach. That continuity is the ground on which Unixi has built: not a replacement for enterprise identity, but the enforcement point that finally brings the unmanaged half of the application portfolio under its governance.
