Shadow AI discovery fails when teams miss embedded LLM code paths

At a glance

What this is: Repello AI maps shadow AI as a five-layer discovery problem and argues that embedded LLM API calls in production code are the most overlooked exposure because network-only tools cannot see them.

Why it matters: IAM, NHI and AI security teams need layered discovery because sanctioned credentials, local agents and code-level integrations can create hidden access paths that policy alone will not surface.

Context

Shadow AI is not a single control problem, and it is not solved by tightening policy wording. The practical gap is discovery: AI use now spans browser sessions, endpoint-installed agents, code repositories, and SaaS features, so any team that looks in only one place will miss real exposure.

For identity and governance teams, the important distinction is between visible usage and governed usage. Shadow AI discovery matters here because sanctioned credentials, legitimate egress, and unmanaged agents can all sit outside the inventory even when the organisation thinks it has control.

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. The result is false confidence, incomplete inventories, and policy decisions based on a narrow slice of the environment rather than the real AI footprint.

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

A: Because the call can look like normal application traffic. If the API key is legitimate and the request exits through approved infrastructure, network tools may classify it as allowed activity, even when the prompt content, data sensitivity, and business purpose were never reviewed.

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. A practical approach is to inventory every assistant, model, and connected context source, then block anything that is unapproved, overly permissive, or likely to expose sensitive data. Approval decisions should be based on measurable control coverage, not developer convenience alone.

Q: What should organisations do first when shadow AI appears in the environment?

A: Organisations should treat the tool as an unmanaged identity, then decide whether it is allowed to handle business data at all. The first 24 to 72 hours should focus on discovery, containment, and policy enforcement at the access boundary. If the tool cannot be governed inline, it should be denied by default.

Technical breakdown

Why network telemetry misses embedded LLM API calls

Network telemetry is useful for identifying obvious traffic to AI provider domains, but it only sees what crosses the wire in a way the control can classify. Embedded LLM API calls in production code often use sanctioned credentials, normal egress paths, and approved infrastructure, which makes them look like ordinary application traffic. That means the security signal disappears unless the code itself is analysed. Static scanning is therefore not optional for shadow AI discovery, because the prompt content, data sensitivity, and business purpose are otherwise invisible.

Practical implication: Treat code-repository scanning as a required discovery layer, not a supplemental review.

How endpoint agents and MCP servers change the trust boundary

Workstation agents and developer tools expand the trust boundary beyond the browser. They can run as local binaries, hold persistent memory, connect to internal MCP servers, and invoke tools or data sources without the visibility that browser-DLP or session monitoring provides. The operational problem is that traditional endpoint controls inventory the device but do not understand the AI runtime on it. That creates a gap between installed software and governable AI behaviour, especially where agents can access files, APIs, and internal services at once. See the Agentic AI Security Policy Template.

Practical implication: Inventory AI runtimes and MCP endpoints explicitly so endpoint controls can classify them as governed workloads.

Why SaaS AI features need posture management, not assumption

Sanctioned SaaS with embedded AI features is often treated as low risk because the base application is already approved. That assumption breaks when AI features process corporate data under separate retention, training, or routing terms that were never reviewed by security or privacy teams. The governance question is not whether the SaaS is allowed, but whether its AI function has been enabled, who can enable it, and what data it can process. Without that review, the organisation has sanctioned software but unsanctioned AI behaviour. See the SaaS Security Guide.

Practical implication: Review tenant-level AI settings and data-handling terms for every sanctioned SaaS platform.

Threat narrative

Attacker objective: The attacker objective is to exploit ungoverned AI usage paths to move sensitive data or influence internal systems without triggering the controls that only watch approved channels.

1. Entry begins when employees use personal-account AI tools, install workstation agents, or ship embedded LLM calls inside production code outside formal review.
2. Credential and trust abuse follow when those tools use sanctioned API keys, legitimate egress, or internal MCP access that makes the activity look authorised.
3. Impact occurs when sensitive prompts, source code, customer data, or internal documents flow through governed systems without inventory, logging, or policy review.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is now an access-governance problem, not just an acceptable-use problem. The article shows that the highest-risk AI usage often hides inside sanctioned credentials, local runtimes, and production code paths. That means the control failure is not simply user behaviour, but the absence of a complete discovery model across browser, endpoint, code, and SaaS layers. Practitioners should treat AI inventory as an identity and access question, not only a tooling question.

Embedded LLM API calls create a governance blind spot that conventional discovery tools are structurally unlikely to close. When a developer ships an API call inside application code, the usage can inherit enterprise secrets, normal network egress, and the appearance of approved traffic. That makes the absence of code-level review a specific failure mode, not a process nuisance. Security teams should recognise this as a gap in application trust review and internal access governance, not just a missing detector.

Discovery without classification creates posture theatre. A long inventory of tools is operationally useless unless each item is tagged by data sensitivity, capability scope, and ownership. The article’s five-layer model is strongest where it forces organisations to decide what to sanction, permit, or block. That decision layer is where governance becomes durable, because visibility alone does not change risk. Practitioners should build a classification gate into the same workflow as discovery.

Policy bans do not reduce shadow AI unless the organisation offers a governed alternative and enforces it technically. The article’s emphasis on sanctioned replacements plus DNS and network enforcement is important because prohibition alone shifts usage off-record. That is a governance failure, not a compliance win. Teams should design controls that preserve visibility and create a managed path for legitimate use rather than driving activity into personal devices and unmanaged agents.

Service-account visibility remains the adjacent identity problem that shadow AI programs often underestimate. When AI tooling reaches into SaaS, APIs, and internal systems, the hidden dependency is often a non-human identity or delegated credential with broad scope. That is why shadow AI discovery should be paired with machine-identity governance, not run as a separate checklist. Practitioners should inventory who or what is actually authenticating on behalf of the AI workflow.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Organisations with high levels of shadow AI faced an average of $670,000 in additional breach costs compared with those with little or none, according to IBM's 2025 Cost of a Data Breach Report.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Five-layer AI visibility: discovery has to span network, browser, endpoint, code, and SaaS because each layer reveals a different part of the AI estate. If one of those layers is missing, the programme will systematically undercount exposure and overstate control. That is why the operational goal is not simply finding tools, but establishing a durable inventory that can be refreshed and acted on.

The forward-looking shift is toward governance at the point of use, especially where AI features sit inside sanctioned SaaS or inside application code. Organisations that rely on policy language alone will continue to miss sanctioned credentials, hidden MCP connections, and local runtimes, so the next phase is tighter linkage between discovery, enforcement, and runtime evidence.

For practitioners

• 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.
• Enforce block decisions at the DNS and network layers Apply host and endpoint controls for items marked unsanctioned, and keep permit decisions tied to logging and policy so exceptions remain visible.
• Review AI-enabled SaaS tenant settings Check whether AI features are enabled, what data they process, who can administer them, and whether retention and training terms match policy.

Key takeaways

• 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.
• The most dangerous blind spot is embedded LLM API use inside production code because sanctioned credentials and normal egress make it look authorised.
• Programmes need classification and enforcement after discovery, otherwise the inventory becomes a report instead of a control surface.

Related NHI Mgmt Group resources: Shadow AI and AI Agent Discovery Guide · SaaS Security Guide · SaaS Security Buyer's Guide · Agentic AI Security Policy Template

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Embedded LLM API Call: A large language model request made directly from application code rather than from a visible browser session or managed AI interface. These calls often inherit enterprise credentials and normal network egress, which makes them difficult to spot unless the codebase itself is scanned.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• AI Posture Management: AI Posture Management is the continuous practice of finding, assessing, and reducing security and governance risk across AI systems. It covers model configurations, agent access, data exposure, tool permissions, identity controls, logging, and policy compliance to prevent misuse, leakage, and unsafe autonomous actions across the AI lifecycle.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is designed for practitioners who need to connect identity controls to the broader security programme their organisation runs.