Incident Published: Sep 15, 2026

Attacker Tooling Now Knows AI Internals: Ninety Days of Honeypot Traffic

Wiz Threat Research ran honeypots emulating LiteLLM, Flowise, LangChain, Langflow, ChromaDB, Ollama and other services for 90 days. Alongside ordinary CVE exploitation, the traffic showed tooling written specifically for AI internals: prompts injected into agent frameworks to make them run operating-system commands, confirmed by a DNS callback rather than visible output; proxy credentials read out of a running process's Python module state instead of from disk; and cryptominers staged in directories named after AI tooling.

Prompt InjectionCredential TheftAI Deployment SecurityAI InfrastructureAgentic AI
7 applicable AIDEFEND defenses
Source: Inside 90 days of attacks on AI infrastructure 
Authors: Yaara Shriki, Wiz Threat Research
Original article: Aug 27, 2026

Threat Analysis

  • Injection aimed at the shell, not the answer. Against LangChain, Flowise, OpenWebUI and Node-RED, attackers sent prompts designed to make agents run OS commands. A DNS query to an attacker-controlled domain confirmed execution, the target's address encoded in the subdomain, so no output needed to come back. The second stage came from Pastebin, base64-encoded to evade logs and filtering.
  • Post-exploitation adapted to the product. On LiteLLM, rather than hunting for credential files, attackers imported the running application's own Python modules and read the master key from module state, because it lives in memory rather than on disk. They also enumerated config paths and fingerprinted the backend with the documented default key.
  • Miners dressed as AI artifacts. One Langflow miner was staged in a .claude directory and renamed unicorn; a Node-RED miner sat where it blended into the Node.js tree.
  • Evidence boundary. These are honeypots: no event counts, window dates, or named victims are published. Wiz states plainly that the injection prompt text is a reconstruction, not captured traffic; it observed the process tree, the callback, and the miner.

Applicable AIDEFEND Defenses (7)

AID-M-001.005
Public AI Endpoint & Agent-Service Exposure Discovery
Very High
Wiz names Marimo, Flowise, Langflow, Ollama, ChromaDB, and Milvus as tools that ship unauthenticated, and argues that anything unauthenticated on the internet should be treated as already compromised. Probing your own external surface with no corporate credentials, then reconciling every responding AI route to an owner and an approved exposure state, is what turns that argument into a work queue.
AID-H-017.002
Least-Privilege Tool Architecture
Very High
Every injection in this telemetry depended on the agent holding a general-purpose shell. Publishing only narrow, typed, single-purpose tools and refusing generic command execution unless a separately isolated control admits it means a smuggled instruction has nothing to call, which decides the outcome before any prompt filter is involved.
AID-I-001.004
Sandbox Network Egress Restrictions
Very High
The attacker needed outbound traffic twice: once for the DNS callback that proved the command ran, and again to pull the second stage from Pastebin. A default-deny destination policy enforced outside the agent's execution environment removes the confirmation signal and the payload fetch together, which is why it matters even when the injection itself succeeds.
AID-H-004.002
Service & API Authentication
High
Several of these services treat authentication as optional configuration rather than a precondition for running. Requiring a verified workload identity at the gateway or service boundary before any request reaches a model or agent handler removes the unauthenticated population that this traffic was searching for in the first place.
AID-D-005.003
Proactive AI Threat Hunting
High
A miner named unicorn inside a .claude directory will not trip a rule written for obvious malware paths. Hypothesis-driven hunts over AI host telemetry, looking for unexpected executables inside AI tooling directories and for an inference or agent process spawning a shell, are how this camouflage gets found after the fact.
AID-D-005.007
Token, Tool-Use, Request-Parameter & Cost Spike Detection & Alerting
High
Stolen provider keys are monetized by running inference on the victim's bill, so the abuse surfaces as consumption rather than as an intrusion alert. Baselining token usage and provider cost per calling identity, then alerting on sharp deviation, gives a signal that survives even when the key theft itself left no file-system trace.
AID-H-002.002
Inference-Time Prompt & Input Validation
Medium
A synchronous gate at the inference edge normalizes and screens incoming text before the agent acts on it, which raises the cost of casual injection attempts. Treat it as a supporting layer here rather than the boundary: the observed second stage arrived base64-encoded specifically to get past prompt-level filtering, so AID-H-017.002 and AID-I-001.004 are the controls that decide this outcome.

What Defenders Should Do Now

  • List every AI service running in your environment and check which ones are reachable from outside and which ones require a credential. Treat an unauthenticated AI service on the internet as compromised and take it off the internet before debating the patch level.
  • Audit what tools your agents actually hold. If any agent can run arbitrary shell commands, that capability, not the prompt filter, is the control that matters; replace it with narrow typed tools or move execution behind an isolated broker.
  • Apply default-deny egress to agent and inference workloads and allowlist only the endpoints they genuinely need. This removes both the out-of-band confirmation channel and the second-stage download seen here.
  • Add hunts for executables living inside AI tooling directories and for inference or agent processes spawning shells. Camouflage in this telemetry was chosen to look like normal AI tooling, so path-based intuition will not catch it.
  • Baseline token consumption and provider spend per calling identity, and alert on sharp deviation, since a stolen gateway key shows up as someone else's inference bill rather than as a file on disk.

Conclusion

The change worth noticing is not that AI services get attacked, but that the tooling arriving at them is written by someone who has read the product. Knowing that a proxy keeps its master key in module state rather than a file, or that a .claude directory is unremarkable on a developer host, is product knowledge applied to intrusion. AIDEFEND  points at the controls that hold regardless of how well the attacker knows the internals: authenticated access to every AI service, narrow tools instead of a general shell, default-deny egress around execution, and consumption monitoring that surfaces a stolen key even when nothing was written to disk.