Shadow AI telemetry shows AI sprawl is already in the browser

At a glance

What this is: This is Push Security’s Shadow AI analysis, and its key finding is that AI use is already widespread in the browser through apps, extensions, and OAuth connections.

Why it matters: It matters because IAM, SaaS security, and identity governance teams need visibility into AI app access paths before those integrations become unmanaged identity and data exposure points.

By the numbers:

• Push Security says the average organization has 16 AI apps in use.
• Push Security says the average organization has 17 AI browser extensions in use.
• Push Security says the average organization has 17 AI OAuth integrations in use.

👉 Read Push Security’s analysis of Shadow AI discovery and browser controls

Context

Shadow AI is what happens when employees adopt AI tools, extensions, or connected apps for work without a governed approval path. In browser-centric environments, those tools do not just create visibility gaps. They also create unmanaged identities, consent paths, and data flows that sit outside IAM, SaaS governance, and browser controls.

Push Security’s framing is practical: blocking AI use does not eliminate the behaviour, it only hides it. For identity teams, the real problem is not whether AI is present, but whether its access path is discoverable, governable, and revocable across the browser session, the SaaS tenant, and the delegated OAuth connection.

Key questions

Q: How should security teams govern Shadow AI in everyday browser use?

A: Security teams should govern Shadow AI by enforcing controls where users actually interact with AI tools, not only at the network edge. That means browser-level inspection, content classification, and policy enforcement for paste, upload, and prompt actions. If users can move sensitive data into an AI tool without a control decision, the governance model is incomplete.

Q: Why do AI browser extensions and OAuth integrations create governance risk?

A: They extend enterprise identity into tools that may be added outside normal procurement or review, often with broad delegated scopes. That can leave persistent access in place after the user forgets it, changes role, or leaves the organisation. The risk is less about the tool label and more about unmanaged authorisation lifecycle.

Q: What breaks when Shadow AI is handled only as a procurement issue?

A: Procurement-only controls miss the fact that employees can adopt new AI tools continuously in the browser, often before IT sees them. By the time a tool appears in a buying workflow, the identity and data exposure may already exist through OAuth consent, browser extensions, or linked SaaS accounts.

Q: What should IAM teams change when AI is added to the environment?

A: IAM teams should expand ownership, review, and offboarding processes so they apply to AI services and supporting non-human identities, not only human users. AI introduces assets that can be provisioned quickly, used broadly, and left behind without a clear leaver event. Lifecycle governance has to follow that pattern.

Technical breakdown

Shadow AI discovery in the browser

Browser telemetry can reveal AI tools that are otherwise invisible to SaaS inventories, because the browser is where users authenticate, consent, and interact with apps. Shadow AI commonly appears as a mix of web apps, extensions, and connected services, each with different identity footprints. That makes it harder to classify than a single sanctioned application. The technical challenge is not just discovery of domains or endpoints. It is joining browser activity, consent events, and identity data into one view of what is actually in use.

Practical implication: treat browser telemetry as an identity discovery source, not just an endpoint visibility layer.

AI OAuth integrations and delegated access

OAuth-linked AI apps are especially important because delegated access can outlive the user’s immediate session and can span mail, files, and other SaaS data. In practice, that means a user can approve access once and create a persistent identity relationship between an AI tool and the organisation’s tenant. If those consents are not inventoried and reviewed, the access path becomes an unmanaged NHI-style dependency even when the app itself is external.

Practical implication: inventory OAuth grants for AI tools the same way you inventory other high-risk delegated access.

In-browser guardrails for unsanctioned AI use

In-browser guardrails sit between discovery and enforcement. They can surface banners, block risky actions, or direct users toward approved paths without relying on network-only controls that miss the actual session context. The point is not to stop every AI interaction. The point is to shape where users authenticate, what they can connect, and which data paths remain visible to the security programme. That makes browser enforcement a governance control, not just a blocking mechanism.

Practical implication: align browser-level policy with SaaS and IAM governance so AI use is steered into approved identity flows.

NHI Mgmt Group analysis

Shadow AI is an identity governance problem before it is an AI problem. The moment a user authorises an AI app, extension, or connector, the organisation has created a new identity relationship that must be discovered, governed, and revoked like any other access path. That is why browser-centric discovery matters: it exposes the control plane where consent happens, not just where traffic flows. Practitioners should treat Shadow AI as an unmanaged access estate, not a tooling fad.

Browser telemetry now fills the gap left by traditional SaaS inventory. Classic discovery methods miss work performed inside the browser, where users authenticate to third-party AI tools and attach them to enterprise data sources. That creates a blind spot for IAM, IGA, and SaaS teams because the asset is not only the app, but the delegated permission. The result is identity sprawl with an AI label on top.

Browser enforcement is becoming part of identity governance. If users are going to adopt AI tools anyway, the programme has to influence the path they take to get there. That means steering them toward sanctioned access, constraining risky connections, and making unapproved behaviour visible at the point of use. For practitioners, the governance question is no longer whether AI is allowed, but whether the access path is controlled.

Shadow AI also changes the meaning of third-party risk. Many organisations still evaluate third-party apps at procurement time, but AI adoption now happens continuously and informally in the browser. That means the risk is dynamic: a user can create a new external dependency in minutes, often without IT review. The practitioner takeaway is that third-party governance must move from onboarding events to session-level visibility and review.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprise teams that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• For a lifecycle lens on this problem, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls.

What this signals

Shadow AI is converging with NHI governance. Once an AI app receives delegated access, the security programme is managing a non-human access relationship, even if the user initiated it from a browser tab. That means SaaS inventory, OAuth review, and NHI lifecycle processes need to converge rather than operate as separate workstreams. The practical signal is that browser-discovered AI use should feed the same governance queue as other external access.

The control gap will widen if teams treat Shadow AI as an awareness issue instead of an access issue. In practice, the organisation needs one view of sanctioned and unsanctioned AI touchpoints, plus a revocation path when consent, scope, or ownership changes. The next step is to align that view with the NHI Lifecycle Management Guide and the browser-based controls that expose session-level behaviour.

For practitioners

• Map AI usage from the browser outward Correlate browser telemetry, SaaS logs, and identity data to identify AI apps, extensions, and OAuth grants that are active in the workforce. Include unsanctioned tools, not just approved ones, so shadow adoption shows up in the same governance view as managed access.
• Review delegated AI access separately from app inventory Track OAuth consents for AI tools as governed access relationships, with owner, scope, and revocation status. Reassess permissions when users change roles, leave teams, or connect new data sources, because the risk sits in the grant as much as the app.
• Use in-browser guardrails to steer behaviour Apply banners, policy prompts, or blocks at the point of access for high-risk AI use cases such as unapproved data upload or unmanaged SaaS connections. This is most effective when paired with sanctioned alternatives that reduce the incentive to bypass controls.
• Extend recertification to Shadow AI connections Add AI apps, extensions, and delegated integrations to access review cycles so their permissions are evaluated alongside other external access. Focus on stale grants, excessive scopes, and orphaned connections that persist after the original business need has changed.

Key takeaways

• Shadow AI is already producing unmanaged identity relationships through browser apps, extensions, and OAuth grants.
• Browser telemetry gives IAM and SaaS teams the discovery layer they need, but governance still depends on scope review and revocation.
• Security programmes should steer AI use into approved paths rather than assume blocking alone will eliminate adoption.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Browser telemetry: Browser telemetry is the event data produced by enterprise browser activity, including logins, profile changes, downloads, session starts, and extension or site interactions. In identity governance, it becomes useful when those events are correlated with account state and privilege context rather than treated as generic activity logs.
• OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.

What's in the full article

Push Security's full blog post covers the operational detail this post intentionally leaves for the source:

• How Push data identifies AI apps, browser extensions, and OAuth integrations in active workforce use
• The browser-level controls used to surface banners, restrict access, and guide users toward approved AI paths
• The specific telemetry signals security teams can use to distinguish sanctioned adoption from Shadow AI
• The product and workflow details behind browser-based visibility for unmanaged AI usage

👉 The full Push Security post covers browser telemetry, AI app visibility, and control options for Shadow AI.

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.