When a thousand agents act as one, your identity model has already failed

Recent reporting describes swarms of more than a thousand autonomous agents operating against live infrastructure during security testing, in some accounts undetected for weeks. The detail that should concern anyone running an authorisation system is not the scale. It is the duration.

Identity systems assume a bounded principal

Every access-control model in production today resolves a request to a principal — a user, a service account, a workload identity — and evaluates permissions against it. The model works because principals are stable, enumerable, and roughly correspond to something in the world that has intent.

A swarm breaks all three properties. It is ephemeral, it is not enumerable in advance, and intent lives in an orchestration layer that never itself authenticates to anything. From the target's perspective, one thousand agents holding one service identity are indistinguishable from one very busy client.

Rate limits and anomaly detection are tuned to the behaviour of a principal. A swarm is not one, and does not look like one.

Why weeks, not hours

Detection windows collapse when behaviour is anomalous. Swarm traffic frequently is not. Each individual request is well-formed, correctly authorised, and within rate limits. The anomaly exists only in aggregate — in the coordination pattern across principals — and almost nothing in a standard stack computes over that dimension.

The comparison worth making is to credential-stuffing detection, which took the industry a decade to get right for exactly the same reason: individually legitimate requests, collectively obvious. The difference is that agent traffic is legitimately authorised, so the credential-based signals that eventually solved stuffing do not apply.

The delegation chain is the missing primitive

What is absent from every mainstream identity system is a first-class representation of delegated, attenuated authority: this request is made by agent A, acting for orchestrator B, on behalf of human C, with a permission set strictly narrower than C's, expiring at T.

Pieces exist. Token exchange and macaroon-style attenuation solve parts of it. What does not exist is an enforcement point that reasons about the whole chain, or a logging format that records it, which means post-incident you cannot answer the only question that matters: on whose authority did this happen?

What is available now

Pending better primitives, three things are worth doing. Issue per-agent identities rather than sharing a service account across a fleet — it costs more to operate and it is the only way aggregate behaviour becomes attributable. Attenuate on delegation so that an agent spawning a sub-agent can only ever hand over a subset of what it holds. And alert on population statistics, not per-principal thresholds: the count of distinct agent identities active against a system, and how fast that count is changing, is a better signal than anything computed per request.

None of that is novel security engineering. It is the same lesson from service-to-service authorisation, arriving again in a setting where the number of principals is no longer something a human sets.

Written by the Devence Lab research team.