Shadow AI discovery: are your controls seeing the embedded code layer?

TL;DR: 40% to 70% of enterprise AI use is unsanctioned, unmonitored, or both, according to Repello AI, and that single-layer discovery misses much of the exposure because embedded LLM API calls in production code are invisible to network-only tools. The decisive control is multi-layer discovery followed by classification and runtime enforcement, not policy-only bans.

Editorial analysis by NHI Mgmt Group, based on content published by Repello AI: “Shadow AI Detection: The 2026 Enterprise Playbook”.

Key questions

Q: What breaks when shadow AI discovery only covers one layer?

A: A one-layer program misses entire categories of AI use because browser sessions, endpoint agents, code-level integrations, and SaaS features expose different signals.

Q: Why do sanctioned credentials make embedded LLM calls hard to detect?

A: Because the call can look like normal application traffic.

Q: How do security teams decide which AI coding tools and models should be approved or blocked?

A: Security teams should evaluate AI coding tools using policy, reputation, access scope, and compliance fit.

Practitioner guidance

• Build a five-layer discovery workflow Scan network, browser, endpoint, code, and SaaS layers together so each category of AI use is visible in the same inventory.
• Classify every discovered AI use case Tag each item by data sensitivity, capability scope, ownership, and prevalence before deciding whether it should be sanctioned, permitted, or blocked.
• Add code-repository scanning to your AI audit Search repositories for SDK imports, direct provider calls, embedded prompts, and vector database usage so production code is not the blind spot.

Bottom line: Shadow AI is a governance and discovery problem that spans browser sessions, endpoint agents, code repositories, and sanctioned SaaS, so no single control layer is enough.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →