Vaikora › Blog › Detection & SOC

Detecting Shadow AI: Unauthorized LLM Usage in Enterprise

Detection & SOC · June 30, 2026 · 12 min read

Shadow AI refers to large language models and generative AI services deployed or used within an organization without explicit approval from security or IT leadership. Employees paste sensitive data into ChatGPT, Claude, Copilot, or lesser-known LLM APIs without authorization, often to accelerate work or bypass procurement. Shadow AI introduces data exfiltration risk, model poisoning, compliance violations, and supply-chain compromise. Detection requires visibility into egress traffic patterns, DNS queries, TLS handshakes, and endpoint behavior. The strategy begins with discovery, surfacing unauthorized AI API usage via network observability, and scales to enforcement, routing approved AI through a policy-enforcing gateway so unauthorized usage becomes visible and actionable.

Why Shadow AI Detection Matters Now

Generative AI adoption is outpacing security governance. A 2025 IDC survey of enterprise IT security leaders found that 70 percent of organizations lack formal policies governing employee use of public AI services. The gap creates risk across multiple domains: data leakage when employees paste customer information, contracts, or financial data into public models; compliance violations under HIPAA, GDPR, and PCI DSS when regulated data reaches unapproved systems; model poisoning and adversarial attacks when external parties ingest your training queries; and supply-chain dependency on AI vendors outside your control.

Shadow AI is not just a data-loss prevention problem. It is an enforcement gap. If employees can route requests to Claude, Copilot, or Llama.cpp instances on unmonitored infrastructure, then your AI governance policy exists on paper only. Detecting shadow AI usage gives security teams the visibility to close that gap.

How Shadow AI Traffic Leaves Your Network

Shadow AI usage creates distinctive network signatures. Understanding where these signals appear is the foundation of detection.

DNS Queries and Proxy Logs

When an employee opens ChatGPT in a browser or calls the OpenAI API programmatically, their device queries DNS for the target domain. Requests to api.openai.com, api.anthropic.com, api.cohere.ai, claude.ai, gemini.google.com, and hundreds of other LLM endpoints generate DNS lookups that proxies and DNS sinkholes capture.

Standard web proxies log all outbound HTTP(S) requests by domain. If your proxy has visibility, you can filter for known AI service domains and see which users or devices accessed them, when, and for how long. A single API call might generate only kilobytes of traffic, but repeated calls to LLM endpoints accumulate rapidly and stand out from normal business traffic.

TLS SNI and Certificate Inspection

The TLS Server Name Indication (SNI) extension is sent in cleartext during the SSL handshake. An observer with network-level visibility, your firewall, intrusion detection system, or network TAP, can log the SNI value without decrypting the connection. TLS SNI logs reveal the destination hostname for every HTTPS connection, including calls to LLM APIs.

This is particularly powerful because it works even when traffic is encrypted end-to-end and your proxy cannot see HTTP headers. A user calling the Anthropic API via a direct socket connection will still emit a TLS SNI record containing api.anthropic.com.

CASB and Cloud Access Security Brokers

Many organizations deploy Cloud Access Security Brokers (CASBs) to monitor and control traffic to software-as-a-service platforms. CASBs maintain real-time databases of cloud services and categorize them. Services like Zscaler, Netskope, and Cloudflare Gateway can categorize requests to AI services and flag them as "Generative AI" or "Unauthorized Cloud Services."

CASB logs show which users, devices, and applications accessed which cloud services, how much data was transferred, and sometimes the specific actions taken (e.g., file upload to cloud storage). This is one of the easiest ways to detect unauthorized AI usage if your CASB is already deployed.

Endpoint Process Telemetry

On devices with an endpoint detection and response (EDR) agent, you can monitor process behavior. Python scripts calling the OpenAI library will spawn python.exe or python3 with network connections to API endpoints. Browser extensions making API calls will show parent process chrome.exe or firefox.exe with child processes or socket connections to LLM domains.

Process telemetry is noisy but powerful in high-sensitivity investigations. You can detect not just web browser access to ChatGPT, but automated or programmatic calls to LLM APIs via custom scripts, which represent higher data-exfiltration risk.

Outbound Firewall Rules and Flow Logs

Cloud firewalls and network flow logs record every outbound connection: source IP, destination IP, destination port, and protocol. If an employee tunnels traffic through a VPN, proxy, or SSH tunnel, flow logs still capture the initial connection from their device to the tunnel endpoint. For direct connections to LLM APIs, flow logs directly record the destination IP and port.

Most LLM API providers run on well-known IP ranges and ports (typically port 443 for HTTPS). Blocking these IPs at the firewall is one approach to prevent shadow AI entirely, but this requires a maintained allowlist and can break legitimate business workflows if users unknowingly depend on the service.

Building a Shadow AI Detection Playbook

Detection starts with data collection and continues with alert logic, verification, and response.

Step 1, Inventory Known LLM API Endpoints

Create and maintain a list of LLM API domains, IP address ranges, and service identifiers. This list should include:

• Major public models: OpenAI (api.openai.com, platform.openai.com), Anthropic (api.anthropic.com), Google (generativelanguage.googleapis.com), Cohere, Mistral, xAI
• Enterprise and open-source alternatives: Azure OpenAI endpoints (if not approved), locally deployed models (if accessible from the network), managed services like HuggingFace, Replicate, or Together
• Known shadows: Smaller, less-monitored providers that employees might discover independently
• Regional and API-gateway variations: Endpoints in different regions, reverse proxies, and CDN distributions

Update this inventory quarterly as new services emerge.

Step 2, Deploy Network Visibility

Ensure your logging infrastructure captures:

1. DNS logs from your recursive resolvers or forwarders (passive DNS)
2. Proxy logs from your web gateway, including destination domain and bytes transferred
3. TLS SNI logs from your firewall or network sensor (no decryption needed)
4. CASB logs if deployed, with service category and user/device identifiers
5. Endpoint logs from your EDR agent, including process parent, network connections, and user context
6. Firewall flow logs if available in your cloud environment or on-premises security appliance

These sources overlap intentionally. Redundancy increases confidence in findings.

Step 3, Write Detection Logic

The following Microsoft Sentinel KQL query detects outbound connections to known LLM API endpoints using firewall flow logs and proxy data:

let LLMEndpoints = datatable(domain: string, provider: string)[
  "api.openai.com", "OpenAI",
  "api.anthropic.com", "Anthropic",
  "generativelanguage.googleapis.com", "Google",
  "api.cohere.ai", "Cohere",
  "api.mistralai.com", "Mistral",
  "api.together.ai", "Together",
  "api.replicate.com", "Replicate",
  "huggingface.co", "HuggingFace"
];
let BlockedUsers = datatable(user: string)[""];
(
  AZFWApplicationRule
  | where Action == "Allow" and DestinationDomain in (LLMEndpoints)
  | extend Provider = tostring(LLMEndpoints[DestinationDomain])
  | where SourceUserId !in (BlockedUsers)
)
| union (
  CommonSecurityLog
  | where DeviceVendor == "Palo Alto Networks" and Activity == "Accept"
  | where DestinationHostname has_any (LLMEndpoints)
  | extend Provider = tostring(LLMEndpoints[DestinationHostname])
)
| summarize
  ConnectionCount = count(),
  LastSeen = max(TimeGenerated),
  BytesSent = sum(SentBytes),
  DistinctDestinations = dcount(DestinationHostname)
  by SourceIP, SourceUserId, Provider, DestinationHostname
| where ConnectionCount >= 5 or BytesSent > 10_000_000
| order by BytesSent desc

This query flags connections to known LLM endpoints, aggregates by user and source, and surfaces patterns where a user or device made repeated calls or transferred large volumes of data. Adjust the thresholds (ConnectionCount >= 5, BytesSent > 10_000_000) based on your baseline and risk appetite.

Step 4, Correlate and Investigate

A single DNS query or one proxy request to an LLM domain may be benign (an employee checking if ChatGPT is accessible). Look for patterns:

• Repeated connections: The same user connecting multiple times per day
• Off-hours usage: Connections outside normal business hours, indicating intentional evasion
• Data exfiltration indicators: Large volume of data transferred in a short time
• Programmatic access: Process logs showing a script or custom application, not a web browser
• Sensitive role usage: Connections from accounts with access to customer data, financial systems, or regulated data

Correlate findings across data sources. If proxy logs, DNS logs, EDR logs, and firewall flow logs all point to the same user calling the same LLM API at the same timestamp, confidence in the finding increases.

Step 5, Validate Against Approved Usage

Before declaring a finding a security incident, check whether the user or department has approved AI usage. Some organizations issue approved ChatGPT or Claude accounts for specific teams. Requests originating from an approved account or device are lower priority than requests from personal devices or unapproved accounts.

Maintain an allowlist of approved AI usage: approved users, approved devices, approved AI services, and the business justification for each. Use this allowlist to filter out known good traffic and focus alerts on genuinely unauthorized usage.

From Detection to Enforcement

Detecting shadow AI usage is the discovery phase. Enforcement requires a policy layer that sits between the user and the LLM API.

The Approval-First Model

An AI security gateway, deployed as a proxy or API ingress, enforces policy before any request reaches an LLM API. The gateway can:

• Allow approved users and departments to use approved AI services
• Log all requests with full context, including prompt, user, role, and timestamp
• Constrain requests that violate policy: redact sensitive keywords, rate-limit by role, or reject requests from high-risk users
• Block requests to unapproved models or services entirely

When all legitimate AI usage flows through an approved gateway, unauthorized traffic to public LLM APIs stands out immediately in your proxy and firewall logs. Shadow usage becomes the exception, not the norm.

An AI security gateway implements exactly this pattern. The open-source vaikora-llm-gateway component accepts requests and applies policy logic. The gateway routes all approved AI requests through a single control plane that maintains policy decisions, audit logs, and threat detection. The control plane is a commercial product; the gateway itself is MIT-licensed open source. When legitimate AI usage flows through this policy-enforcing architecture, unauthorized direct calls to LLM APIs become immediately visible in your network logs and distinguishable from approved patterns. The moment you route approved AI through a policy-enforcing gateway, unauthorized usage becomes visible and enforced.

Building Enforcement Policies

Effective AI governance policies address:

1. Model whitelisting: Only approved LLM providers (e.g., OpenAI on company contract, internal Llama instance) are allowed. All others are blocked.
2. Data classification rules: Requests containing Personally Identifiable Information (PII), payment card data, or trade secrets are rejected or constrained (redacted, anonymized, rate-limited).
3. User and role based access: Only certain teams or roles can access AI services. Analysts can use Claude, but interns cannot.
4. Audit and logging: Every request is logged with full context for compliance and incident investigation.
5. Prompt and output inspection: Detect attempted prompt injection, jailbreaks, or exfiltration attempts via the gateway's threat-detection layer.

These policies ensure that AI governance is not a checklist on a wiki, but a runtime enforcement mechanism every request passes through.

Scaling Detection Across Your Organization

Shadow AI detection at scale requires mature logging infrastructure, well-defined detection logic, and defined response procedures.

Centralize Logging

Route all proxy logs, DNS logs, EDR logs, and firewall logs to a central SIEM or data lake (Splunk, Sentinel, Datadog, etc.). Use consistent field names (source_user, destination_domain, bytes_transferred) so detection queries can run across all sources simultaneously.

Automate Alerting

Write detection rules in your SIEM that run on a regular cadence (every hour, every 15 minutes) and trigger alerts for unauthorized LLM usage. Integrate alerts with your ticketing system (Jira, ServiceNow) so security analysts can respond immediately.

Establish Incident Response

When an alert fires, define a response workflow:

1. Immediate containment: If the user is transferring large volumes of data to an LLM API, block the connection at the firewall or revoke the user's API key.
2. Investigation: Pull browser history, process telemetry, and network logs to understand what data was sent.
3. Scope assessment: Determine if sensitive data was exfiltrated and whether other users have similar behavior.
4. Remediation: Educate the user on AI governance policy, potentially restrict their access, or escalate to HR if policy violation was deliberate.
5. Policy adjustment: If shadow AI usage is widespread, re-evaluate your AI governance policy. Maybe approved AI access is too restricted, or awareness is too low.

Communicate Policy

Shadow AI detection is only effective if users understand the policy and the consequences. Publish an AI usage policy that:

• Lists approved AI services and when they can be used
• Explains what data can and cannot be sent to AI APIs
• Describes the monitoring approach and the enforcement mechanism
• Provides a process to request new AI services or exceptions

When users understand that shadow AI usage is monitored and enforced, the behavior changes.

Compliance and Regulatory Context

Detecting and controlling shadow AI usage is increasingly a compliance requirement. HIPAA, GDPR, PCI DSS, SOC 2, and ISO 27001 all require organizations to document and control how sensitive data flows out of their environment. Uncontrolled AI API usage is a control failure under these frameworks.

The EU AI Act, which came into force in January 2026, requires "high-risk" AI systems to maintain audit trails and risk assessments. If an organization uses generative AI on customer data without explicit tracking and control, the organization may be in violation. Shadow AI, usage that is not tracked, is incompatible with this regulatory environment.

Similarly, NIST's AI Risk Management Framework (AI RMF) emphasizes transparency, accountability, and human oversight. Shadow AI violates all three. Detection and enforcement mechanisms are now part of foundational security posture.

Frequently asked questions

What is shadow AI and why is it a security risk?

Shadow AI refers to unapproved or unauthorized LLM usage within an enterprise network. It is a security risk because employees may send sensitive data, intellectual property, or regulated information to public AI APIs without authorization, resulting in data exfiltration, compliance violations, and supply-chain risk. Shadow AI also bypasses governance and audit controls, making it impossible for security teams to assess which data was shared with which models or vendors.

How do you detect shadow AI in an enterprise?

Detection requires visibility into outbound traffic via proxy logs, DNS queries, TLS SNI inspection, CASB logs, and endpoint telemetry. Look for connections to known LLM API domains (api.openai.com, api.anthropic.com, etc.), repeated access patterns, large data transfers, and programmatic or off-hours usage. Correlate findings across multiple data sources to increase confidence and reduce false positives.

What network traffic indicates AI API usage?

LLM API usage generates DNS queries to the provider's domain, outbound HTTPS connections to API endpoints, TLS SNI records containing the destination hostname, and HTTP POST requests with large payloads (prompts) and responses (model outputs). CASB systems categorize these connections as "Generative AI" or "Unauthorized Cloud Services." Flow logs show connections to well-known IP ranges associated with major LLM providers.

How do you find unauthorized LLM usage?

Cross-reference proxy logs and firewall flow logs against a maintained inventory of known LLM API domains and IP ranges. Write detection queries in your SIEM that flag connections to these endpoints, then correlate with your approved AI usage allowlist. Users and departments not on the allowlist represent unauthorized usage. Investigate high-volume or off-hours access patterns first.

What controls can stop shadow AI in an enterprise?

Deploy an AI security gateway that enforces policy before requests reach LLM APIs. The gateway allows approved users and models, blocks unapproved services, logs all activity, and detects prompt injection and data exfiltration attempts. Combine the gateway with proxy controls (URL filtering), firewall rules (IP/port blocking), browser policies (extension blocklists), and user education on AI governance.

How does an AI security gateway reduce shadow AI risk?

An AI gateway routes all AI requests through a policy engine that inspects every prompt and response, applies data classification rules (rejecting PII or payment card data), rate-limits or blocks unapproved models, and logs every request to an audit trail. When legitimate AI usage flows through the gateway, unauthorized direct calls to LLM APIs become the exception and immediately stand out in network traffic logs, making them detectable and enforceable.

What compliance frameworks require shadow AI controls?

HIPAA, GDPR, PCI DSS, SOC 2, ISO 27001, and the EU AI Act all require organizations to document and control how sensitive or regulated data flows out of their environment. Shadow AI, untracked AI usage, is a control failure under these frameworks. Organizations subject to these regulations must have documented AI governance policies and enforcement mechanisms.

More from the Vaikora blog