Proof Over Prediction: What Happens When You Actually Watch Who's Attacking AI Infrastructure

Customer telemetry shows how AI agents behave in a limited set of production environments and what risks they carry. Vulnerability research surfaces how those environments can be attacked. Both sources are valuable, but neither shows actual attacker behavior or how quickly they operationalize a new vulnerability once it's public.

To find out, Zenity Labs deployed a global fleet of decoy AI systems, including self-hosted inference servers, AI gateways, and agentic endpoints, across multiple cloud providers and regions. The goal wasn't to confirm that AI infrastructure could be attacked. The goal was visibility into how attacks unfold in practice, so the detections Zenity builds reflect what real attackers actually do rather than what researchers assume they would.

Why This Kind of Intelligence Has Been Missing

Earlier this year, GreyNoise published findings on AI-system fingerprinting and active recon campaigns, among the first documented evidence that AI infrastructure was being scanned and probed at scale. Microsoft has also reported on attacker behavior targeting AI endpoints. Those contributions matter, and this research builds on both.

But AI-native honeypot coverage has remained limited relative to traditional infrastructure. The intelligence sources most defenders have today reflect different things:

• First-party telemetry from their own environments tells them about their attack surface.
• CVE and patch advisories tell them what to fix.
• Traditional network threat intelligence wasn't built for AI-specific attack surfaces.

What those sources don't provide is behavioral data on how threat actors approach AI infrastructure in the wild. Honeypots configured to mimic real AI deployments generate exactly that, treating every inbound interaction as a data point from a real attacker in a real environment.

What the Sensors Caught

The network captured nearly 10,000 attack attempts across AI environments. The findings fall into three categories.

CVE exploitation in days

CVE-2026-40217, a CVSS 8.8 remote code execution vulnerability in LiteLLM's custom-code guardrail, was publicly disclosed on April 10th. The first exploitation attempts hit the sensors within days.

LiteLLM is one of the most widely deployed AI gateways in enterprise environments, with close to 100 million monthly downloads. It sits at a high-trust position in most AI stacks, routing traffic across providers. Over the six weeks following disclosure, sensors recorded nearly 600 attack requests from eight distinct source IPs across multiple cloud environments, with payloads escalating from initial probes through sandbox escape techniques to OS command execution attempts. The progression points to a practiced exploit chain, not opportunistic scanning.

A second campaign targeted an SSRF vulnerability in LiteLLM's connection-test endpoint that had bypassed the original CVE-2024-6587 fix and remained exploitable through several subsequent releases. Sensors captured almost 3,000 exploitation attempts from more than 20 source IPs, all structured to exfiltrate the proxy's master key and provider API credentials by redirecting the proxy's own outbound connections to attacker-controlled servers. A successful hit means the attacker leaves with credentials for every AI provider the organization has connected to their gateway.

Sensors also captured active SSRF reconnaissance against Ollama, corroborating and extending the fingerprinting campaign GreyNoise reported earlier in 2026. Attackers were sending blind callback probes to confirm which Ollama instances were vulnerable, with source IPs that included a documented Tor exit node. This is the pre-exploitation phase made visible: attackers building target maps of vulnerable AI infrastructure, not waiting for a CVE announcement to start looking.

Hijacked infrastructure for offensive operations

Beyond direct exploitation, the sensors documented something in a different threat category entirely: attackers using exposed AI endpoints to conduct attacks against live third parties without the knowledge of the infrastructure owner.

In one incident, a threat actor configured Strix, an autonomous AI pentesting agent, to run on the hijacked infrastructure and directed it against a live French e-commerce website. The agent's instructions specified it should run continuously for more than 2,000 steps without requesting permission. Repeated retry commands in the session logs indicate a live operator was actively steering the campaign through the agent.

In a second incident, a threat actor using OpenAI Codex in its most permissive configuration accidentally routed an active session through a sensor, exposing a scanner built to enumerate publicly accessible LiteLLM endpoints across the internet, along with active reconnaissance results.

AI compute theft: the evolution of the cryptominer

Cryptomining attacks were effective because the logic was simple: find exposed compute, route your workload through it, and let someone else absorb the cost. The same pattern is now playing out against AI infrastructure.

Multiple threat actors were found routing their own AI workloads through exposed endpoints as free, anonymous compute. One group was running a full multi-agent workflow with five active sub-agents and cron-based orchestration after exhausting their paid provider credits. Error logs showed the exposed endpoint was being used as a failover in their production routing stack. A second actor inadvertently exposed their development environment, git history, and reconnaissance scripts by routing a live session through a sensor.

The compute cost is almost beside the point. The pattern reveals how exposed AI endpoints get treated once they're found: as a resource to be used. In being used, the endpoint may generate API costs, create outbound traffic, and participate in downstream activity the legitimate owner has no visibility into. Unlike cryptomining, where the worst outcome is a high electricity bill, the consequences here can include the endpoint's model infrastructure being directed at real targets.

The Defender Timeline Has Already Shifted

Five days from CVE disclosure to active exploitation isn't a future risk. It's the current operating tempo for AI infrastructure. Autonomous offensive tools are available, documented, and in active use against real targets. The SSRF credential-exfiltration campaign ran with consistent payload structure across more than 20 rotating source IPs, the signature of automated tooling at scale.

The Ollama recon campaigns add a layer to this picture: attackers are building target inventories before a CVE is acted on. Detection at the exploitation phase is already late. Organizations running self-hosted AI infrastructure that lacks authentication, egress controls, or monitoring on administrative endpoints aren't positioned ahead of this threat.

The Strix incident raises a specific question most organizations aren't asking yet: if your AI endpoints were being used to attack a third party right now, would you know?

Attack chains in the wild to Platform Defenses

The value of running a honeypot network isn't only in the findings themselves. It's in how those findings translate into the platform.

Zenity builds detection rules directly from what the sensors capture. Each observed attack pattern, whether the LiteLLM sandbox escape payload structure, the SSRF credential-exfiltration chain, or the behavioral signatures of autonomous agent hijacking, becomes the basis for a specific detection in the platform. A rule built from an actual attacker's payload reflects real decisions: the obfuscation choices that operator made, the specific tool signatures they used, the escalation sequence they followed. That precision is harder to achieve when detection is modeled from hypothetical attack paths.

Customer environment telemetry shows Zenity what's happening inside organizations. The honeypot network shows what's happening outside them. Together, they create a feedback loop: attacker behavior observed in the field translates into updated detections without waiting for that behavior to appear inside a customer environment first. Each new finding extends that coverage, and the gap between what attackers are doing and what the platform can detect narrows over time.

Access the full research, including CVE timelines, attacker TTPs and defender recommendations, is available at www.labs.zenity.io