Agent identity: non-human identities and least privilege
Every agent should log in as itself, with short-lived credentials and only the permissions its job needs. Shared human accounts and forever-keys turn every mistake into a mystery.
In 60 seconds
Agent identity: non-human identities and least privilege
Every agent should log in as itself, with short-lived credentials and only the permissions its job needs. Shared human accounts and forever-keys turn every mistake into a mystery.
Common anti-patterns
- The agent logs in with a real employee's account
- One API key shared by every agent in a team
- Keys that never expire, pasted in config files
- Admin rights "because it was easier to set up"
- No owner listed; nobody knows if it is still needed
- One identity per agent, per environment (test and production separate)
- Short-lived credentials issued at run time
- Secrets kept in a secrets manager, fetched by tool code, never shown to the model
- A role listing the exact permissions the job needs
- A named owner and an expiry or review date on every identity
Short-lived beats long-lived
- 1
Agent starts a task
The runtime, not the model, asks the identity service for a credential. - 2
Platform proves the workload
It confirms this really is agent X in environment Y. - 3
Short-lived token issued
Scoped to agent X's role. Expires soon. - 4
Tool code uses the token
The model calls a tool; the tool holds the token. The model never sees it. - 5
Token expires
Nothing to rotate by hand. A leaked copy is soon useless.
Least privilege, written down
| Agent | Needs | Does not need |
|---|---|---|
| Invoice-reading agent | Read invoices folder; write to a review queue | Pay invoices; read HR files; delete anything |
| IT helpdesk agent | Read tickets; reset passwords for non-admin users after checks | Change admin accounts; change security settings |
| Report-writing agent | Read-only access to a reporting database view | Write access to production tables |
Lifecycle: joiners, movers, leavers
- Joiner: identity created only through the approval process, with owner and role.
- Mover: when the agent's job changes, its role is reviewed; old permissions are removed, not just added to.
- Leaver: when the agent is retired or its owner leaves, the identity is disabled and credentials revoked. Orphaned agent identities are a common way in for attackers.
- Rotation: any remaining long-lived secrets (for systems that cannot issue short-lived ones) are rotated on a schedule and after any suspected leak.
Watch and read more
Lab
An identity plan for three agents: identity, permissions, credential type, owner and off-switch.
The problem
You are the identity lead. Three agents are about to go live: an invoice-reading agent, an IT helpdesk agent that can reset passwords, and a sales report agent that queries a database.
- For each agent, fill in the starter table.
- List permissions as specific actions on specific resources, not "access to finance".
- Mark which credential is short-lived and how it is issued. If you must use a static key anywhere, say how it is stored and rotated.
- For each agent, write the single action that switches it off in an emergency.
- Add one "must never" rule per agent and say where it is enforced (in code, in the identity system, or in the target app, but not only in the prompt).
agent | identity name | environment | permissions (action:resource) | credential type & lifetime | owner | off-switch | must never (enforced where?)
invoice-reader | agent-invoice-read-prod | prod | | | | |
helpdesk-agent | | | | | | |
sales-report | | | | | | |You are done when
Hard questions
Try to answer before you reveal. If you can answer these, you understood the lesson.
Q1The helpdesk agent must reset passwords, but never for administrators. Where do you enforce that, and why not in the prompt?Reveal
Enforce it in the identity system or the reset tool's code: the agent's role simply lacks permission on admin accounts, or the tool checks the target's group and refuses. A prompt rule can be talked around by a clever ticket. A permission check in code cannot be persuaded.
Q2Short-lived tokens expire in minutes, but an attacker who controls the agent's runtime can keep asking for new ones. Does short-lived still help?Reveal
Yes, but it is not enough alone. It helps against leaked copies (in logs, prompts, screenshots) and forces an attacker to stay inside the runtime. To stop an active attacker you also need to revoke the agent's ability to get new tokens (disable the identity), which is why a one-step off-switch and monitoring of token requests matter.
Questions people ask
Isn't one service account for all our agents simpler?
Simpler to set up, much harder to run. With one shared account you cannot tell which agent did what, you cannot give each agent only its own permissions, and revoking it during an incident breaks every agent at once.
What if a system only supports static API keys?
Keep the key in a secrets manager, give it the narrowest rights the system allows, let only the tool code fetch it, rotate it on a schedule, and watch its use. Put that system on the list for a better option later.
Do I need SPIFFE to do this well?
No. SPIFFE is one open standard for workload identity. Cloud platforms have their own workload identity features. What matters is the pattern: identity based on the running workload, short-lived credentials, and no copied secrets.
Should the model ever see a credential?
No. Anything in the model's context can end up in an output, a log or a URL. The model asks for an action; the tool code holds the credential and performs it.
Lesson test
5 questions. Get 3 right (60%) to pass and complete this lesson.