Network-Level Shadow AI Detection Using Traffic Analysis and API Fingerprinting

Network-level shadow AI detection using traffic analysis and API fingerprinting is the easiest way to start finding AI tools that employees use without IT approval. It reveals connections to AI services, but it cannot account for local models, personal-device use, or unreviewed AI behavior inside approved software. Enterprise security teams need a layered detection program that joins network evidence with identity, endpoint, browser, and code inspection, then turns those findings into governed access.

Why shadow AI traffic doesn't look like a threat

Shadow AI hides in plain sight because employees do not need to leave an installation footprint to use it. A browser tab is enough. Other entry points include a browser extension, an API call buried in an existing script, or a feature toggle inside an approved platform. None of these needs a rogue server or an unfamiliar application, the usual signs of shadow IT.

The resulting traffic runs over standard HTTPS. To a firewall not looking specifically for AI, a generative AI request and a weather-widget request look nearly identical. The task is therefore to identify a category of normal-looking traffic. That makes passive discovery necessary but insufficient. Speakeasy provides one upstream control point through governed distribution of agents and MCP servers, controlling what can be deployed rather than relying only on traffic inspection afterward.

How do you detect unauthorized AI usage across an enterprise network

Start with DNS queries and outbound HTTPS connections, matching destinations against a maintained catalog of AI services. Known endpoints include api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, and api.together.ai. Enterprises with a firewall or SASE platform already have raw material for this analysis. CASB tools can classify AI traffic and correlate it with user identity, producing a baseline map of who is using which services.

Manual log review lets teams look at one connection at a time, while perimeter firewalls let them enforce rules for known destinations. On its own, neither approach shows whether a connection is part of an approved workflow or comes from an employee’s personal account. Work-hour traffic spikes can strengthen a domain hit as secondary evidence of possible unauthorized use. Keeping the domain catalog up to date matters more than treating every burst of traffic as suspicious. This is an immediately useful starting point for a partial inventory of enterprise AI.

The five surfaces where shadow AI actually lives — and what network monitoring misses

The exposure spans five surfaces, which are network, browser, endpoint, code, and SaaS. At the network surface, visibility ends when an employee moves to an unmanaged personal device on a mobile hotspot. At the browser surface, a personal ChatGPT or Claude account can reach the same legitimate domain as an approved account. A domain hit does not show who owns the account, and copy-paste leaves no file event. Extension audits can therefore show things that connection logs cannot.

The endpoint surface includes local inference through Ollama or LM Studio, using models such as Llama or Mistral without an external API request. Relevant clues include model files, GPU-intensive processes, and local inference servers. Persistent workstation agents add another problem because they combine endpoint access, external LLM connections, internal MCP servers, and installed skills. Standard EDR does not expose all the relevant agent behavior merely by seeing the process.

The code surface has embedded LLM calls that use valid credentials and the usual corporate egress. Their destination can be visible while their purpose remains undocumented. On the SaaS surface, the application is approved but its newly activated AI behavior is not. AI features inside Notion, Zoom, or Salesforce can therefore escape an application-level approval decision. Ungoverned MCP servers cut across these surfaces, creating agent-to-system connections that need their own discovery and access controls.

Why the code surface is the hardest blind spot to close

An embedded LLM call can look entirely legitimate because its API key came from a secret manager and its request followed an approved network path. A CASB may identify the AI destination without distinguishing that call from sanctioned use. A dependency in requirements.txt or package.json is a clue, but not an explanation. Static analysis must trace how the code constructs prompts and what data it includes.

The 2026 credential-leakage incident described in the brief shows why that distinction matters. A prompt-injection payload hidden in a GitHub issue title caused an AI workflow to execute malicious commands inside a CI/CD runner. Exfiltrated credentials were later used to publish a tampered npm package that silently installed malware on approximately 4,000 developer machines. The agent treated untrusted text as instructions and acted with the authority of secrets in its environment, without human review of the step.

The response belongs in the architecture, including the firewall rule set. Static analysis and secret scanning built into CI/CD show the code paths and the risks to credentials. OneCLI keeps agents apart from real secrets by using placeholder keys that are swapped at request time, while Render’s managed OIDC uses short-lived, auto-rotating tokens in place of stored API keys. These patterns address credential authority as well as discovery.

MCP servers as the fastest-emerging shadow AI surface

MCP servers extend the code problem into a growing network of agent-accessible tools. The MCP 2026 roadmap identifies audit trails, enterprise-managed authentication, and gateway and proxy patterns as gaps still being addressed. Its March publication and material specification releases in June and July show how quickly the foundation is changing. Governance built around an early specification can become a maintenance project before its rollout is complete.

The June 2026 Enterprise-Managed Authorization extension, or EMA, places MCP provisioning under enterprise identity providers. Users authenticate through existing enterprise identity, and the IdP provisions access to authorized servers without separate per-server OAuth consent screens. That creates a central place for access decisions and an auditable trail.

The risks extend beyond unreviewed data access. CVE-2025-54135, CurXecute, covered prompt injection that caused agents to create MCP configuration files triggering remote code execution. CVE-2025-54136, MCPoison, involved attackers with repository write access replacing an approved MCP configuration with a malicious one to achieve persistent remote code execution. An approved server configuration is not a permanent certificate of good behavior.

How API fingerprinting sharpens what basic domain monitoring can't resolve

API fingerprinting adds specificity to destination monitoring by examining request structure, authentication headers, payload shape, and timing. Where those details are available for inspection, token patterns and request cadence can help distinguish managed integrations from personal-key use on the same domain. Streaming responses, token-count parameters, and system-prompt fields are more clues. They can also reveal AI calls behind shared domains or reverse proxies that make destination matching less useful.

A fingerprint may establish that an approved route is carrying a prompt, but it does not explain the full code path that assembled it or whether that workflow passed review. Signatures also need maintenance as providers change their interfaces. Local inference and personal-device activity remain outside the monitored path. The practical combination is domain monitoring for breadth and fingerprinting for depth on flagged traffic.

What a layered detection architecture looks like in practice

Teams should start with the infrastructure they already have and then invest in deeper inspection. Network and CASB monitoring establish the connection baseline, while SSO and SaaS log review add identity and application context. Starting with these layers uses systems enterprises already operate. Their findings should feed one inventory rather than remain in separate dashboards, where each tool can be correct while the overall picture is incomplete.

Endpoint monitoring is the next step for organizations that have managed devices. MDM and endpoint agents can find AI applications, model files such as.gguf and.safetensors, and GPU-intensive inference processes. DLP adds evidence of sensitive data that has been copied into browser tabs for an AI service. Browser extension audits then check for tools that can reach data without a network event that stands out. Static analysis and secret scanning are the last steps, checking for embedded AI behavior in production code.

This sequence allocates effort across required layers. Once high-volume traffic is classified, teams have more capacity for the deeper analysis that browser and code surfaces require. Deployment governance, including the governed access layer offered by Speakeasy, complements these discovery tools by recording which agents and MCP servers are authorized to operate. That supplies a reference against which observed activity can be judged. A connection is not rogue simply because it is new, and it is not sanctioned simply because its destination is familiar.

Turning detection findings into access control and governance

Every finding needs classification, a risk decision, and a disposition. Relevant criteria include data-exfiltration potential, compliance scope, and credential exposure. The decision should either sanction the tool with controls or route employees to a governed alternative. Discovery followed by a blanket block skips the very judgment the evidence was collected to support.

Enterprise assistants, internal LLM APIs with logging, and vetted MCP servers give employees an approved route before network and DNS deny lists close unsanctioned ones. Bans alone can push activity onto personal devices, where corporate monitoring loses sight of it.

Runtime control also requires an identity that can be held accountable. Okta at Oktane 2026 treated AI agents as first-class identities with owners, permissions, lifecycles, and audit trails. Short-lived, task-scoped credentials avoid relying on hardcoded keys or over-scoped service accounts. Beyond coarse RBAC, relationship-based or attribute-based permissions can express narrower boundaries, such as allowing an agent to summarize project documents without exporting them to external APIs.

Tools that support each detection layer, and where Speakeasy fits the architecture

Speakeasy is an AI control-plane option for turning discovery into governed access. It sits between agents, MCP servers, and enterprise systems, enforcing identity and RBAC through providers including Okta and Entra ID and through SAML/OIDC. Its governed MCP distribution layer controls which servers can connect, while runtime checks address prompt injection, PII, and secrets. Cost and usage telemetry, interaction logs, and audit trails make activity on that governed path accountable. This complements passive monitoring rather than extending it magically to unmanaged devices or local inference.

Netskope and Microsoft Defender for Cloud Apps support the CASB network layer. They classify AI traffic against domain catalogs and correlate it with users to build the initial usage inventory. Their useful comparison criteria are classification coverage and identity context. Local models and the meaning of embedded code calls still require other evidence.

Cloudflare Zero Trust added its Shadow AI Report in August 2025 to show who AI traffic comes from, how much bandwidth it uses, and where it comes from. Its enterprise MCP reference architecture combines Cloudflare Access, AI Gateway, and MCP Server Portals. Gateway DLP supports discovery of unauthorized remote MCP usage on enterprise networks. This is a relevant network-and-MCP option for enterprises already using Cloudflare’s edge network.

Endpoint and MDM tools show what is on local devices that these network services cannot see. Their role includes finding applications such as Cursor, Ollama, and LM Studio, detecting model files, and flagging inference processes. Their coverage depends on managed devices. That boundary is a reason to combine layers.

Static analysis and secret-scanning tools built into CI/CD check the code layer. They identify AI SDK dependencies, trace prompt construction, and expose hardcoded keys. Unlike a connection log, repository analysis can connect an AI call to the application behavior that generates it. These tools belong in the stack even when network classification is working well.

Building a detection program that keeps pace with a moving target

Detection coverage decays unless maintenance is part of the program. Domain catalogs and API fingerprints need updates as services and interfaces change. MCP governance must also keep up with specification changes without relying on internal tooling that has to be rebuilt after each release. The architecture needs continuing discovery.

A sustainable cadence combines continuous network and SSO monitoring with quarterly or semi-annual endpoint and code audits. Recurring amnesty programs help reveal activity that technical controls cannot see. A maintained catalog of sanctioned alternatives reduces the incentive to seek ungoverned ones.

The measure of maturity is whether the gap between actual AI use and IT-visible AI use is shrinking. Perfect coverage on day one is not the standard, and stricter policy alone is not evidence of progress. AI governance belongs in the same category as API gateway infrastructure, a persistent control layer that governs access, records interactions, and enforces policy. Detection earns its value when that layer can act on what it finds.