Key Insights
In September, Google's Threat Intelligence Group described an actor who used "an AI coding chatbot, a prompt, and a set of agent instructions" to plan, build, and run a mass credential-harvesting campaign in under six hours, compromising thousands of third-party credentials. The same report describes an exposed dashboard managing more than 23,800 harvested secrets, including cloud and AI API keys, though GTIG did not tie it to the same actor.
Keys like those don't trip much when they're used. Every API call they make is authorized.
Our analysis of the Hugging Face breach looked at what happens when hundreds of agents coordinate, and why views built one identity at a time miss it. This post covers the floor underneath that: the four signals that still catch a single AI attacker, or your own agent gone off script, and why they only work together.
Why Cloud Security Tools Miss AI Attackers
Most cloud security stacks were built to answer three questions. What's misconfigured? Does this match a known attack? Is this endpoint compromised?
Posture tools tell you a door is unlocked, not who's walking through it. Rules need a pattern written in advance. And there is no endpoint agent sitting on an API call. An attacker working through valid credentials gives none of them much to work with. The activity only looks wrong next to what that identity normally does, or next to something no legitimate process should ever touch.
Signal 1: Cloud Activity Logs, Read as a Biography
Every major cloud already writes down what happened: who called which API, from where, against which resource. Most teams store these logs for compliance and query them after an incident.
The shift is to read them as a running biography of each identity. A deployment service account that has called the same forty APIs from the same two regions for a year has a stable fingerprint. The day it calls a forty-first API from a third region, that's a fact to act on, even though no rule anywhere says it's bad.
Signal 2: Control-Plane Changes
Attackers and runaway agents both want more access, and in the cloud, access is granted in the control plane. Watch for:
New roles and trust policies
Policy edits that widen access
New access keys on existing identities
Changes to logging or monitoring configuration
New compute in unusual places
Any one of these can be routine. A burst of them from an identity that seldom touches the control plane is something else.
Signal 3: The Texture of Machine-Speed Access
Look for first-time access to a resource, a sharp change in volume or rate, access at odd times for that identity, and chains of actions that cross systems the identity has never linked before.
AI-driven activity has a texture people at keyboards don't produce. It enumerates fast, retries instantly, and pivots without pause. A credential harvest planned and run in under six hours is that texture at scale. Initial access with a stolen key can look perfect. What the key does next is where it stops looking human.
Signal 4: Decoy Credentials and Honeypots
Decoys are among the oldest tricks in security and among the most underused in cloud. Plant credentials, keys, secrets, storage buckets, and instances that no legitimate process will ever touch, and make them look valuable to anything scanning for useful material.
Their value is precision. When a decoy key is used, there is no ambiguity to adjudicate. An attacker testing a pile of harvested secrets will test a planted one along with the rest.
Why the Four Signals Only Work Together
None of these signals is enough alone. Logs without baselines are noise. Baselines without tripwires drift toward false positives. Tripwires without context tell you something is wrong but not what else that identity touched.
Joined, they answer three questions about every human, service account, key, and agent: what is normal for it, what can it reach, and what did it actually reach? Add one check across identities, the same key in use from several places at once, because that's where per-identity views go blind.
The bar is precision. Card networks stopped cataloging bad transactions long ago and started modeling normal for each cardholder, acting on deviations in milliseconds. They can act without a human because false positives are rare. Cloud detection has to reach that standard before anyone will let it act on its own, which is a design problem we'll take up later in this series.
Four Questions to Ask of Any Cloud Detection Approach
Four questions are a good place to start, whether you're evaluating a vendor or your own stack. First, can it tell you, per identity, what normal looks like? Second, does it see the control plane and the data plane together? Third, can it fire with near-zero false positives on your busiest legitimate day? Fourth, would it notice the same credential in use from two places at once?
If any answer is no, that's the gap an attacker with a harvested key will use. None of these signals is new. What's new is how many valid keys are in circulation and how fast an AI-assisted attacker can try them.
We track AI-driven attacks as they're reported and what they mean for defenders. Our AI security resource hub collects our latest research, guides, and analysis in one place.
Get AI Security Resources