Every Permission You Granted Came With a Speed Limit You Never Wrote Down

Least privilege has earned its place. Every entitlement review, every quarterly recertification, every joiner mover leaver workflow runs on a premise that is correct. A person should hold the access their job requires and nothing beyond it. That practice survived twenty years of audit scrutiny because the logic underneath holds.

It is also incomplete, and the missing part is about to matter more than the part we got right.

Every permission you have ever granted contained three things. The scope, meaning what the holder can reach. The holder, meaning who they are. And a third component nobody wrote into the entitlement record, because nobody had to. The rate. How fast that access could physically be exercised.

An analyst with read access to the customer database can read customer records. She can also only read so many. She has a working day, one screen, a finite attention span and a job that involves other things. The permission described what she could see. Her humanity decided how much. That second limit was never a control you designed. It was a property of the thing you granted the permission to.

Remove the human and you remove the limit. You do not remove the permission.

Call it the throughput assumption. Every access decision your organisation has ever made carried an unwritten rate. The person holding it supplied that rate free of charge. Nobody recorded it.

What an access review actually checks

Run the review in your head. A manager receives a list. Each row names a person and an entitlement. The manager confirms that this person still needs that entitlement, or revokes it. The output is a signed attestation that scope and holder are still correctly paired.

Scope, checked. Holder, checked. Rate, never mentioned. There is no column for it. There has never been a column for it, because for two decades the rate was determined by the holder and the holder was a person.

This is why the problem does not look like a problem. Nothing in your identity governance stack is broken. The reviews run, the certifications complete, the evidence satisfies the auditor. The control is doing exactly what it was designed to do. It was designed against a population where the third variable held itself constant.

The Tuesday this shows up

A mid sized company has a reporting service account. It was created years ago so a scheduled job could pull a nightly extract from the customer database into a dashboard. Read only, one table set, no write path. It has passed every review since, and correctly so. The scope is right. The holder is a documented service account with a named owner in the platform team.

Then someone in the business builds something useful. An assistant that answers questions about customers, wired to that same account because the credentials already existed and the permission was already approved. Nobody escalated anything. Nobody requested new access. The change request, if there was one, described a new interface to existing data.

Now walk the questions in the order a practitioner actually hits them. Who owns this thing. The platform team owns the account, but they did not build the assistant. What can it reach. Exactly what it could reach yesterday, which is why nobody flagged it. How many records did it read last month. Nobody knows, because nobody has ever needed to ask that about a service account. How many could it read in an hour if the question it received happened to require that. Nobody knows that either. Would anything stop it. The database will answer as fast as it is asked.

Every one of those answers is individually defensible. The account is scoped correctly. The owner is named. The access was approved. Stack them and you have an identity that can execute a decade of an analyst's reading in an afternoon, sitting inside a control framework that has certified it as appropriate four times.

The scale of this is not hypothetical. A 2026 survey of more than 2,900 cybersecurity decision makers put the ratio of machine identities, including AI agents, to human identities at 109 to 1. That is the population your access reviews expect a person to certify, one row at a time. The fastest growing part of it is the part where the throughput assumption no longer holds.

Where the objection lands

The strongest counterargument is that this is solved and has a name. Rate limiting. Data loss prevention. Anomaly detection on query volume. Mature organisations already cap how fast a service can hit an API, already inspect what leaves the perimeter, already alert when a principal behaves unlike itself. The mechanism I have described is real, the objection goes, but the mitigations arrived before the problem did.

It is a fair objection and it is partly true, which is what makes it worth taking seriously. But look at why each of those controls exists. Rate limits are set per service to protect availability, sized so that a runaway client cannot take the database down. They are tuned to what the infrastructure can survive, not to what a single identity should be permitted to see. Data loss prevention inspects content at a boundary and asks whether this material is allowed to leave. It does not ask whether this principal should be moving material at this velocity. Behavioural analytics compares an identity to its own history. So a service account that has read aggressively since the day it was wired up has established aggression as its baseline.

None of the three was designed as an identity control, none of them appears in an entitlement record, and none of them is what the manager signs off in the review. They are real mitigations sitting in a different part of the organisation from the decision they would need to inform.

What changes when you accept it

A permission is no longer a static fact about who may reach what. It becomes a statement about who may reach what, how quickly, and within what ceiling.

An identity is no longer adequately described by its scope. It is described by its scope and its maximum sustainable rate.

An access review is no longer complete when scope and holder are confirmed. It is complete when someone can say what this identity did last quarter and what it could have done.

Here are the questions worth carrying into your own organisation this week, and none of them require a project to answer. Which of your service accounts had a human hand on the keyboard a year ago and does not now. For your ten highest scope non human identities, can anyone tell you the volume each one actually moved last quarter. If one of them were asked for a hundred times its normal work in a single hour, what in your stack would notice, and would it notice in time to matter. When an entitlement was approved, was the approver picturing a person, and does that picture still describe the holder.

Find your own shape

Organisations meet this in different places. Some find it in service accounts that outlived their original job and quietly acquired new consumers. Some find it in developer credentials that were sized for one engineer and are now the identity behind an automation that never sleeps. Some find it in a well governed agent platform where every agent is correctly scoped and no one has ever set a ceiling on any of them. Some find it in a third party integration where the throughput assumption was never theirs to make. The mechanism is the same. Where it surfaces depends on what you automated first.

The uncomfortable part is that none of this shows up as a failure. Nothing alerts. The reviews still pass. You will not discover a broken control, because the control is not broken. You will discover that a correct control was answering a question that stopped being the whole question. It kept answering it perfectly the entire time.

Start with the ten highest scope non human identities you own. Not an inventory project and not a new tool. Ten identities, and for each one a single number describing what it actually moved last quarter against what it could move. That number does not exist in most organisations today, which is precisely why it is worth having before someone else establishes it for you. Bring it to leadership and the board as what it is, a risk position you can now describe rather than a control you hope is holding.

Least privilege asked how much access is enough. Nobody thought to ask how fast.