Shadow AI detection is the practice of finding and governing unsanctioned AI tools, models, and API integrations that employees deploy without security approval. It has become urgent because these tools route live enterprise data to external models in real time, and traditional security stacks cannot see them. The 2026 Cordyceps disclosure, which exposed identical AI-generated vulnerabilities across 300+ GitHub repositories, showed how fast ungoverned AI can turn into a supply-chain crisis.
Shadow AI is any AI tool, model, or API integration deployed inside an organization without IT or security approval. Unlike sanctioned systems, it operates outside every review process your governance program depends on. That makes detection the first and most important step in bringing it under control.
Shadow AI is not simply the next version of shadow IT. Shadow IT typically involves unsanctioned software that stays inside a known perimeter. **Shadow AI routes live data — prompts, customer records, source code — to external models**, and its behavior is non-deterministic, so the same input can produce different outputs and different data exposure each time.
The evidence for urgency is concrete. The Cordyceps disclosure found identical AI-generated flaws propagated through CI/CD pipelines across more than 300 GitHub repositories, exposing them to supply-chain attacks [2]. IBM's 2025 breach research reinforces the stakes: **20% of breaches now involve shadow AI, adding roughly $670,000 to the average breach cost, and 97% of AI-related breaches lacked proper access controls** [1].
Ungoverned AI expands the attack surface in ways security teams rarely have full visibility into. When any team can connect to an external model, the organization inherits risk it never assessed — and 96% of tech professionals say AI agents are a growing security risk [5]. The exposure spans data, compliance, and cost.
Closing this surface requires governance where AI traffic actually flows — not in a dashboard bolted on after the calls have already left the building.
Most enterprise security tools were built for a world of static endpoints and known applications. They inspect files, configurations, and logs — but they sit outside the live data plane where AI calls happen. That structural gap is why shadow AI slips past them.
Each category has a specific blind spot:
The common thread is that these tools react after the fact and never observe the AI request itself. Detecting shadow AI requires visibility at the traffic layer, where every AI call is made — and that is the job of an AI gateway.
An **AI gateway** is the control plane that sits between your users and applications and the external AI providers they call. Every AI API request passes through it, which means every request is visible, logged, and subject to policy before it ever reaches a model. [Kong AI Gateway](https://konghq.com/products/kong-ai-gateway)Kong AI Gateway is built to occupy exactly this position in the enterprise architecture.
Because it inspects traffic inline, Kong AI Gateway turns shadow AI from an invisible risk into a governed flow. Its core detection and control capabilities include:
This is the shift from reacting to AI risk to governing it. Kong research found that **54% of enterprises with AI governance frameworks rely on an AI gateway as their control plane**, reflecting how central the traffic layer has become to [enterprise AI governance frameworks](https://konghq.com/blog/learning-center/what-is-ai-governance)enterprise AI governance frameworks. For a deeper primer, Kong explains [what an AI gateway is](https://konghq.com/blog/enterprise/what-is-an-ai-gateway)what an AI gateway is and how it fits the broader stack.
**Federated AI governance is** a model where a central team sets baseline policies while individual teams retain autonomy to operate within them. In Kong, this works through workspaces: platform leadership defines organization-wide rules, and each team manages its own configuration underneath.
Policy inheritance makes the baseline non-negotiable. A rule such as "never route PHI to external models" is defined centrally and inherited by every workspace, so no team can opt out. This structure holds across multi-cloud and hybrid environments, giving large organizations one consistent governance posture instead of dozens of independent ones. It directly addresses the [agentic AI governance and shadow AI risk](https://konghq.com/blog/enterprise/agentic-ai-governance-managing-shadow-ai-risk)agentic AI governance and shadow AI risk that grows as AI adoption spreads across teams.
A shadow AI governance framework works best when it is rolled out in stages, moving from visibility to enforcement without stalling the teams already using AI. The following four phases align with the Govern, Map, Measure, and Manage functions of the NIST AI Risk Management Framework [3].
Because these controls run as plugins on the same gateway you already operate, each phase extends existing infrastructure rather than replacing it. Reviewing the [OWASP Top 10 LLM vulnerabilities](https://konghq.com/blog/engineering/owasp-top-10-ai-and-llm-guide)OWASP Top 10 LLM vulnerabilities during the Define phase helps prioritize which policies to enforce first.
Shadow AI is already inside your organization, routing live data to models you never approved. The organizations that stay in control are the ones governing AI where it actually flows — at the traffic layer, in real time. Kong AI Gateway gives enterprise security and platform teams that reference architecture: one control plane for detection, policy, and audit across every AI call. [Request a demo](https://konghq.com/contact-sales)Request a demo to see how Kong governs shadow AI at scale.
**What is shadow AI detection?**
Shadow AI detection is the practice of identifying unsanctioned AI tools, models, and API integrations deployed without security approval. It relies on visibility at the traffic layer, where AI calls are made, because these tools route live data to external models in ways traditional security stacks cannot see.
**How do enterprises detect shadow AI?**
Enterprises detect shadow AI by inspecting AI traffic at an AI gateway that sits between users and external providers. The gateway logs every call, flags unauthorized models, and enforces policy in real time. Kong research found that 54% of enterprises with governance frameworks use an AI gateway as this control plane.
**What is the difference between shadow AI and shadow IT?**
Shadow IT is unsanctioned software that usually stays within a known perimeter. Shadow AI routes live data — prompts, records, and code — to external models and behaves non-deterministically, so its data exposure and outputs vary from one call to the next. That makes shadow AI harder to detect and higher risk.
**What are the HIPAA risks of shadow AI in healthcare?**
Routing protected health information to an external LLM without a Business Associate Agreement is a potential HIPAA violation, regardless of whether a breach occurs. Ungoverned AI also fails HIPAA's audit-trail requirement, leaving organizations unable to prove how PHI was accessed or transmitted.
**What is federated AI governance?**
Federated AI governance is a model where a central team defines baseline policies while individual teams keep autonomy to operate within them. Central rules — such as never routing PHI to external models — are inherited by every team, ensuring one consistent posture across multi-cloud and hybrid environments.
**What is the Cordyceps AI vulnerability disclosure?**
The Cordyceps disclosure identified identical AI-generated vulnerabilities propagated through CI/CD pipelines across more than 300 GitHub repositories, exposing them to supply-chain attacks. It demonstrated how ungoverned AI-generated code can spread the same flaw at scale before anyone detects it.
AI data governance is the set of policies, processes, and controls that manage how data flows into, through, and out of AI systems. It covers who can access which models, what data reaches an LLM, how outputs are monitored, and whether every interac
Most teams start the same way. A developer creates an API key, calls OpenAI or Anthropic, and ships a prototype. The problems surface when that prototype becomes five production services calling three providers. Hardcoded provider dependencies are
Why Risk Management Will Separate Agentic AI Winners from Agentic AI Casualties Let's be honest about what's happening inside most enterprises right now. Development teams are under intense pressure to ship AI features. The mandate from leadership
Organizations are under immense pressure to develop and deploy AI agents quickly and at scale. However, since agentic AI systems rely on live data and complex integrations, they also introduce a massive new attack surface. Traditional security tool
You can see this visualized in the diagram below. As you move to the right, you get smaller and smaller circles — more services, deployed faster, in a more distributed manner to add resiliency and features. As you move to the right, your control and
The Stainless deal tells you where the easy wins are headed. Turning an OpenAPI spec into a TypeScript SDK, a Python client, and an MCP server is going to be a button. That's good. It lowers the activation energy for getting an agent to call your
For many buyers, this is where the evaluation begins: the part of the stack responsible for controlling, shaping, and observing AI traffic as it moves between applications and AI models. Once the baseline requirements are met, the question then shif