Securing AI Agent Identities: A Practical Guide

Agents cannot borrow accounts

The fastest way to ship an AI agent is to run it under a developer's account or a shared service account. It is also the fastest way to lose control. When an agent shares a human account, you cannot tell agent actions from human actions in logs, you cannot revoke the agent without locking out the person, and the agent inherits every entitlement the human has accumulated.

Generic service accounts are no better. They pool many workloads behind one credential, so blast radius grows silently and ownership evaporates. Overprivileged non-human identities rank among the top risks in the OWASP Non-Human Identities Top 10 (2025), and any cloud IAM review will show granted permissions far exceeding exercised ones. Agents make that surplus dangerous in a new way, because a hijacked agent spends whatever it holds. The NHI list covers the credential side; the OWASP Top 10 for Agentic Applications (2026) adds what a hijacked agent does with it: goal hijacking, memory poisoning, tool misuse, cascading failures. Read them together.

• One identity per agent deployment, not per team, per tool, or per vendor
• Agent actions must be attributable in every audit log without correlation gymnastics
• Revoking an agent must never disable a human or an unrelated workload

Make agents first class in your directory

The major identity platforms now treat agents as a distinct identity type. Microsoft Entra Agent ID, announced in 2025, gives each agent its own directory object backed by a service principal, and Conditional Access can now target agents, though as of mid-2026 it carries documented gaps and preview-labeled conditions. Okta for AI Agents, announced the same year, registers agents as first-class non-human identities in Universal Directory with a defined lifecycle from onboarding to decommissioning.

Be precise about what gets the identity. Four levels: the blueprint you build or buy, the deployed agent in one environment, the single execution or session, and the requesting human when there is one. Credentials attach at the deployment level: each independently permissioned deployment gets its own workload identity, each execution gets a session-scoped token and a correlation ID, and the blueprint stays metadata grouping deployments of a kind. Microsoft's Agent ID model draws the same lines: a reusable blueprint stamps out per-deployment agent identities.

Whatever your stack, copy the pattern: agents live in the directory, are registered at creation, carry metadata, and get retired deliberately. If your platform lacks a native agent type, model agents as dedicated workload identities with strict naming and an inventory. Two fields matter most. Every agent needs a named human owner who answers for its behavior, approves its access, and retires it. And purpose belongs in the record, written narrowly: 'summarizes support tickets from queue X' is enforceable, 'helps the support team' is not.

• Register every agent at creation time; discovery after the fact is a compensating control, not a strategy
• Record owner, purpose, platform (Claude, Copilot, Cursor, custom), environments, and the systems it touches
• Define a retirement path on day one; orphaned agents are tomorrow's improper offboarding finding

Least privilege, short-lived, per environment

Access reviews trim excess months later. It is cheaper to never grant it. Scope the agent's first grant to the minimum concrete task list from its purpose statement, and make broad scopes an explicit exception with an expiry date.

Then eliminate static keys. Secret leakage is a top OWASP NHI risk because long-lived API keys end up in code, config, and chat, and agents multiply that surface: they read and write files, call tools, and log verbosely. Issue short-lived tokens from your identity provider and use workload identity federation so nothing durable sits on disk. The Model Context Protocol points the same direction for servers that enable its optional, HTTP-transport authorization layer: the 2025-11-25 specification makes protected MCP servers OAuth 2.1 resource servers, requires PKCE, and mandates RFC 8707 resource indicators so a token is only valid for the server it was minted for. Stdio servers instead take credentials from their environment, so that discipline carries the weight. Hold internal connections to that bar even where the spec does not force you to.

Finally, separate environments. An agent identity in development must not work in production. Distinct identities per environment mean a prompt-injected dev agent cannot reach production data, and production credentials never appear in the loosely governed places where agents are built and tested.

• Grant read before write; add write per system only with owner sign-off
• Prefer resource-scoped grants (one repo, one queue, one mailbox) over org-wide roles
• Deny by default for production data stores, secrets managers, and identity admin APIs
• Target token lifetimes in minutes or hours; rotate and vault anything static you cannot yet eliminate
• Keep dev agents on synthetic or masked data, and treat any cross-environment grant as a finding

Layer detection over deterministic control

A cron job with a service account does one thing on a schedule; an AI agent plans its own steps, so the same identity can touch different systems in a different order on every run; even the cron job's profile shifts when its code changes. Deterministic controls still do the heavy lifting: allowlists, resource restrictions, egress policy, transaction limits, sandboxing, and approval gates stop whole classes of harm before execution and work on the first run. What they cannot do alone is tell a legitimate step from a hijacked one inside the envelope you granted: a prompt-injected agent uses exactly the permissions you gave it, so there is no policy violation to detect.

That gap is what behavioral baselining per agent identity covers, which is only possible once each agent has its own identity. Record what normal looks like and alert on deviation, as you would for a privileged human account. Treat it as detection and response, not a replacement for authorization: baselines miss first-run attacks, mimicry, and agents that run too rarely to profile, so the deterministic layer stays in front.

Agents also give you a runtime signal humans never do: you know the task. Log the instruction the agent was given next to the actions it takes; treat divergence as the alert condition. MCP makes this tractable because tool calls are structured requests with a name and arguments, not opaque traffic.

• Baseline tools called and typical sequences, data volume per session, outbound destinations, trigger sources, and active hours
• Compare scopes exercised against scopes granted, then trim the gap
• Assign every task a correlation ID and propagate it through each tool call and downstream request
• Treat a summarization task that emits an outbound email or file share as an incident, not an anomaly score
• Watch for hostile sequences where each call is allowed, such as a sensitive read followed by an external post

Gate the irreversible

Approval gates work only if they are rare enough that humans still read them. Tier every tool by consequence: can the action be undone, does it leave your boundary, does it change money or permissions, how sensitive is the data, how large the volume, and can it chain. Every tier still passes deterministic authorization first; the tier decides what you add on top. Judge writes by consequence, not reversibility alone: a draft PR is reversible, yet it can trigger CI and touch your supply chain. The pattern is standard practice: Anthropic's Claude for Chrome asks before high-risk actions like publishing, purchasing, or sharing personal data.

MCP's elicitation capability standardizes mid-session requests for user input, a useful channel for approvals. It is not authorization: it proves neither the approver's authority nor that approval binds to the exact payload that executes. Bind approvals to precise arguments and re-verify at execution, or an injected agent can swap arguments after approval.

• Show approvers the exact action and arguments, not a vague summary
• Cap approvals per hour so fatigue does not turn the gate into a rubber stamp

Kill switches and session records

When an agent misbehaves you need to stop it in minutes, and suspending its identity is not enough. Self-contained tokens stay valid until expiry, static credentials keep working, queued jobs keep draining, downstream sessions keep serving. A real kill switch is layered: halt execution and queued work, block new issuance, revoke issued tokens (RFC 7009) and check by introspection, terminate downstream sessions, rotate static credentials, block egress. Short-lived, audience-bound credentials bound the worst case; they are the fallback, not the mechanism. Microsoft's continuous access evaluation shows the direction: resource servers subscribe to revocation events instead of waiting out token lifetimes.

Record what the agent did, but record it safely: full prompts, tool results, and browser content routinely carry tokens, secrets, and personal data, and a naive record-everything transcript becomes a second breach. Default to structured, tamper-evident action metadata (identity, task, correlation ID, tool, argument summary, result status, destination), exclude tokens and credentials outright, redact sensitive fields, encrypt, restrict access, and set purpose-limited retention, per the OWASP Logging Cheat Sheet. Reserve governed raw capture for surfaces that earn it. Browser agents do: in Anthropic's internal red-team evaluation of Claude for Chrome (123 test cases, 29 attack scenarios, August 2025), prompt injection succeeded 23.6 percent of the time without mitigations and 11.2 percent with them. Evaluation numbers, not incident rates, but double-digit success under test demands recording, not just prevention.

• One rehearsed runbook spanning execution, queued work, token issuance and revocation, downstream sessions, static credentials, and egress
• Separate paths for killing a live session versus revoking credentials; rehearse both and measure time to full lockout, not time to ticket closed
• Capture structured action records for every tool call; keep tokens and secrets out of logs by construction
• Run browser agents in dedicated profiles, never in a human's logged-in profile, and log URLs and page actions with sensitive content redacted
• Retain records long enough to reconstruct an incident end to end, no longer than purpose justifies

Delegation, not impersonation

Every agent action is a chain: a user asks, an agent decides, a tool executes, a downstream API grants. Each hop is a place where authority can silently widen. The user asked for one calendar event; the agent holds a token that can read every mailbox. The core rule is that authority must narrow or stay equal at every hop, never widen. Any surplus privilege in the chain is what prompt injection and tool poisoning spend.

Agents act in one of two authority modes, and the chain must say which. A user-delegated agent acts on a specific person's request; its authority stays within what that user can do and what the task needs. An autonomous agent acts on standing authority from an owner-approved workload policy, with no requesting user and none fabricated. Pick one mode per deployment and encode it in the token shape.

OAuth 2.0 Token Exchange (RFC 8693, 2020) supplies the building blocks, but it is a toolkit, not a guarantee: the actor_token is optional, the act claim appears only when authorization server policy issues it, a token may name multiple audiences, and nothing downscopes automatically. Deploy a stricter profile on top: require the actor token, issue nested act claims per hop, mint one audience per token, and downscope at every exchange. Prefer delegation over impersonation: an impersonation token looks exactly like the user, so logs cannot distinguish agent from human.

Consent and delegation standards for agents are still settling. The Identity Assertion JWT Authorization Grant is an active OAuth Working Group draft that lets the enterprise IdP mediate agent-to-app connections instead of pairwise consents, the direction Okta's Cross App Access is productizing. Other proposals, including an on-behalf-of extension for AI agents, expired in early 2026 without adoption. Build on RFC 8693 semantics now; treat draft mechanics as likely to change.

Audience and context must survive every hop. A token minted for hop one must not replay at hop three, so every service validates that the aud claim names it. If the user's session was step-up authenticated or tenant-scoped, that context constrains every downstream hop. Re-mint per hop via token exchange rather than forwarding one broad token; the last hop holds the shortest-lived, narrowest token.

The payoff is auditability. Every consequential agent action should be reconstructable from logs as three facts: who asked, who acted, and with whose authority. That reconstruction works only when the issuer preserves the act chain and every service logs it. If your logs answer only one of the three, you have an attribution gap that will surface during your first agent incident.

• Map every chain in production: user, agent, orchestrator, MCP server, downstream API; flag every hop where the credential outscopes the request
• Log the full act chain from the token, not just the caller's client ID, and join it on a request ID minted at the point of human intent
• Alert on chain anomalies: a user-delegated agent acting with no upstream user, a chain longer than your architecture allows, or an audience mismatch spike
• Prohibit humans from borrowing agent credentials; it destroys attribution and is a ranked NHI risk

MCP proxies can become confused deputies

MCP concentrates the confused deputy problem most sharply in proxies. An MCP proxy server fronts a third-party API for many callers while holding one powerful downstream credential, a service account or PAT or API key. Any caller who can influence the proxy, including via injected content in tool results, can spend that credential's full authority.

The MCP security best practices (2025-11-25) are direct: token passthrough is forbidden. A server must validate that inbound tokens were issued to it, then mint its own separately scoped token for upstream calls, and proxies must obtain per-client user consent rather than reusing it across dynamically registered clients.

• Give each MCP server its own identity and least-privilege downstream credentials, never a shared admin service account
• Validate aud on every inbound token; reject tokens minted for other services
• Exchange, never forward: mint a fresh downstream token per user, per session where the downstream API supports it
• Treat community MCP servers as third-party supply chain: pin versions, review tool definitions, and isolate them from credentials they do not need

Govern the fleet

You cannot govern agents you cannot see, and most organizations already run more than they think: IDE assistants with repo access, chat agents wired to MCP servers, custom LLM services holding API keys. In Okta's AI at Work 2025 survey of 260 executives, 91 percent said their organization uses AI agents while only 10 percent have a well-developed strategy for managing non-human identities. Anchor the registry in your IdP, not a spreadsheet, so entries stay tied to live credentials: one entry, one owner, one review date per agent, recording credentials, reachable tools and MCP servers, highest data classification, and environments.

Then run the workforce lifecycle. OWASP ranks improper offboarding as the number one non-human identity risk, and agents accumulate stale access faster than other workloads because they are cheap to create and easy to forget. An agent joins with a request naming owner, purpose, and scopes. It moves when scopes change, which triggers re-approval. It leaves when its purpose ends or its owner departs, which triggers credential revocation, not just deactivation.

Publish a short allowlist of approved agent platforms and the controls each must meet; make the sanctioned path easier than the shadow path. Score every registered agent on three numbers computed from the registry and IdP logs, and set review cadence and approval bar by consequence: reach, data sensitivity, rate, and autonomy.

• Require SSO for the humans administering each agent platform; runtime agents use workload identity federation and short-lived machine credentials instead
• Bound user-delegated agents by the requesting user's permissions, autonomous agents by owner-approved workload policy
• Ban long-lived static API keys where a platform supports short-lived tokens
• Require exportable audit logs that name the agent identity, not just the vendor
• HR offboarding automatically flags every agent a departing owner held; reassign or revoke within a fixed SLA
• Recertify on a schedule tied to risk tier; quarantine unowned or unreviewed agents to read-only after dependency checks and owner escalation, with exceptions, rollback, and break-glass before any hard disable
• Run quarterly shadow-agent discovery: review IdP OAuth grants, egress to LLM APIs, and new MCP server registrations

The identity-first bottom line

Our view at Identra is simple: agents are an identity problem before they are an AI problem. Give each independently permissioned agent deployment a distinct, owned workload identity. Bind every execution and tool call to its task context. Constrain authority at every hop. Combine deterministic controls with runtime detection. Design revocation across live execution, token issuance, and downstream credentials. Teams that start there will adopt agents faster and with fewer surprises than teams that bolt monitoring onto anonymous automation, because you cannot watch, constrain, or retire what you cannot name.

Read next