AI Agent Identity: IAM for Non-Human Actors

June 25, 2026 · Securing AI: How AI Gets Attacked — and Defended (part 29)

▶ Watch on YouTube & subscribe to The Stack Underflow

Your autonomous agent is probably logging in as you right now. It carries your API token, inherits your OAuth scopes, and writes its actions to the audit log under your name. When it deletes a record, the log says you deleted it. When it calls an external API, the outbound credential is yours. That is not a configuration detail — it is a security architecture failure, and it is the root cause behind an entire category of agent attacks.

In January 2026, attackers who gained access to a DeFi platform’s agent infrastructure moved over 260,000 SOL tokens (roughly $28 million at the time) without any approval gate firing, because the agents held excessive, persistent, user-level permissions. The agents were trusted as humans, logged in as humans, and the blast radius of a single compromise was the entire account. Multiply that pattern across an enterprise running hundreds of agents and you have a systemic exposure that no prompt filter or output validator can fix.

The one-sentence version: An autonomous AI agent is a non-human actor — it needs its own identity, scoped to its task and short-lived enough that a stolen credential expires before an attacker can use it, because you cannot secure what you cannot attribute.

Why shared credentials are a skeleton key

The default pattern when teams first deploy agents is to hand the agent a long-lived API key or a service account that belongs to a human. It is the path of least resistance: the human already has access, the agent needs access, reusing the credential gets the job done in an afternoon.

The problem is that a shared, over-broad credential does not just give the agent what it needs — it gives the agent everything the human can reach. Call that scope="*". When multiple agents share a single credential, a compromise of any one of them is a compromise of all of them simultaneously.

BEFORE (skeleton key pattern)
─────────────────────────────

  [AGENT A]──┐
  [AGENT B]──┼──► agent_token: identity=human_alice · scope=* ──► EVERYTHING
  [AGENT C]──┘

  One credential stolen → attacker IS human_alice, reaches everything
  Log says: actor=human_alice for every agent action
  Attribution gap: which agent did what? Unknown.

Identity and Privilege Abuse is the OWASP Agentic Top 10 2026 entry (ASI03:2026) that names this pattern. It occurs when delegated authority, ambiguous agent identity, or trust assumptions across agents lead to unauthorized actions. The OWASP GenAI Security Project released the full list in December 2025; ASI03 sits third, behind Agent Goal Hijack and Tool Misuse.

The attribution gap is the most insidious part. If every agent in your fleet logs its actions as actor=human_alice, you cannot investigate an incident, you cannot scope a breach, and you cannot prove to an auditor which agent touched which resource. The log is useless for containment.

The four-layer attack flow

Here is the shape of an Identity and Privilege Abuse attack. The target is obviously fake (attacker.example) — the point is the mechanism, not a recipe.

ATTACK FLOW — shared/over-broad credential
───────────────────────────────────────────

Step 1  Attacker observes or steals the shared agent token
        (via prompt injection, memory leak, or supply-chain compromise)

Step 2  Token carries scope=* and identity=human_alice

Step 3  Attacker authenticates as human_alice

Step 4  Reaches: databases · secrets vault · payment APIs · admin panel

Step 5  Exfiltrates or destroys — log still says actor=human_alice

Step 6  Forensics team investigates human_alice — wrong trail
        ☠  "ONE KEY, EVERYTHING"

Notice that steps 3 through 6 require zero sophistication once the token is in hand. The attacker does not need to understand how the agent works. They are not attacking the LLM — they are attacking a credentials problem that would look exactly the same in a traditional service-account misconfiguration.

This is also why the earlier guardrails in this series — excessive agency controls, memory poisoning defenses, tool-misuse gates — all depend on identity to be enforceable. You cannot scope an agent’s tool access if the agent has no identity of its own to scope against.

The four IAM defenses that close the gap

Each defense maps to a Zero Trust principle from NIST SP 800-207 (Zero Trust Architecture), extended to non-human actors. In February 2026, NIST’s NCCoE published a concept paper — “Accelerating the Adoption of Software and AI Agent Identity and Authorization” — proposing a formal demonstration project applying SP 800-207, MCP, and Next-Generation Access Control (NGAC) to agentic architectures. The direction is clear: agents are principals, and they need the same identity hygiene as any other principal.

AFTER (per-agent identity, defended)
─────────────────────────────────────

  [AGENT A] ──► identity=agent_A · scope=read-tickets  · ttl=15m
  [AGENT B] ──► identity=agent_B · scope=send-summaries · ttl=15m
  [AGENT C] ──► identity=agent_C · scope=query-reports  · ttl=15m

  One credential stolen → attacker is agent_A, reaches only read-tickets,
  for at most 15 minutes, and the log says actor=agent_A
  ✓  "NARROW, EXPIRED, ATTRIBUTED"

Defense 1 — Per-agent identity (every agent is its own principal)

Every agent gets its own identity — a distinct principal that is not a human and is not shared with any other agent. In OAuth 2.0 terms, this means a separate client ID and client secret per agent role, not per deployment. In AWS terms, it means a distinct IAM role. In Kubernetes, a distinct service account.

The agent’s identity must be separate from any human identity. When agent_A calls an API, the outbound credential identifies agent_A, not human_alice. This is the prerequisite that makes every subsequent defense possible.

Defense 2 — Least-privilege scopes (the identity reaches only its one job)

Once each agent has its own identity, scope it tightly to the minimum permissions required for its specific task.

A scope of read:tickets cannot reach the secrets vault, cannot call payment APIs, and cannot delete records — even if the credential is stolen. This directly limits blast radius. It is also what makes the excessive-agency and tool-misuse guardrails from earlier in this series operational: you cannot enforce tool-level scoping unless the identity running the tool is attributable and constrained.

Defense 3 — Short-lived credentials (a stolen token expires fast)

Long-lived API keys are standing attack surface. Replace them with short-lived tokens — 15 minutes is a reasonable starting point for most agent tasks — issued at runtime via a credential broker and rotated automatically.

Credential lifecycle (short-lived pattern)
──────────────────────────────────────────

Task starts  → broker issues token for agent_A · scope=read-tickets · ttl=15m
Task runs    → agent uses token; token is valid
Task ends    → token expires naturally; no cleanup required
Token stolen → attacker has a token that expires in minutes, not months
               Blast radius is bounded by time as well as scope

The Zero Trust principle here is “fail closed” (NIST SP 800-207 principle 4 in the series framework): if a token is missing, expired, or out of scope, the default answer is deny, not permit.

Defense 4 — Auditability (every action is attributable to a named identity)

With per-agent identities in place, the log now tells the truth. Compare these two log lines:

BEFORE:  action=delete_records · actor=human_alice · result=success
AFTER:   action=delete_records · actor=agent_A · scope=read-tickets → DENIED

The “after” line does three things at once: it names the agent, it surfaces the scope violation (the agent tried to delete with a read-only scope), and it records a deny event you can alert on. This is “log everything” — Zero Trust principle 3 — made literal for non-human actors.

A structured log schema for agent actions should capture at minimum: agent identity, requested action, granted scope, resource identifier, decision (allow/deny), and timestamp. That is your incident-response trail.

How to defend: the layered checklist

DEFENSE STACK — agent IAM
─────────────────────────
Layer 1  Per-agent identity
         □ Every agent has its own principal (not a human, not shared)
         □ Separate client ID / IAM role / service account per agent role

Layer 2  Least-privilege scopes
         □ Enumerate minimum required permissions per agent task
         □ Default deny; add only what is needed
         □ Re-audit scopes when agent tasks change

Layer 3  Short-lived credentials
         □ No standing API keys for agents
         □ Token TTL is 15 minutes or less for interactive tasks
         □ Credential broker issues tokens at task start

Layer 4  Auditability
         □ Every agent action logged with: identity · scope · action · result
         □ Scope violations alert in real time
         □ Audit log is immutable and agent-accessible only for writes, not reads

Cross-cutting
         □ Agents never inherit user identity
         □ Cross-agent delegation is explicit, scoped, and logged
         □ Rotate agent credentials on a schedule independent of human rotation

On the framework side: OWASP ASI03:2026 recommends OAuth 2.0 with short-lived tokens, task-scoped permissions, and policy-enforced authorization on every action. NIST SP 800-207 extends zero trust to non-human actors with the same three core principles: verify explicitly, enforce least privilege, assume breach.

Common misconceptions

• “A service account with a long-lived key is fine — that is how microservices work.” Traditional microservices are long-running processes with stable, predictable behavior. Agents are LLM-driven, can be injected with adversarial instructions, and their tool calls are not deterministic. A long-lived service-account key for an agent is a persistent skeleton key waiting to be exfiltrated via prompt injection or memory leakage.

• “If I rotate keys on a schedule, I am covered.” Scheduled rotation reduces the standing window, but it does not scope the credential to a specific task. A rotated key that still carries scope=* is still a skeleton key — just a fresher one. Rotation and least-privilege are separate controls; you need both.

• “Per-agent identity is too much overhead for a small team.” The overhead is a one-time architecture decision. Every major cloud IAM system (AWS, GCP, Azure, Okta) supports programmatic issuance of short-lived, scoped credentials. The operational cost is a credential-broker call at task start. The operational cost of a breach — forensics, incident response, customer notification — is orders of magnitude higher.

• “My agents only call internal APIs, so credential theft is not a realistic threat.” Prompt injection, memory poisoning, and supply-chain attacks (all covered in earlier tutorials in this series) are precisely the mechanisms that expose internal agent credentials without any external attacker ever touching your perimeter. The attack surface is the agent itself.

Frequently asked questions

What is the difference between a service account and a per-agent identity? A service account is a long-lived identity typically tied to an application or system process — it usually has broad, persistent permissions and is managed by a human administrator. A per-agent identity is scoped specifically to the task the agent performs, issued with a short TTL, and ideally created programmatically at runtime by a credential broker. The key distinctions are scope (narrow vs. broad) and lifespan (minutes vs. months). Agents should use per-agent identities, not repurposed service accounts.

What does OWASP ASI03:2026 say concretely about mitigations? The OWASP Top 10 for Agentic Applications 2026 entry for Identity and Privilege Abuse (ASI03:2026) recommends: short-lived credentials, task-scoped permissions, policy-enforced authorization on every action, isolated identities for agents (never shared with users or other agents), and audit logging of every privileged action. It explicitly calls out confused-deputy scenarios — where a low-privilege request tricks a high-privilege agent into acting on its behalf — as a primary attack pattern to defend against.

How does cross-agent delegation work safely in multi-agent systems? When Agent A needs to delegate a task to Agent B, the delegation should be explicit (Agent A explicitly passes a limited capability to Agent B, not its own full credential), scoped (Agent B’s derived token covers only the sub-task, not Agent A’s full scope), and logged (the delegation chain is recorded so forensics can reconstruct what happened). OAuth 2.0 token exchange (RFC 8693) provides a standard mechanism for this. The tutorial on multi-agent failure modes covers the trust-escalation patterns that make unscoped delegation dangerous.

Does this apply to agents running locally, not just cloud deployments? Yes. A locally-running agent that authenticates to any external service — a database, an API, a secrets vault — has credentials that can be extracted from memory, from logs, or via prompt injection into the agent’s context. The risk profile is the same; only the attack surface shape differs. Local agents should use the same short-lived, task-scoped credential pattern, issued via a local credential broker (such as a Vault agent sidecar or a platform-native secrets manager).

How do I audit agent actions if the agent runs hundreds of sub-tasks per second? The answer is structured, machine-readable logs rather than human-readable text logs. Each log entry should be a JSON object with a fixed schema (identity, action, scope, resource, result, timestamp) written to an append-only store that the agent cannot modify. Your SIEM ingests this stream and alerts on anomalies — scope violations, unusual action frequencies, cross-agent delegation chains that exceed a defined depth. High-volume audit is an infrastructure problem, not a reason to skip logging.

Where this fits in the series

This tutorial is the closing episode of the agentic AI security playlist. It sits on top of everything that came before: excessive agency, agent memory poisoning, tool misuse, and multi-agent failure modes all assume that agents are distinct, attributable identities — this tutorial explains why that assumption must be engineered, not hoped for. The guardrails are only enforceable when you can name what you are gating.

The next playlist opens with Zero Trust for AI, which scales these same principles — verify explicitly, least privilege, assume breach — from a single agent to an entire system. If this tutorial answered “how do I identity-harden one agent?”, the next answers “how do I run a hundred of them safely?” The foundational mental model for all of it lives at The AI Attack Surface Explained. Browse all tutorials to follow the full series.