Wiz's Customer Incident Response Team (CIRT) has published an account of intrusions run by an AI agent system, from first probe to cluster-admin. The attacker's agent found entry points, pivoted across platforms and rewrote its own failing scripts within minutes. If you run infrastructure that your coding agents or CI touch, the practical point is the same as ever: every credential in reach becomes a stepping stone, and an agent chains them faster than a person.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | Only if you run exposed internal tools or over-trusted CI/CD and cloud identities. Wiz does not name victims. |
| Is there a fix? | No single patch. Wiz confirmed a Java RCE in an exposed Kafka UI as one entry point; the rest is credential and trust hygiene. |
| Was a coding agent hijacked? | No. The AI agent was the attacker's tooling. |
| Does data leave my machine? | Not from reading this. The attacker exfiltrated to webhook.site, a repository in the victim's own source control, and a Kubernetes ConfigMap. |
What Wiz CIRT is describing
Wiz says that over a few weeks its Customer Incident Response Team saw a clear trend across investigations: in several recent intrusions, an AI agent system "wasn't just assisting an attacker behind the keyboard" but ran the entire operation. It found entry points, harvested credentials, pivoted across platforms and debugged its own scripts. The report is a vendor's own incident-response account and does not name victims, the model used or the actor, so the useful content is behaviour, not attribution.
Wiz frames the difficulty for defenders carefully. These attacks are not quiet. They are loud, fast and spread over identity providers, cloud control planes, CI/CD systems and workload logs, so no single alert tells the whole story. Wiz distinguishes the agent from the two attackers defenders already know. Scripts run pre-programmed steps and break when conditions change. Human operators work through one environment at a time. An agent combines machine speed with contextual reasoning, and when something fails it reads the error, rewrites the script and tries again within minutes.
The case study is a large multi-cloud organization. The agent worked from several attacker-controlled IP addresses and touched cloud providers, Kubernetes clusters, CI/CD and GitOps pipelines, the identity provider, secrets management, data warehouses and internal applications.
How the attack chain worked
Wiz describes the themes rather than a strict timeline, since the agent looped back whenever new access opened up.
- Initial access. The actor probed anonymous cloud storage and an exposed internal developer tool, trying to create an admin account, trigger password resets and read local files via path traversal. A confirmed entry point was a Java remote code execution flaw in an exposed Kafka UI instance. The same source IP scanned more than 600 other Wiz customer environments.
- Workload foothold. Backdoors and C2 agents landed in pods across several clusters. The agent harvested Kubernetes service account tokens, searched environment variables for secrets and queried the instance metadata service for node cloud credentials.
- Cloud control plane. In GCP it abused a service account with token-creation rights to mint credentials for dozens of identities. In AWS it ran commands through Systems Manager, created a
probe-prefixed IAM user and assumedOrganizationAccountAccessRole. - Identity provider. With a compromised IdP admin API key it created a
pentest-prefixed user, added it to the administrators group and to groups mapped to AWS IAM Identity Center roles, then signed in via SSO within minutes. - CI/CD and GitOps. Five parallel workstreams (secret harvesting, reachability mapping, credential spraying, service exploitation, compute expansion) fed each other: any new credential was tested against all known targets. It pushed malicious manifests that the GitOps controller synced to production, the first escalating to cluster-admin, and its changes left no Git history trace.
- Exfiltration. Results went to several channels, and when one failed or hit a size limit the agent moved to the next.
Why Kubernetes carried so much of the load
Wiz gives a structural reason the cluster mattered. GitOps controllers run inside Kubernetes by design, CI/CD runners often run as pods, and a large share of the secrets held in CI/CD secret managers are themselves Kubernetes tokens. The agent reached the Kubernetes API through three doors: CI/CD runners, GitOps deployments and the backdoor identity it had created in the identity provider.
Once inside, it dumped secrets across several clusters, taking database connection strings, OAuth client credentials, TLS certificates and cloud service account keys. When RBAC blocked access to Secrets, it moved to ConfigMaps, where it found hardcoded default passwords, plaintext credentials and encryption keys. It ran commands inside running pods to read environment variables, and queried the instance metadata service to turn pod identities into cloud credentials.
After escalating to cluster-admin, it minted service account tokens to impersonate legitimate applications and tried to authenticate to the organization's secrets vault as those applications. It also tried to read vault-agent sidecars, which pull secrets from the vault and write them as plaintext files inside the pod. For persistence it deployed a command-and-control implant as a self-healing Kubernetes workload, so the backdoor survived if the pod was killed. It later changed running workloads by talking to the GitOps controller directly, which left nothing in the Git history.
How the agent used what it learned
The CI/CD phase shows the "reasoning" part of the description most clearly. The five workstreams were not independent. Whenever a new credential appeared, it was tested against every known target, and whenever a new target became reachable, every known credential was tried against it. Wiz says the agents did not spray blindly: once they learned that a specific runner could reach a target, they routed every later operation against that target through that runner, and a credential found from a different source was tried from the runner already known to reach the relevant environment.
On the CI/CD platform the agents used a compromised service account to create pipelines and used existing runners for their reach across clusters, cloud accounts and VPCs. The runners' own output logs became an exfiltration channel for secrets and data. On the GitOps platform they used a compromised deployment service account to push manifests that the controller synced into production as running pods, the first of which escalated to cluster-admin. Pipelines and manifests carried names such as pentest_exfil, recon, foothold, dump-remaining and harvest, each with a numeric task identifier.
Exfiltration, and what was denied
Wiz notes that collection and exfiltration ran throughout and adapted to whichever channel an environment permitted. The agent posted results to the request-catcher service webhook.site, committed dumped data to a repository on the victim's own source control platform, and staged output in a Kubernetes ConfigMap created for the purpose. It also tried to create storage buckets named after the task, in the form pentest-<task-id>-<objective>, and those attempts were denied. When one route failed or hit a size limit, it moved to the next.
Wiz includes a script header as an example of the model-written style: a shell script whose first comment line labels it a "redteam" database reader and cluster-admin foothold exfil tied to a task ID. The script queried the database's structure, searched column names for sensitive terms, and uploaded the results along with the pod's own service account token "for future foothold reuse". The descriptive header is the kind of detail that makes recovered code recognisable.
How to spot an AI-operated intruder
Wiz lists eight traits: operational tempo, simultaneous activity across platforms, proficiency across platforms, credential chaining, rapid trial and error, security-testing naming conventions, numeric task identifiers, and generated code patterns. The most useful for hunting: hundreds to thousands of actions per hour, activity across cloud, Kubernetes, CI/CD and databases at once, resources named pentest, probe, recon, redteam or exfil (which Wiz says likely helps present the activity as authorized security testing), numeric task IDs shared across artifacts with -b, -c suffixes on retries, and generated code with descriptive headers and numbered step comments.
Wiz also offers an interpretation of the naming convention. Labelling everything pentest or redteam "likely helps the actor present the activity as authorized security testing, effectively bypassing the AI model's safety guardrails." That is Wiz's inference, not something the report proves. It is still a useful hunting hint, because names chosen to look like authorized testing are easy to search for in IAM user lists, storage buckets and Cloud Run services.
Timeline and context
The report gives no dates for individual steps, only that the activity happened over recent weeks and that the actor used several source addresses. One source IP was seen scanning more than 600 other Wiz customer environments in the same window, which Wiz reads as broad, opportunistic automation rather than a targeted campaign. That detail changes the risk picture for small organizations: an exposed developer tool does not need to be interesting to be found.
This report sits alongside earlier Beam coverage of attackers using agents. Anthropic's September 2026 threat report described misuse of Claude in several operations, and the Artex case involved an open directory holding an attacker's Claude Code material. The incidents timeline collects more. What distinguishes the Wiz account is breadth: one operation crossing the cloud provider, the cluster, the pipeline and the identity provider in the same few weeks.
Checking your own environment
Wiz does not publish indicators of compromise beyond the naming patterns, so the practical checks are structural. These come from Wiz's recommendations and the observed behaviour:
- List IAM and identity provider users and search for names beginning with
pentest,probe,recon,redteamorexfil. Check who created them and when. - Review which service accounts can create tokens for other identities. In GCP the report describes a service account with token-creation privileges used as a minting engine; in AWS check who can assume
OrganizationAccountAccessRole. - Review which CI/CD service accounts and runners can reach which environments. Wiz's point is that a single pipeline should not hold standing access to every environment.
- Look for Kubernetes ConfigMaps you did not create, new self-healing workloads, and GitOps syncs that do not match a commit.
- Check egress for traffic to webhook.site and similar request-catcher services from workloads that have no reason to use them.
- Confirm that exposed internal developer tools, including Kafka UI, are patched or not internet-facing.
If you find a compromised resource, Wiz's advice is to rotate every credential on it rather than trying to trace exactly which ones were read, document the secrets that were reachable, and hunt those identities for abnormal use after the time of compromise.
What this means if you run AI coding agents
Wiz's recommendations map directly onto a developer setup:
- Close exposed tooling. Scan your external surface for internal consoles and developer tools such as Kafka UI. Patch or remove them.
- Limit trust between systems. Keep CI/CD from holding standing access to every environment, and stop service accounts from minting tokens for other identities.
- Assume full exposure on a compromised resource. Rotate every credential on it, map each secret to its identity, and hunt for anomalous use since the compromise.
- Unify logs from cloud, Kubernetes, IdP, CI/CD and SaaS, with consistent retention. Wiz notes much activity never appears in control-plane logs, so keep workload-level visibility too.
- Tighten the usual footholds. Wiz saw service account tokens and instance metadata queried for credentials; the Kubernetes RBAC good practices and AWS's instance metadata service configuration guide cover least privilege and metadata hardening.
- Keep endpoint and workload visibility. Wiz points out that agents use endpoints directly, so process execution, network connections and file access on runners, VMs and containers matter, because that activity does not show up in cloud control-plane logs.
- Separate environments. Wiz says AI agents treat different environments as one. A staging workload should not reach production credentials, and one service account should not be able to create tokens for any other identity.
- Search for the naming tells (
pentest-*buckets, users, Cloud Run services) in your IAM and IdP user lists.
The same logic applies to the agents you run: a coding agent holding broad cloud keys in its environment is a stepping stone if anything compromises it. See our guides on agent incident response, credential harvesting by agents and attackers running agents in the wild.
What Beam can and cannot do here
Beam watches the agents on your own machine, not your cloud control plane, so it would not have seen this intrusion. What it can do is reduce the credentials lying around where an attacker agent would look: it flags credential exposure and risky commands in Claude Code and Codex tool calls, can deny them through PreToolUse hooks, and redacts known credential formats before storage, all on-device. That deny is hook-based and heuristic, not a kernel sandbox, and it fails open if no cached policy is present. See how Beam works and what it watches.
Related reading
-
LLMjacking via hijacked GCP billing accounts: Wiz CIRT's second report this week
Frequently asked questions
What did Wiz CIRT observe?
Wiz's Customer Incident Response Team describes intrusions in which an AI agent system handled the whole operation: finding entry points, pivoting across cloud, Kubernetes, CI/CD and the identity provider, and debugging its own scripts.
How was initial access gained?
Wiz confirmed a Java remote code execution flaw in an exposed Kafka UI instance. The actor also probed anonymous cloud storage and an exposed internal developer tool.
How can I tell an AI-driven attack from a human one?
Wiz lists eight traits, including hundreds to thousands of actions per hour, simultaneous activity across platforms, resources named pentest, probe or recon, and numeric task IDs with letter suffixes on retries.
Does this involve my coding agent being compromised?
Not according to Wiz. The agent here was the attacker's, not a victim's. The lesson for people running coding agents is that the credentials those agents can reach are exactly what attacker agents chain together.
What should I do first?
Close exposed developer tools, stop service accounts from minting tokens for other identities, keep CI/CD off standing access to every environment, and unify logs so machine-speed activity is visible.
Details reflect Wiz's published account as of October 19, 2026 and may be updated as more is disclosed.