Agent Identity & Authentication, Explained From Zero

Every topic has circled one idea: agents act. The instant something acts, the system on the other end asks what it always asks of humans — who are you, and are you allowed? An agent is a new kind of actor, and answering those two questions for it is the whole of this topic. Get them wrong and the careful permissions from the last few topics quietly stop meaning anything.

1 · Who is the agent, really?

The instant an agent sends an email, moves money, or reads a record, the system on the other end has to answer a question it always asks of humans: who are you, and are you allowed to do this? For a person, we solved that with logins, passwords, and permissions. But an agent is a new kind of actor — not quite a human, not quite a traditional program, running around taking actions on other people’s behalf. So we must answer two entwined questions for it. Who is this agent — its own identity? And on whose behalf is it acting right now? Get those wrong, and every access control you built quietly stops meaning anything.

2 · An agent needs its own identity

The first principle is simple to say and constantly violated: an agent should have its own identity, distinct from any human’s. The tempting shortcut is to let the agent log in as a person — reuse an employee’s account, borrow an admin’s credentials — because it is fast and it works. But when the agent wears a human’s badge, three bad things follow. You cannot tell the agent’s actions apart from that person’s in any log. The agent inherits all of that human’s power, usually far more than it needs. And if the credential leaks, both the human and the agent are compromised at once. Giving the agent its own distinct identity is the foundation everything else rests on — the difference between a named employee and an anonymous stranger in a borrowed uniform.

3 · Authentication: proving it’s really it

Having an identity is only half of it; the agent must also be able to prove it is that identity — that is authentication. For people we use passwords and a second factor from a phone. Agents are different: they act constantly and automatically, so they cannot type a password or tap a prompt. Instead they authenticate with a strong secret the system issues them — think of it as a cryptographic key or a signed token that only the genuine agent holds, and that it presents each time it acts. The crucial properties: this secret should be unique to the agent, kept somewhere only the agent can reach, and ideally short-lived, so it expires quickly and a stolen one becomes worthless fast. Weak or shared secrets are exactly how attackers impersonate an agent — and an impersonated agent is an attacker wearing all of its power.

4 · The confused deputy

Here is the classic trap that makes agent identity so subtle — security people call it the confused deputy. A deputy is someone who acts with borrowed authority. Picture a powerful agent that holds broad permissions and is eager to help whoever asks. A low-privileged, sneaky requester — or an injected instruction — asks the agent to do something that requester could never do themselves. The agent, not carefully checking on whose behalf it is acting, performs the action using its own high privilege. The requester could not reach the vault, but the agent could, so the agent opened it for them. The agent was not hacked; it was confused about whose authority it should be using. This is why “on whose behalf?” matters as much as “who are you?”

5 · Acting on behalf of a user

The cure for the confused deputy is delegation done properly: when the agent acts for a specific user, it should act with that user’s permissions, not its own broad ones. If Alice asks the agent to fetch her orders, the agent should carry Alice’s limited authority for that task, so it can reach only Alice’s data — even though the agent, in general, might be capable of far more. Modern identity systems support this with what is often called on-behalf-of or delegated tokens: the agent receives a scoped, temporary credential that says “acting for Alice, limited to what Alice can do.” Then, when a sneaky request tries to reach someone else’s data, the borrowed authority simply does not stretch that far, and the action fails safely.

6 · Why shared, broad keys hurt

Name the anti-pattern directly, because it is everywhere. The worst possible setup is a single, broad, never-expiring key that everything shares. Broad, so it can do far more than any one task needs. Shared, so many agents and services all use the same one and you can never tell who did anything. And eternal, so it stays valid forever — meaning the day it leaks, and secrets do leak, the attacker gets full access that never times out. Each trait multiplies the others’ damage. It is the identity equivalent of one master key that opens every door in the city, that a hundred people carry copies of, and that no locksmith can ever change. Every good practice here breaks that combination apart: make keys narrow, individual, and expiring.

7 · Defense: named, scoped, short-lived

Pull it together into four habits. Give every agent its own distinct identity, never a borrowed human login — so you always know who acted. Have it act on behalf of the requesting user, carrying that user’s scoped permissions, which defuses the confused deputy. Use short-lived, narrowly scoped tokens instead of broad eternal keys — each credential limited to a small set of actions and expiring quickly, so a leak is contained and self-healing. And log every action against the agent’s identity, so you have a complete audit trail of who did what, for whom, and when. This dovetails with excessive agency: identity decides who an agent is, least privilege decides what it may do, and together they box even a tricked agent into a small, traceable corner.

8 · A simple test you can run this week

9 · Glossary — every term, spelled out

Identity

Who an actor is in a system. An agent should have its own, distinct from any human’s.

Authentication

Proving you are who you claim to be — for an agent, presenting a strong, ideally short-lived secret.

Confused deputy

A trusted, powerful actor tricked into using its own authority to do something the requester could not.

On-behalf-of (delegated) token

A scoped, temporary credential letting an agent act with a specific user’s permissions, not its own broad ones.

Short-lived credential

A secret that expires quickly, so a stolen one soon becomes useless.

Audit trail

A log of who did what, for whom, and when — possible only when each agent has its own identity.