Wiz: AI Agents Are Now Running Entire Cloud Attacks at Machine Speed

AI agents are running the whole operation

According to Wiz, its CIRT has seen a clear trend in recent investigations: AI-driven attacks are on the rise. In several intrusions, the AI agent system was not merely assisting a human attacker. Wiz says it ran the entire operation. It found entry points, harvested credentials, pivoted across platforms and fixed its own scripts as it went.

Wiz describes these intrusions as "loud", fast and present at every layer of the cloud stack. The difficulty for defenders, the company argues, is not that the attacks are invisible. Their footprint is split across identity providers, cloud control planes, CI/CD systems and workload logs, and no single alert tells the full story.

Eight traits that set them apart

Wiz says AI agents combine machine speed with contextual reasoning, which separates them from scripts that run pre-programmed steps and from human operators who work slowly and in sequence. Across investigations, the CIRT lists a recurring set of characteristics:

• Operational tempo: hundreds or thousands of actions per hour, continuing for long periods without pauses or working-hour patterns.
• Simultaneous multi-platform activity: one task enumerates cloud resources while others deploy Kubernetes workloads, create CI/CD pipelines or query databases, all from the same source in the same time window.
• Proficiency across platforms: the agent uses the native APIs and tooling of cloud providers, container orchestration, CI/CD systems, databases, identity providers and message queues.
• Credential chaining: each credential becomes a stepping stone. Wiz gives the example of a Kubernetes service account token leading to a cloud service account, then to a CI/CD system, and finally to full administrative access.
• Rapid trial and error: when an attempt fails, the agent reads the error, rewrites its script and tries again within minutes.
• Security-testing naming: resources and payloads carry labels such as pentest, probe, recon, redteam and exfil. Wiz says this framing likely helps present the activity as authorized testing, effectively bypassing the AI model's safety guardrails.
• Numeric task identifiers: the same number often appears across related artifacts, and retries add a letter suffix such as -b, -c or -d. Wiz says these appear to be internal task IDs.
• Generated code patterns: recovered code has descriptive headers, numbered step-by-step comments and helper functions reused across dozens of payloads.

Inside one multi-cloud intrusion

The case Wiz walks through involved an organization with a large multi-cloud environment. The agent worked from several attacker-controlled IP addresses and moved through cloud providers, Kubernetes clusters, CI/CD and GitOps pipelines, the identity provider, secrets management, data warehouses and internal applications.

For initial access, the actor probed multiple internet-facing services. It sent exploitation payloads for well-known vulnerabilities, tried anonymous access to cloud storage and worked through the API of an exposed internal developer tool, where it attempted to create an administrator account and uploaded a test file with a pentest prefix. One confirmed entry point was a Java remote code execution vulnerability in an exposed Kafka UI instance, followed by malware deployment and a C2 channel. Wiz says the agent kept scanning for alternative entry points even after it had a foothold. The same source IP address was seen scanning more than 600 other Wiz customer environments in the same window, which Wiz calls consistent with broad, opportunistic automation.

Once it had code execution, the agent pursued three goals almost at once. It deployed backdoors and C2 agents to multiple pods across several clusters. It extracted mounted Kubernetes service account tokens, searched environment variables for strings such as token, secret, key and pass, and queried the Instance Metadata Service for the node's cloud credentials. It also scanned internal message brokers, schema registries and databases to see what was reachable from inside the pod's network.

Cloud control plane and identity provider

Harvested credentials became the main route into the cloud control plane. The agent operated in both GCP and AWS at a tempo Wiz says no human could match. In GCP, it turned a service account with token-creation privileges into an automated minting engine that generated credentials across dozens of identities. It also scraped container registries in a continuous loop, tried to exfiltrate database records and deployed publicly accessible Cloud Run services prefixed with pentest-.

In AWS, it used Systems Manager to run commands across instances, tried to connect to databases, moved laterally over SSH and staged exfiltration to a bucket named pentest-<task_id>. For cross-account persistence, it created an IAM user prefixed with probe and used it to assume OrganizationAccountAccessRole, gaining administrative access across member accounts in the AWS Organization.

The agent also built an identity of its own. With a compromised administrator API key for the identity provider, it created a user with a pentest prefix, set its password, activated it and added it to the administrators group. When the identity provider returned errors, the agent troubleshot each failure on the fly.

What it means for security teams

Wiz frames the post as a guide to recognizing machine-speed attackers and says it outlines what teams need in place to detect and respond to them. The signals it highlights are practical ones: very high action rates with no pauses, parallel activity across several platforms from one source, security-testing labels on resources, numeric task IDs and heavily commented generated code.

Because each of these traces sits in a different system, the case suggests defenders need to correlate identity, cloud, CI/CD and workload logs rather than rely on a single alert.