The 80:1 problem: machine identity is now the perimeter
For every human on your team there are roughly eighty machine identities acting on their behalf. Almost none of them have an owner. That ratio is the whole security problem.
The number nobody counts
Count the humans with access to your production systems. Now count the service accounts, API keys, agents and workers that act on their behalf. In most companies we survey the second number is around eighty times the first. Every one of them can read data, move money or call another system.
The humans are governed. They have managers, offboarding, quarterly access reviews. The eighty machines per human are governed by a spreadsheet, a shared secret in an environment variable, and the memory of whoever created them. When that person leaves, the identity keeps working.
Agents change the slope, not just the count
Static service accounts were already a problem. Agents make it worse because they act on their own initiative. A single agent can spawn tasks, request new scopes and reach systems its author never anticipated — all inside one afternoon.
The old answer was to give the agent a broad, long-lived key so it would not get stuck. That is exactly the wrong instinct. Breadth plus longevity is standing risk, and standing risk is what attackers buy on the open market.
Treat identity as the perimeter
There is no network edge to defend when your workload is a fleet of agents calling SaaS APIs. The only durable boundary is identity: who is this actor, who sponsors it, and what is it allowed to do right now.
Get that right and the eighty-to-one ratio stops being frightening. Each machine has a distinct identity, a named human sponsor, and credentials scoped to the task in front of it. The count still climbs. The blast radius does not.
- #non-human identity
- #perimeter
- #least privilege
More field notes
Revocation in 4.2 seconds: anatomy of a containment
We measured the path from anomaly to full revocation across every system an agent could reach. This is where the seconds go, and why they matter.
Daniel Osei · Security Engineer
8 min read