Notifications
Clear all
Topic starter
09/07/2026 1:40 pm
TL;DR: Shadow AI detection is the practice of finding unsanctioned AI tools and integrations that route live enterprise data to external models, and Kong says traditional security stacks cannot see them. IBM’s 2025 breach research links shadow AI to 20% of breaches and about $670,000 in added breach cost, showing why traffic-layer governance now matters.
NHIMG editorial — based on content published by Kong: Shadow AI Detection: The Enterprise Governance Guide
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Enforce model allowlists and sensitive-data redaction inline Block calls to unapproved providers and redact regulated content before requests leave the organisation.
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.
👉 Read Kong's analysis of shadow AI detection and governance →
Shadow AI detection: what it means for AI governance teams?
Explore further
09/07/2026 1:43 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Shadow AI detection is becoming an AI governance control point
