Notifications
Clear all
Topic starter
20/08/2026 5:44 pm
TL;DR: Shadow AI is now a governance problem as much as a discovery problem: organisations are finding far more AI tools in use than security teams knew about, while browser-based prompts, OAuth grants, and MCP servers create data leakage paths that network logs miss, according to Strac. The boundary issue is no longer whether AI is adopted, but whether identity, access, and data controls can keep pace with unmanaged AI use.
NHIMG editorial — based on content published by Strac: What is Shadow AI? Definition, Risks & How to Detect It (2026 Guide)
By the numbers:
- By Q1 2026, large enterprises doing full Shadow AI discovery audits were typically finding 8–12× more AI tools in active use than their security team had on file.
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 organisations rely only on network logs to detect Shadow AI?
A: They miss the most important part of the event, which is the prompt content and the file or clipboard data being submitted.
Practitioner guidance
- Implement browser-level AI visibility Deploy controls that can observe prompts, pasted content, file uploads, and clipboard events in browser-based AI sessions, then route high-risk activity into alerting or redaction workflows.
- Review OAuth grants for AI-linked apps Inventory AI applications with delegated access to Google Workspace, Microsoft 365, Slack, and GitHub, then remove scopes that are broader than the use case requires.
- Classify MCP servers as governed workloads Track local MCP servers on developer endpoints, identify which resources they can reach, and block default access to home directories, secrets stores, and internal APIs.
What's in the full article
Strac's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step detection method comparisons for browser telemetry, OAuth grants, SaaS logs, and endpoint visibility.
- Practical examples of how prompt-level redaction is applied to PII, PHI, source code, and secrets.
- Detailed discussion of MCP server discovery, local process visibility, and endpoint-scoped controls.
- Real-world Shadow AI patterns observed in discovery scans across different business functions.
👉 Read Strac's guide to Shadow AI detection and control in 2026 →
Shadow AI and MCP servers: what IAM teams need to watch now?
Explore further
20/08/2026 6:27 pm
Shadow AI is now an identity governance problem, not just a data leakage problem. The article shows that the riskiest AI use often comes through authorised identities on unauthorised tools, or unauthorised identities on authorised tools. That combination breaks the normal assumptions behind inventory, approval, and audit. For IAM teams, the governance boundary now includes browser sessions, OAuth consents, and AI-linked delegated access, not just directory accounts.
A question worth separating out:
Q: What should teams do when MCP servers are running on developer laptops?
A: Treat them as governed integrations, not informal utilities. Identify the resources each server can reach, restrict filesystem and credential access by default, and require authentication or scoping before the server can connect to internal systems. If a local MCP server can read secrets or browse corporate data freely, it is already outside acceptable control.
👉 Read our full editorial: Shadow AI is creating a data governance gap IAM cannot ignore
