Notifications
Clear all
Topic starter
18/08/2026 3:01 pm
TL;DR: Shadow AI now operates through browser tabs, embedded platform features, personal logins, and code-level API calls, leaving security teams blind to most usage unless network, identity, and repository signals are correlated, according to Xygeni. The governance gap is no longer discovery alone, but enforcing approved use at the point where AI tools are installed or called.
NHIMG editorial — based on content published by Xygeni: how to detect and eliminate shadow AI risk in practice
By the numbers:
- 80% of workers use AI tools their organization hasn’t approved, according to Unseen Security’s 2026 State of Shadow AI report.
- 86% of organizations say they lack visibility into how data actually flows to and from the AI tools already in use.
- Zscaler’s ThreatLabz team analyzed 536.5 billion AI and machine learning transactions across its cloud and recorded a 3,464.6% year-over-year increase in enterprise AI/ML traffic.
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 personal accounts and API keys make shadow AI harder to control?
A: Because they bypass the normal identity and procurement signals that most governance processes depend on.
Q: What breaks when AI assets are tracked separately from repositories and pipelines?
A: You lose the relationship context that explains real exposure.
Practitioner guidance
- Build a unified AI inventory Track models, datasets, agents, MCP servers, repositories, and developer tools in one inventory so relationship risk is visible, not inferred.
- Correlate identity and network signals Join OAuth grants, personal account sign-ins, proxy logs, and service-account activity so unapproved AI usage can be traced to a person or workload.
- Enforce policy at execution points Block unapproved AI packages during install and deny unauthorised model calls at the API layer rather than relying on policy documents alone.
What's in the full article
Xygeni's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step detection logic for identifying shadow AI across browser, identity, and repository signals
- The relationship-graph model used to connect models, agents, datasets, MCP servers, and coding tools
- Operational guidance for blocking unapproved installs and API calls at the point of execution
- How the AI inventory and guardrail workflow maps findings into one risk view
👉 Read Xygeni's analysis of how to detect and eliminate shadow AI →
Shadow AI risk and AppSec controls: what teams are missing?
Explore further
18/08/2026 3:40 pm
Shadow AI is now an identity governance problem, not just an AppSec hygiene issue. The article shows that personal logins, OAuth grants, API keys, and embedded AI features all create an identity surface that conventional software inventory tools do not see. That means the control problem spans IAM, secrets governance, and code security at once. Practitioners should treat unmanaged AI use as an identity and access failure mode, not a mere policy exception.
A question worth separating out:
Q: What should teams do if they discover shadow AI in the business?
A: Teams should first identify who owns the tool, what data it touches, and which identities it uses. Then they should either bring it under policy and lifecycle control or remove access to enterprise data until governance is in place. Discovery without containment simply confirms the scale of the gap.
👉 Read our full editorial: Shadow AI risk is outpacing AppSec visibility and governance
