Notifications
Clear all
Topic starter
19/08/2026 3:40 pm
TL;DR: Browser telemetry shows the average organisation now has 16 AI apps, 17 AI browser extensions, and 17 AI OAuth integrations in use, according to Push Security, which argues that blocking AI does not stop adoption but instead hides it from security teams. The governance problem is not AI presence alone, but unmanaged browser-mediated access paths that outpace existing identity controls.
NHIMG editorial — based on content published by Push Security: Shadow AI: what Push data reveals about the scale of the problem
By the numbers:
- The average organisation has 16 AI apps, 17 AI browser extensions, and 17 AI OAuth integrations in use.
- The average organisation has 17 AI OAuth integrations in use.
- The average organisation has 17 AI browser extensions in use.
Questions worth separating out
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.
Q: Why do browser extensions create identity governance risk?
A: Extensions can broaden the browser trust boundary by accessing content, modifying pages, or interacting with data that identity teams assume is protected by the browser session.
Q: What breaks when OAuth consent is used for shadow AI without review?
A: The organisation loses control over delegated access.
Practitioner guidance
- Inventory browser-originated AI access paths Build a live inventory of AI apps, browser extensions, and OAuth integrations that originate in employee browsers, then map each item to the user, tenant, and scopes it can reach.
- Review OAuth scopes as delegated privilege Classify every AI-related OAuth grant by effective access, not by app name.
- Tie offboarding to consent revocation When a user leaves, changes role, or no longer needs a tool, revoke browser-based AI consent and extension access as part of the standard offboarding workflow.
What's in the full article
Push Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Telemetry-driven discovery workflow for AI apps, extensions, and OAuth integrations in the browser
- Practical examples of how Push maps browser activity to shadow AI exposure
- The article's broader third-party risk framing across SaaS, extensions, and identity controls
- Implementation-oriented guidance for teams assessing browser-based AI governance
👉 Read Push Security's analysis of shadow AI and browser-mediated third-party risk →
Shadow AI in the browser: what third-party risk teams are missing?
Explore further
19/08/2026 4:19 pm
Browser-level visibility is now a third-party risk control, not just a user-experience layer. AI adoption is increasingly occurring through the browser, which means the browser has become the practical enforcement point for SaaS and delegated access governance. Organisations that treat browser activity as a secondary telemetry source will miss the actual identity events that matter, including consent, extension installation, and shadow AI use. The implication is that third-party risk programmes must move upstream into the browser session.
A few things that frame the scale:
- The average organisation has 16 AI apps, 17 AI browser extensions, and 17 AI OAuth integrations in use, according to the 2026 Infrastructure Identity Survey.
- The average organisation already has 17 AI browser extensions in use, which means browser-level discovery is now a governance requirement, not an optional control.
A question worth separating out:
Q: Who should own offboarding for third-party AI integrations?
A: Identity, SaaS, and third-party risk teams should share ownership, with a clear revocation step tied to user lifecycle events. If an AI tool is connected to a corporate tenant through OAuth or an extension, offboarding must remove that link as deliberately as any other access grant.
👉 Read our full editorial: AI apps in the browser expose third-party risk gaps
