An engineer ships an agent to production. It needs to call an internal API, so it uses the key already sitting in the engineer’s environment. The agent runs. It also now holds every permission that engineer holds.
That is the default state of most agent deployments today. The agent has no identity of its own, so it borrows one. Usually it borrows a human’s, through an API key. The agent works on day one, which is exactly why the problem ships to production unnoticed.
What inheritance actually costs you
Four failures follow from that single shortcut, and they compound.
You get privilege escalation. A non-human process now carries a human’s full access. It can reach every system the human can reach, whether the task needs it or not.
You get no scoping. The agent should touch a narrow slice of your systems. Instead it gets everything, because the key was never meant to express “only this.”
You get no attribution. When the agent acts, the audit log shows the human. You cannot separate what the agent did from what the person did. Incident response slows to a crawl, and so does any compliance story you have to tell later.
You get no clean revocation. To shut the agent off, you rotate the human’s key. Now you have broken the human’s own access and every other process that depended on that key. There is no off switch for the agent alone.
A knowledgeable reader will reach for the obvious fixes here. Rotate the key on a schedule. Hand the agent a service account instead. Both miss the real problem.
A passport is the wrong mental model
The instinct is to treat identity as a passport. A passport authenticates who you are and maps you to a fixed set of permissions. Show it at the border, get the access that comes with it. That model works when behavior is predictable inside those permissions. A human with read access to a dataset reads the dataset. A service account that posts to a queue posts to the queue, at the same cadence, every time.
Agents break the assumption underneath the passport. The right question is not “who is this actor.” It is “what is this actor authorized to do right now, for this task.” That is authority, not identity in the passport sense, and the difference is the whole point.
Here is why it matters. An agent is non-deterministic. Give two agents the same permissions and the same goal, and they can take different actions, because each one picks its tool chain at runtime based on its prompt, its context, and the output of whatever called it. The set of actions an agent will actually take is not knowable when you grant its permissions.
That turns design-time least privilege into a design-time answer to a runtime problem. You are deciding, in advance, what an actor may do, when the actor itself decides what to do only once it is running. A static grant cannot keep up with an actor whose behavior shifts on every interaction.
Why your IAM stack does this to you
This is not a configuration mistake. It is a structural assumption baked into identity and access management. The systems you run assume an actor is one of two things: a person, or a long-lived service account with a static permission set. Both are stable. Both do roughly the same thing every day. Your controls, your audit model, and your provisioning flows are all built on that stability.
Agents are neither. They act on behalf of people, so they are not service accounts. They are software that spins up and tears down on its own schedule, so they are not people. They sit in the gap your IAM stack does not have a category for, and the gap is where the credential gets borrowed.
The take-away
If your agents authenticate as the humans who deployed them, you have a privilege-inheritance problem in production right now. Find it before an auditor or an incident does: look for human API keys being used by non-human processes, and for audit logs where you cannot tell agent actions from human ones.
The shallow fix is to stop sharing keys. The real fix is harder. A non-deterministic actor cannot be governed by a static, design-time grant, which means the agent needs an identity built for authority that is decided at runtime, not a passport stamped once at the border.
That raises the obvious question. If the agent needs its own identity, what is that identity actually made of, and is it anything more than the workload identity you already run? That is the next post.