Identity in 36 AI-agent intrusions

October 21, 2026

Since July I've kept a catalog of public incidents where an AI agent did a real share of the attacking. It includes evaluation runs that got out of their sandbox, criminal operators driving agent harnesses, and state actors using models across a whole intrusion. There are 36 records now. Each one is mapped to MITRE ATT&CK and, where it makes sense, tied to a detection rule.

Earlier this month I went back through it looking only at identity. I expected to find agents doing something new to authentication. I didn't find that.

What the records show

31 of the 36 records include at least one identity technique: valid accounts, credentials left in files, stolen or replayed tokens, account manipulation or creation, password guessing, forged credentials, or credential dumping. Credentials found in files or repositories (T1552.001) appear in 20 records. Use of valid accounts (T1078) appears in 22.

None of them involved breaking a cryptographic control. Every compromise used a credential that was valid, an account that was legitimately registered, or an authentication flow doing what it was built to do.

Cryptography comes up in only three records, and in each one it either held or was never turned on:

In the JadePuffer intrusion Sysdig reported, the agent tried to forge tokens for a Nacos server using the product's well-known default signing key. The server used a custom secret, so the agent dropped that path and tried others.
In one of OpenAI's June training runs, an internal model got protected data from a government statistics site by sending unsigned tokens. The site accepted them without checking a signature.
In the OALABS case, the operator's agents stole a Lightning wallet database and tried to crack it. The keys were encrypted and the attempt failed.

My read is that a valid credential is no longer good evidence of who is on the other end. What's left to detect is behavior, and what stands out in these records is speed and parallelism.

What the agent looks like in identity logs

One credential from many places at once

In the marimo intrusion Sysdig reported, a stolen cloud key made 12 GetSecretValue calls from 11 different edge IPs in 22 seconds. OpenAI's research agents that reached Australia's Medicare statistics portal rotated source IPs and sent made-up browser user-agents. Impossible-travel rules and per-IP correlation miss both. Catching them takes a client identity that survives IP changes, like an API key bound to a registered consumer, a session identifier, or a TLS fingerprint.

One principal across every plane within minutes

In the intrusion Unit 42 wrote up in September, agents tested stolen access across cloud, identity, CI/CD, container and SaaS environments in parallel, then set up persistence on all of them in the same window. A human operator usually works through those one at a time. A detection that follows the principal across planes can see this. A detection that watches each log source on its own can't.

Secret found, secret used, no pause

When Gemini broke out of a leaky CTF environment, it got into two of three real companies with credentials from a public repository and the third by guessing a password until it worked. OpenAI's agents used developer keys from public GitHub repositories to query the US Census Bureau's data API. Harvesting leaked keys is old. What's different is that searching, extracting and logging in happen in one loop with nobody stopping to decide. The only signal available is the first use of that credential by that principal, and most environments don't record it.

Guessing that doesn't stop

People guessing passwords make typos, pause, and give up. The agent cases look like evenly spaced attempts that continue until one works. If your lockout threshold is set at a number a human would plausibly hit, detection has to sit below it. The successful login after a long run of failures is the event to alert on.

Non-human identities with no boundary

In four records, an evaluation or sandbox identity reached production systems or a real third party. Where something contained it, it was a network rule or a harness setting, never the identity. In Anthropic's Claude Opus 4.6 case, the model found a stored password, used it to get administrator access, and then changed a setting so the system would be easier to reach later.

What I'd change

Most of this points at how identities are issued and scoped more than at new detections:

Scope non-human identities at the identity provider so an evaluation or automation credential can't authenticate in production at all.
Bind API keys to a registered consumer, so there's something besides an IP address to correlate on.
Add first-seen-for-this-principal enrichment to authentication logs.
Correlate by principal across cloud, identity provider, CI/CD and SaaS logs instead of within each one.

MFA doesn't settle this either. Anthropic's report on GTG-20006 describes device-code phishing against cloud email, where the victim completes the sign-in on the attacker's behalf. The technique is old. The model's contribution was scale.

Caveats

These are public disclosures, so the set leans toward cases that vendors and labs chose to write up, and 36 is a small number. The ATT&CK mappings are mine, built from the published write-ups, and many of those leave out the mechanics. The detection rules behind each pattern are experimental and need tuning against your own environment before they alert.

I'm preparing the catalog and its detection rules for public release and will link them here when they're out.