The identity problem: whose power is it wielding?

Lesson 1 of 5 in Agent Identity, Auth, and Secrets.

Here is how almost every agent ships its first production version. Someone creates a service account — svc-ai-automation — gives it the union of every permission any planned agent might need, drops the key in an environment variable, and moves on. It works. It demos beautifully. And it has quietly destroyed three properties your security program depends on.

It is unauditable. Six agents, forty tool integrations and one shared principal means the log line says svc-ai-automation deleted 1,204 rows. Which agent? Running which prompt version? For which user? You cannot answer, and no amount of log retention will change that — the information was never captured, because the identity was never distinct.

It is unrevokable. When one agent misbehaves at 02:00, your only lever is disabling the shared account, which stops every agent and every integration that shares it. In practice teams do not pull that lever; they wait, argue, and let the incident run. A control nobody dares use is not a control.

It is unscopable. A shared principal must hold the union of every permission its consumers need. So the low-risk summarizer agent also holds the finance agent’s write access to the ledger. Least privilege is arithmetically impossible in that design — you scoped the account, not the agent.

The two identity questions

Every agent authorization decision resolves to two independent questions, and confusing them is the single most common design error in this domain:

What may THE AGENT do? The agent is a workload with its own authority — a principal you can name, scope, monitor, rotate and revoke. This is authorization of the agent.
On WHOSE BEHALF is it acting? When the agent reads Dana’s mailbox, is that Dana’s authority being exercised, or the agent’s? This is delegation.

An agent that answers only question one becomes a superuser bot that anyone who can talk to it can aim at anyone’s data. An agent that answers only question two — by simply borrowing the user’s credentials — becomes untraceable: the audit log shows Dana doing things Dana never did. You need both answers, in every tool call.

Key terms: agent identity, service principal, workload identity, delegation, impersonation, least privilege

Shared service account vs per-agent identity — the four properties that decide incidents
Property	Shared service account	Per-agent identity	Why it decides the incident
Attribution	Every action logs as one principal. Agent, version and requesting user are lost.	Each action carries a distinct principal id, so the actor is recoverable from the log alone.	Fifteen minutes into an incident, "which agent did this" must be a query, not an investigation.
Revocation	One kill switch for all consumers. Using it causes a second outage, so it goes unused.	Disable one identity, stop one agent. Blast radius of the response matches the incident.	A kill switch you are afraid to pull is decoration. Per-agent identity makes revocation cheap.
Scoping	Must hold the union of all consumers’ permissions — permanently the widest role in the system.	Scoped to one agent’s job. The summarizer never holds the ledger write.	Union-of-permissions is how a prompt-injected low-value agent reaches high-value systems.
Rotation	Rotating the key breaks every consumer at once, so rotation gets deferred indefinitely.	Short-lived credentials issued per agent (often per session) — rotation is the normal case, not a project.	Long-lived shared secrets are the artefact most likely to be sitting in a repo, a log, or a prompt.

Sort the questions below before reading on. Some are about the agent’s own authority, some are about delegated authority, and the interesting ones need both to be true before the call is allowed — that intersection is the whole design.

Interactive sorting exercise: Each row is a check the runtime must perform before a tool call fires. Which identity question does it answer?

OWASP Top 10 for Agentic Applications (2026) — ASI03 Identity & Privilege Abuse

The OWASP Agentic Security Initiative gave this its own top-ten entry: ASI03 Identity & Privilege Abuse. The companion threat taxonomy, Agentic AI – Threats and Mitigations (v1.0, 17 February 2025; v1.1 released alongside the Top 10 on 9 December 2025), separately names Privilege Compromise, Identity Spoofing & Impersonation and Repudiation & Untraceability among its fifteen agentic threats.

Read those four names together and they describe one failure: an agent whose authority is broader than its task, indistinguishable from the humans around it, and unattributable afterwards. The shared service account produces all four at once. (The taxonomy is commonly cited with T-numbers; the numbering is not reproduced here because the source PDF is gated — use the threat names.)

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.