Notifications
Clear all
Topic starter
14/08/2026 6:33 pm
TL;DR: Blocking AI tools at the network edge often drives usage underground while leaving organisations blind to personal accounts, browser extensions, and OAuth-connected AI apps, according to Push Security and Okta data. The real control problem is no longer allow versus block, but whether the governed path is visible, instrumented, and easier than the workaround.
NHIMG editorial — based on content published by Push Security: Blocking AI tools doesn't stop employees from using AI
By the numbers:
- Push telemetry shows that the average organization has 16 AI apps, 17 AI browser extensions, and 17 AI OAuth integrations in active use during a typical week.
- 80% of employees who use unapproved AI tools do so because it's easier to use their own accounts, and 57% because the approval process is too slow.
Questions worth separating out
Q: How should security teams govern shadow AI without blocking productivity?
A: Use visibility-based controls instead of blanket bans.
Q: Why do personal accounts and OAuth grants make shadow AI a governance problem?
A: Because they turn a simple app choice into delegated access.
Q: What breaks when AI visibility is limited to SWGs, CASBs, or EDR?
A: Those tools usually miss browser-layer activity, which is where login method, prompt content, extension behaviour, and clipboard activity often occur.
Practitioner guidance
- Build browser-layer AI visibility Instrument the browser session so you can see AI logins, personal-account use, clipboard activity, and extension permissions rather than relying only on perimeter logs.
- Treat OAuth grants as governed access Inventory AI-to-SaaS OAuth connections, review the downstream systems they can reach, and revoke grants that create persistent access without a clear business need.
- Classify agentic browsers as managed actors Create a control path for emerging autonomous browsers, including discovery, approval, and offboarding, so they do not remain invisible runtime identities.
What's in the full article
Push Security's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step browser discovery workflows for identifying shadow AI apps, extensions, and OAuth connections.
- Configuration detail for Monitor, Acknowledge, and Block enforcement modes across different user groups.
- Data-flow guardrails for clipboard, file upload, file download, and AI chat monitoring.
- Operational examples for detecting agentic browsers and unapproved MCP connections.
👉 Read Push Security's guide to shadow AI visibility, guardrails, and control →
Shadow AI visibility gaps: what IAM and security teams are missing?
Explore further
14/08/2026 6:38 pm
Shadow AI governance is an identity problem before it is an AI policy problem. The article shows that the hardest part of shadow AI is not choosing which tools to allow, but understanding who accessed what, under which identity, and through which authentication path. That makes the boundary between AI usage and IAM governance much thinner than many programmes assume. Practitioners should treat browser-layer identity signals as governance evidence, not as ancillary telemetry.
A question worth separating out:
Q: Who should be accountable when departmental AI tools access sensitive systems?
A: Accountability should sit with the business owner, the platform owner, and the identity team together, because no single group can explain the full access chain alone. The owner must justify the access, security must constrain it, and IAM must be able to attest it. Without that shared model, governance becomes symbolic rather than operational.
👉 Read our full editorial: Shadow AI governance fails when visibility stops at the perimeter
14/08/2026 6:40 pm
Shadow AI governance is an identity problem before it is an AI policy problem. The article shows that the hardest part of shadow AI is not choosing which tools to allow, but understanding who accessed what, under which identity, and through which authentication path. That makes the boundary between AI usage and IAM governance much thinner than many programmes assume. Practitioners should treat browser-layer identity signals as governance evidence, not as ancillary telemetry.
A question worth separating out:
Q: Who should be accountable when departmental AI tools access sensitive systems?
A: Accountability should sit with the business owner, the platform owner, and the identity team together, because no single group can explain the full access chain alone. The owner must justify the access, security must constrain it, and IAM must be able to attest it. Without that shared model, governance becomes symbolic rather than operational.
👉 Read our full editorial: Shadow AI governance fails when visibility stops at the perimeter
