Shadow AI detection is becoming an AI governance control point

At a glance

What this is: Kong argues that shadow AI detection must move to the traffic layer because unsanctioned AI tools and API integrations expose live enterprise data and bypass traditional visibility.

Why it matters: This matters to IAM, NHI, and AI governance teams because AI calls often rely on secrets, delegated access, and unsanctioned integrations that create uncontrolled identity and data pathways.

By the numbers:

• IBM's 2025 breach research says 20% of breaches now involve shadow AI, adding roughly $670,000 to the average breach cost.
• Kong research found that 54% of enterprises with AI governance frameworks rely on an AI gateway as their control plane.
• Kong says the AI Sanitizer covers 20+ categories of sensitive data across 12 languages.
• SailPoint found that 96% of enterprises say AI agents are a security risk.

👉 Read Kong's analysis of shadow AI detection and governance

Context

Shadow AI is any unsanctioned AI tool, model, or API integration that employees use without security approval. The governance problem is not only the software itself, but the live data flow to external models and the lack of visibility into who is calling what, with which credentials, and for what purpose. In practice, that makes shadow AI an identity and access problem as much as a data control problem.

For IAM and NHI practitioners, the intersection is direct: shadow AI often depends on API keys, service accounts, delegated tokens, and third-party model access that never passed normal lifecycle controls. The result is a hidden access path into sensitive data and production systems, which means discovery, policy enforcement, and auditability have to move closer to the request path. See also the Top 10 NHI Issues for the wider governance backdrop.

Key questions

Q: What breaks when shadow AI is not discovered at the traffic layer?

A: When shadow AI is not discovered at the traffic layer, organisations lose visibility into which models receive prompts, files, and code, and they cannot enforce policy before data leaves the environment. That creates blind spots in auditability, data protection, and accountability. The practical failure is that governance becomes reactive, with security teams trying to reconstruct exposure after the fact.

Q: Why do unsanctioned AI integrations create both IAM and data risk?

A: Unsanctioned AI integrations often depend on API keys, service accounts, or delegated tokens, so they expand the identity surface as well as the data surface. If those identities are not lifecycle-managed, they can persist long after the team that created them has moved on. That makes access governance and data governance inseparable in AI programmes.

Q: How do security teams know whether shadow AI governance is actually working?

A: Look for evidence that every model call is logged, every approved provider is explicitly allowlisted, and every sensitive-data control is enforced before transmission. If teams still need to ask which AI tools are in use, or if logs cannot tie a request to a user identity and model destination, governance is incomplete.

Q: Who is accountable when an unsanctioned model call exposes regulated data?

A: Accountability usually sits with both the business owner of the AI use case and the control owner responsible for policy enforcement. If data leaves through an unapproved integration, the absence of central guardrails, review, and lifecycle control becomes a governance failure, not only a user mistake. That is why exceptions must be traceable and time-bound.

Technical breakdown

Why shadow AI escapes traditional security visibility

Traditional security tools were built for static endpoints, known applications, and after-the-fact inspection. Shadow AI changes the control problem because the request itself carries prompts, documents, and code to an external model in real time. That means the sensitive event happens in the data plane, not in a file store or endpoint where most tooling still focuses. If the gateway or proxy layer does not see the request, governance becomes reconstructive instead of preventive. The core technical failure is not a missing alert alone, but a missing inspection point where identity, content, and destination can be evaluated together.

Practical implication: place policy enforcement where AI requests transit, not only where logs are reviewed.

How AI gateways change the control model for AI traffic

An AI gateway acts as an inline control plane between users, applications, and external AI providers. Because every AI API call passes through it, the gateway can inspect the request, apply model allowlists, enforce token limits, redact sensitive content, and keep an audit trail. This shifts control from scattered application logic to a consistent enforcement point. It also makes policy inheritance possible across teams, which matters in federated environments where local developers are otherwise tempted to route around central rules. For identity governance, the important point is that the gateway becomes the choke point for both secret use and data egress.

Practical implication: consolidate model access, request filtering, and logging into one inline control layer.

Why federated AI governance still needs central guardrails

Federated AI governance lets a central team define baseline policy while individual teams retain operating autonomy. That balance works only if inheritance is non-optional and the guardrails are enforced at runtime. Otherwise, every workspace becomes a separate exception process. In operational terms, the governance model has to define what data may leave the organisation, which models are approved, and how violations are surfaced to SIEM or SOC workflows. For identity teams, the lesson is familiar: decentralised adoption without central entitlement control produces access drift, only now the drift is happening in AI request pathways.

Practical implication: define central policy once, then enforce it consistently across every AI workspace and team.

Threat narrative

Attacker objective: The objective is to harvest enterprise data and amplify exposure through ungoverned AI calls, then reuse the resulting content or code in broader attacks.

1. Entry occurs when employees or developers connect unsanctioned AI tools or API integrations to enterprise workflows using approved-looking access paths.
2. Credential access or abuse follows when those integrations rely on API keys, delegated tokens, or service accounts that are not governed like production identities.
3. Impact occurs when prompts, files, or code leave the organisation in real time, creating data exposure, compliance risk, and downstream supply-chain flaws.

NHI Mgmt Group analysis

Shadow AI detection is now an identity governance problem, not just an AI monitoring problem. If an unsanctioned model call depends on a secret, token, or delegated identity, the failure is upstream of the model itself. Governance has to cover who can invoke AI, what identity is used, and whether that access is lifecycle-managed like any other privileged pathway. The practitioner conclusion is that AI traffic needs identity controls, not just content inspection.

Traffic-layer enforcement is the named control gap that shadow AI exploits. The article’s core lesson is that most enterprise stacks inspect data after it has already left the control boundary. That creates a detection gap for prompts, code, and regulated data that are sent directly to models. The practical conclusion is that organisations need an inline decision point before model invocation, not a retrospective review after the fact.

Federated governance only works when baseline policy is non-negotiable. Distributed AI adoption fails when teams can bypass central restrictions by choosing their own integration path or model endpoint. A federated model is therefore not a softer control model, it is a control distribution model with central invariants. The practitioner conclusion is to standardise policy inheritance and treat exceptions as risk events, not normal operating mode.

AI gateway adoption is becoming the architectural marker of mature AI governance. Kong’s data that 54% of governed enterprises already rely on an AI gateway suggests the market is converging on an enforcement layer rather than a dashboard. That does not eliminate the need for IAM, NHI, or data controls, but it does clarify where policy must be operationalised. The practitioner conclusion is to evaluate whether AI governance is embedded in the traffic path or still bolted on around it.

Shadow AI turns model usage into a supply-chain and compliance issue at the same time. The Cordyceps disclosure shows how AI-generated flaws can propagate across repositories, while live data routing introduces regulated-data exposure and audit problems. That combination is what makes shadow AI materially different from ordinary shadow IT. The practitioner conclusion is to manage AI adoption as both a code-risk and access-risk programme.

What this signals

Shadow AI governance will increasingly be measured by whether security teams can prove every AI call is tied to a governed identity, a defined model, and an approved data path. That is the operational test for whether AI adoption is expanding capability or simply expanding exposure. The organisations that treat AI traffic as a controlled identity pathway will be better positioned to absorb agentic AI without creating unmanaged access sprawl.

Detection-to-enforcement latency: the time between an unsanctioned AI request and a policy decision is becoming the key control metric. If that decision happens after prompts or code have already left the organisation, the programme is only observing risk, not reducing it. Teams should benchmark this against their IAM, SIEM, and gateway integrations, and use the NIST AI Risk Management Framework as the governance anchor.

The broader signal is that AI governance is converging with identity governance around inline controls, not separate review workflows. That means IAM and NHI teams should expect more demand for policy inheritance, auditability, and exception management across AI workspaces. The practical shift is from managing AI usage as a policy document to managing it as an enforced access path.

For practitioners

• Discover AI traffic paths before enforcing policy Run the AI gateway or equivalent control in observation mode to inventory approved and unapproved models, token sources, and data flows before blocking anything. Use the resulting baseline to identify which teams are sending prompts, code, or records to external services.
• Bind model access to governed identities Map every AI integration to the exact service account, API key, or delegated token it uses, then retire any identity that lacks ownership, expiry, or rotation. Treat model access the same way you would treat privileged non-human identity access.
• Enforce model allowlists and sensitive-data redaction inline Block calls to unapproved providers and redact regulated content before requests leave the organisation. Pair allowlists with prompt guards so policy violations are stopped at the request path rather than logged after exposure.
• Integrate gateway telemetry with SOC workflows Forward AI request logs, model names, user identity, token counts, and policy decisions into SIEM so security teams can investigate misuse quickly. Use the audit trail to support incident response, compliance evidence, and exception review.
• Treat federated exceptions as risk decisions Require central approval for any workspace that bypasses baseline AI policy, and time-box those exceptions. The goal is to prevent local autonomy from becoming permanent policy drift across the estate.

Key takeaways

• Shadow AI becomes a governance failure when models can receive live enterprise data outside the traffic layer.
• The evidence points to a real control gap: IBM ties shadow AI to 20% of breaches and roughly $670,000 in added breach cost.
• Practitioners should treat AI gateways, identity binding, and inline policy enforcement as core parts of AI governance.

Key terms

• Shadow AI: Shadow AI is the use of AI tools, models, or integrations inside an organisation without security approval or governance. It usually creates hidden data flows, unmanaged access paths, and accountability gaps because security teams cannot reliably see who is using which model, with what identity, and for what purpose.
• AI Gateway: An AI gateway is an inline control layer that sits between applications and external AI providers. It can inspect requests, enforce policy, redact sensitive data, limit usage, and log every call, making it the practical point where AI governance becomes operational rather than advisory.
• Federated AI Governance: Federated AI governance is a model where central policy is set once and inherited by distributed teams that still retain local operating autonomy. The control challenge is to preserve consistency across workspaces while preventing exceptions, model sprawl, and data routing outside approved boundaries.

What's in the full article

Kong's full blog covers the operational detail this post intentionally leaves for the source:

• How Kong's AI Gateway applies model allowlists, token limits, and prompt guards in inline request flow.
• The AI Sanitizer's handling of 20+ sensitive-data categories across 12 languages for prompt redaction.
• How federated workspaces inherit central policy across teams in multi-cloud and hybrid environments.
• The phased discovery, define, enforce, and optimise approach mapped to NIST AI RMF functions.

👉 Kong's full post covers the AI gateway control plane, federated governance model, and phased enforcement approach.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and agentic AI identity. It is designed for practitioners who need to connect identity controls to modern access pathways.