AI adoption is outpacing enterprise control. The 2026 Verizon DBIR found that 45% of employees regularly use AI on corporate devices, and 67% of those users access AI through non-corporate accounts. Cyberhaven Labs reports that 39.7% of data sent to AI tools is sensitive, while endpoint AI app adoption grew 509% year over year.
Our earlier blog post addressed the first question every security team asks: What AI is running on my network? But seeing AI activity isn’t the same as knowing when it is a problem. AI applications now run inside trusted enterprise workflows, accessing source code, credentials, internal systems, and external APIs. When these tools are compromised or behave unexpectedly, the activity may still look legitimate: Authorized applications, valid credentials, approved destinations. Endpoint and DLP controls often can’t tell that apart from normal use. The network can. Every AI interaction crosses it, and the network is the one place that records where data actually went and whether that flow is normal for the host that made it. In the recent case of the Hugging Face breach, AI agents modified logs to hide their own activity. The network record didn’t change.
We have expanded our capabilities beyond basic AI visibility to deliver active AI threat detection. Our sensors detect AI activity behaving like a threat at machine speed, utilizing traffic that no endpoint solution has access to and that gateways can miss. These detections flag activity against each network’s own baseline rather than a rule list that quickly goes stale. We help security teams to move from "we know what AI is here" toward "we know when to investigate."
When a trusted component of the AI stack is compromised, its network behavior can change even though the software itself is sanctioned. That became concrete in March 2026, when attackers published backdoored LiteLLM releases that harvested secrets and communicated with attacker-controlled infrastructure.
A sanctioned component reaching new infrastructure is a behavioral change the network sees. Where the destination matches known-bad threat intelligence, Corelight flags it on the first DNS or TLS lookup, then triggers an anomaly on the network behavior change.
AI aggregators like OpenRouter, LiteLLM, Portkey, Helicone, and Braintrust introduce an indirection layer between the enterprise and the underlying model provider. For example, an employee routes requests through OpenRouter to access DeepSeek through what appears to be a US-based API endpoint. Without visibility into the new intermediary, this looks like sanctioned traffic.
Corelight names the aggregator instead of trusting it, and a subnet's first use of one is itself an anomaly. Analysts see the indirection layer and can check what's behind it.
Self-hosted LLM endpoints like Ollama, vLLM, and other open-source inference servers are being deployed faster than security teams can inventory them, and attackers are already scanning for them. Real-world honeypot research documents sustained probing for vulnerable paths, fingerprinting via known attacker user-agent strings, and attempts to invoke exposed inference APIs.
Corelight detects reconnaissance and exploitation attempts against self-hosted model infrastructure and adds network access anomalies to the self-hosted service, giving security teams visibility into attackers targeting AI endpoints.
The application is sanctioned; the volume and the geography are not. Independent anomaly models (application usage, data volume, and destination country) fire on the same activity. These are the types of patterns seen in the LLMjacking campaign that could have run up ~$46K/day in victim costs or the DEF CON example of an AI application compromise that automatically uploaded passwords, credentials, and sensitive information from user prompts to the attacker's infrastructure.
Corelight delivers several signals based on anomalous behavior, not a brittle rule set, giving an analyst far stronger grounds to escalate than a single signal by itself.
Detecting AI threats is only valuable if your team can see them in the tools they already use. Corelight's Q3 2026 release introduces purpose-built Shadow AI dashboards for multiple SIEM platforms (Splunk, Microsoft Sentinel, Elastic, SentinelOne, and Corelight Investigator) with consistent panel logic and field mappings.
The dashboards include dedicated views for:
For a CISO, this converts previously unidentifiable risk into a reportable metric. You can walk into a board meeting with structured evidence showing which AI services are being observed, which providers and intermediaries are involved, where unusual data movement is occurring, and what threats were detected and investigated.
Corelight combines AI service visibility, threat intelligence, behavioral analytics, and investigation context to cover a broad range of AI-related risks:
| Security problem | What Corelight detects |
|---|---|
| AI application and service usage | Use of known GenAI services and applications |
| Shadow AI anomalies | Anomalous use of GenAI services and applications that are uncommon for the subnet and peer groups |
| AI gateways and aggregators | Traffic through services such as OpenRouter, LiteLLM, Portkey, Helicone, and Braintrust |
| Provider and jurisdiction risk | Connections to AI providers or destinations that may violate organizational policy |
| AI supply-chain compromise | Communications with known infrastructure associated with compromised AI software |
| Scanning of exposed AI infrastructure | Reconnaissance against self-hosted LLM and inference endpoints |
| Exploitation attempts against AI endpoints | Attempts to access or exploit exposed AI services |
| Unusual data movement | AI-associated systems transferring atypical volumes of data |
| Unexpected geography | Connections to countries or regions not normally seen for an asset or subnet |
| Subnet-level anomalies | Activity that is unusual for a network segment |
| Peer-group anomalies | Systems behaving differently from comparable peers using the same applications |
| Investigation context | Network activity surrounding an AI-related detection |
| SOC visibility | AI usage, threat indicators, gateways, providers, and anomalies in existing workflows |
Knowing what AI is on your network was the first question. The harder questions are: Is a trusted component compromised? Is an aggregator hiding where data actually goes? Is someone probing your inference endpoints? Is an AI tool moving data somewhere it's never been?
AI inventory tells you where AI exists. AI threat detection tells you when to investigate.