Wiz has published a report on agentic attacks: intrusions in which AI agents do much of the hands-on work while a human sets goals and guardrails. Three of the cases come from Wiz's own investigations, and one of them entered through an MCP interface on an AI-agent backend. If you run Flowise, an MCP server or any agent-builder tool, the practical point is that these tools are now both a target and a way in, and an attacker's agent will use every credential it finds.
Wiz also lists seven "fingerprints" that separate agent activity from human operators and from canned scanners. Those are the most reusable part of the report, so this post walks through them with the cases that produced them.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | If you expose Flowise, a Java operations gateway or an MCP-backed service to the internet, you match the profiles Wiz investigated. Wiz does not name victims. |
| Is there a fix? | No single patch. The report points to reducing exposed attack surface, visibility and containment workflows. |
| Was a coding agent hijacked? | No. The agents were the attackers' own tooling. |
| Does data leave my machine? | Not from reading this. In the cases Wiz describes, cloud and Kubernetes credentials were bulk-exfiltrated from victims' servers. |
| Can I detect it? | Wiz says the activity is noisy and leaves traces; the seven fingerprints below are its detection guide. |
What Wiz means by an agentic attack
Wiz's thesis is that agents write custom tooling, read the output and iterate far faster than a person typing commands. That makes them different from a script, which breaks when conditions change, and from a human, who works one environment at a time. Wiz also stresses that capability is not stealth: agents make mistakes and leave broad trails, so the hard problem for defenders is telling agentic activity apart from legitimate automation.
This follows Wiz's earlier incident-response account, which we covered in Anatomy of an AI-Driven Cloud Attack. The new report widens the lens to public cases and adds three fresh investigations.
The public cases Wiz points to
Wiz cites reporting from other organizations. These are the vendors' claims as Wiz summarizes them; we have not re-verified each one.
- ARTEX in South Korea. Zscaler and CrowdStrike reported an agentic pentesting framework, ARTEX, used against internet-facing applications at financial institutions, with PII of about 67,000 people reportedly exfiltrated. We covered the details in the South Korea bank hack post.
- ARTEX and Storm-0940. Microsoft attributed a ConnectWise Cloud Backup supply-chain compromise to a China-state-aligned actor, with ARTEX speeding up reconnaissance, password spraying and OAuth application abuse. Sign-in attempts hit more than 2,250 tenants, with privileged cloud access in some cases in under three hours, though most attempts failed. See our Storm-0940 write-up.
- Hermes at the Thailand Ministry of Finance. Hunt.io found attacker infrastructure exposing logs of the Hermes agent running unattended in "YOLO" mode, enumerating hosts and hunting for privilege escalation. Several ministry systems were compromised with web shells, stolen credentials and a custom Go-based implant. Initial access is unknown. For the agent itself, see Unit 42's Hermes Agent cybercrime findings.
- Japan. JPCERT/CC described attackers using AI to scan for known vulnerabilities, exploit APIs, reverse-engineer Android apps to find those APIs and test for SSRF.
- CrowdStrike's custom workflows. Four actors hit healthcare, government and private-sector targets with tooling ranging from a PentestGPT-derived harness with supervisor and executor agents to Claude Code workflows, with credential and medical-record theft reported.
- DIVD. The Dutch institute disclosed a breach whose way of working suggested agentic AI, without identifying the agent.
Three intrusions Wiz investigated
| Case | Entry | Scale |
|---|---|---|
| A | Exposed Flowise, a Node.js AI-agent builder. An unauthenticated request with an internal-origin header bypass led to injected JavaScript spawning a shell. | 99 scripts over about 24 hours, one every 1 to 2 minutes. The agent then used the instance to mass-exploit dozens of other Flowise servers. |
| B | A Java enterprise operations gateway: a JVM-spawned shell, then a base64 C2 beacon. | 602 unique steps across 12 technique families in about 4.5 hours, covering cloud metadata, Kubernetes RBAC, RabbitMQ, Hazelcast, ArgoCD and InfluxDB. |
| C | An AI-agent GraphQL backend with an MCP interface. Attacker-controlled MCP command arguments led to a shell. | About 21 hours, 803 comment lines and 150+ scripts. Bulk secret exfiltration of cloud and Kubernetes credentials, persistence and spread across pods. About 25 organizations were targeted, including crypto exchanges and fintechs. |
Case C matters most to readers of this blog. MCP servers that launch processes take arguments from the client, and when the surface is reachable by an attacker, those arguments become a command line. It is the same class of problem as the Langflow MCP stdio RCE. The Model Context Protocol documentation describes the stdio transport that makes this pattern common.
Case A is also instructive: the compromised Flowise instance became attack infrastructure, scanning and exploiting its peers. An agent-builder you leave exposed can end up working for someone else.
The seven fingerprints
- Machine-paced, sustained iteration. Cadence varies with how hard each step is, and it lasts for hours. That is too slow for hand-authoring and too adaptive for a stock scanner. Case A's one-script-every-1-to-2-minutes rhythm is the example.
- Natural-language reasoning in the tooling. Scripts carry attack plans and self-documenting comments. In Case C, the commentary referred to "the other" agent instance and tried to work out what it had achieved. Wiz calls this its smoking gun and notes that human attackers rarely sign their work that way.
- Self-correction. Versioned scripts explain why the previous version failed. Wiz cites rerouting around a customized allowlist (Case A), walking through metadata-service fallbacks (Case B) and a four-generation request-signing debug (Case C). In Wiz's words, a static playbook cannot read an AWS error and re-derive the regional STS requirement.
- Structured, breadth-first methodology. Checklist-style coverage of many techniques instead of one objective.
- Verbosity and lateral spraying. Many lateral paths tried at once; in Case B, 15 ports across 5 hosts in parallel. Wiz argues the noise is itself a detection opportunity.
- Probe-before-payload and OPSEC wrappers. Harmless markers go out before real exploits, syntax is checked before loading, output is truncated, timeouts are set and traffic is blended with normal egress. Case B disguised a queue disruption as a routine repair action.
- Disposable, self-labeled artifacts. Throwaway names in
/tmpand in-memory paths, but some embed identifiers anyway: RabbitMQ parameters named after a C2 host (Case B) and an exploit description in an endpoint name (Case C). An agent generating names on the fly often does not think to hide them.
What changes for attribution and scale
Wiz makes two broader points. First, shared and repurposed tooling weakens code-similarity attribution, so Wiz suggests weighting victimology, targeting, infrastructure and objectives more heavily, citing the Shai-Hulud/TeamPCP and Miasma campaigns. Second, one operator can run more campaigns with less supervision. Both fit the pattern in our October 2026 attacks timeline, where several entries involve attacker-side agents.
What this means if you run AI coding agents
Nothing in the report says a coding agent was compromised. But the same infrastructure that hosts agent builders and MCP servers often sits next to the credentials your coding agents use, so a few checks are worth doing today.
- Find what is exposed. List every Flowise, Langflow, MCP gateway or agent-builder instance you run and confirm none is reachable from the public internet without authentication. Check the version of each against its vendor's advisories; for Flowise, start at the project repository.
- Review MCP launch configs. Look for servers that pass client-supplied values into a command line or shell. Treat any MCP interface that accepts command arguments over the network as remote code execution waiting to happen.
- Shrink what a shell can reach. In Cases B and C, the agent harvested cloud metadata and Kubernetes credentials once it had a shell. Restrict metadata service access, use narrow RBAC and keep long-lived secrets out of environment variables.
- Hunt with the fingerprints. Search process and file telemetry for scripts in
/tmpwith long natural-language comments, versioned retries of the same script, and a single source touching many ports and services at a steady cadence. Wiz says this activity is noisy. - Rotate after exposure. If an exposed instance may have been reached, rotate the cloud, Kubernetes and API credentials it could read, not just the instance's own.
What Beam can and cannot do here
Beam is local security and observability for coding agents on your own machine. It does not monitor internet-facing servers or detect an attacker's agent on your network, so it is not the tool for Cases A to C directly.
Where it applies: Beam scans skill and MCP configs before you run them with its heuristic checks, and flags risky actions such as credential exposure and destructive commands in the coding agents it watches. For Claude Code and Codex, its policy can deny a flagged tool call through a PreToolUse hook. That is hook-based, not a kernel sandbox, and scanning is heuristic rather than semantic analysis. See how Beam watches agent activity and why everything stays local. For monitoring a running web app, see Beam Monitor.
Related reading
- Anatomy of an AI-Driven Cloud Attack
- South Korea bank hack with ARTEX
- Unit 42 on the Hermes Agent
- Monitoring a Mac mini running OpenClaw and Hermes Agent
Frequently asked questions
What are agentic attacks?
Wiz uses the term for intrusions in which a human sets objectives and guardrails while AI agents write custom tooling, read the results and iterate at machine speed. The agent is the attacker's tool, not a compromised victim.
What cases did Wiz investigate itself?
Three: an exposed Flowise server (99 scripts in about 24 hours), a Java enterprise operations gateway (602 steps over about 4.5 hours) and an AI-agent GraphQL backend with an MCP interface (about 21 hours, 150+ scripts, around 25 targeted organizations).
How can I tell an agent from a human or a scanner?
Wiz lists seven fingerprints, among them machine-paced iteration that lasts for hours, natural-language reasoning inside scripts, versioned self-correction, breadth-first methodology, probe-before-payload habits and disposable but self-labeled artifacts.
Does this mean my coding agent was hijacked?
No. In these cases the agent belongs to the attacker. The relevance for people running coding agents is that agent-builder tools and MCP servers were the doors, and attacker agents chain whatever credentials they find.
What should I do first?
Remove agent builders and MCP endpoints from the public internet, patch them, keep secrets out of the environments they run in, and alert on sustained, many-path activity from a single source.
Details are accurate as of October 29, 2026, based on Wiz's published report. Figures for the public cases are the reporting organizations' claims as summarized by Wiz, and may be revised as investigations continue.