TL;DR: Shadow AI is expanding faster than many organisations can observe or govern, and Push Security argues that browser-level visibility is becoming the practical control point for discovering AI app use, browser extensions, and OAuth integrations across the workforce. The governance challenge is no longer whether employees use AI, but whether security teams can see, classify, and constrain that use before it becomes shadow SaaS, data loss, or identity sprawl.
NHIMG editorial — based on content published by Push Security: Shadow AI: how to discover, govern, and secure AI apps
By the numbers:
- Push telemetry shows the average organization has 16 AI apps, 17 AI browser extensions, and 17 AI OAuth integrations in use.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.
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-based AI extensions create identity risk for enterprise users?
A: They create identity risk because they can sit inside the authenticated session and see the same bearer tokens the user relies on.
Q: What do security teams get wrong about blocking AI tools outright?
A: They assume network blocking creates control, but users often shift to personal devices, browser workarounds, or OS-level agents that bypass those restrictions.
Practitioner guidance
- Implement browser-based AI discovery Use browser telemetry to identify AI apps, extensions, and SaaS sessions before they enter your approved application catalogue.
- Review AI-related OAuth grants Inventory delegated permissions for AI tools, including scope breadth, refresh token lifetime, and revocation status.
- Enforce browser-layer data controls Apply policy to uploads, prompts, copy actions, and downloads inside AI sessions so sensitive data is not handled only by downstream DLP controls.
What's in the full article
Push Security's full post covers the operational detail this post intentionally leaves for the source:
- How its browser visibility model identifies AI apps, extensions, and SaaS use across real sessions
- Examples of the telemetry signals used to separate sanctioned AI use from shadow use
- The control workflow for turning browser discovery into policy, investigation, and response
- The article's practical framing for teams evaluating browser security as an AI governance control
👉 Read Push Security's analysis of shadow AI discovery and browser control →
Shadow AI in the browser: what security teams need to control?
Explore further
Browser-level discovery is now part of identity governance. AI use no longer sits neatly inside application inventories, because employees bring it in through browsers, personal accounts, and delegated integrations. That means IAM and IGA teams need a discovery model that starts with sessions and OAuth grants, not only with approved apps. The practitioner conclusion is simple: if the browser is ungoverned, the AI estate is ungoverned too.
A question worth separating out:
Q: Who is accountable when sensitive data is retained in a third-party AI tool?
A: Accountability sits with the organisation that allowed the data into the tool, even if the provider stores or processes it. Teams need clear ownership for prompt retention, deletion requests, and vendor data processing terms. If the provider cannot prove erasure or lineage, the organisation still carries the compliance and privacy risk.
👉 Read our full editorial: Shadow AI adoption is outpacing browser control and governance