Top 10 Agent Identity Controls for AI Agents

Most AI agent incidents so far trace back to an identity decision: an agent running on someone's personal token, a static key found in a file, or permissions far wider than the task. The Top 10 Agentic AI Identity Issues names the problems; this guide is its counterpart and sets out the ten controls that close them, in the order most organisations can implement them. For each control it gives the mechanism (standards, token types, platform features), how to test it, and how to show an auditor it works. It is written for IAM, platform security and AI engineering teams who are moving agents from pilots into production and need a concrete control set rather than principles.

Key takeaways

Identity before guardrails. Prompt filters reduce how often an agent is manipulated; identity controls decide how much damage a manipulated agent can do. Build the second first.
One agent, one identity, one owner. Every agent needs its own non-human identity with a named accountable human, never a borrowed user account or a shared service account.
Short-lived, audience-bound credentials. Workload-issued tokens scoped to one resource (RFC 8707 resource indicators, audience validation) replace static API keys wherever the platform allows.
Delegation must stay visible. When an agent acts for a user, the token should carry both parties, as OAuth 2.0 Token Exchange (RFC 8693) does with the act claim, so logs show who asked and what acted.
You must be able to stop it. A tested path to revoke an agent's credentials and sessions in minutes is a control, not an afterthought.

The ten controls at a glance

#	Control	Closes issue (Top 10 issues list)	OWASP Agentic 2026	OWASP NHI 2025
1	Inventory every agent with an accountable owner	4. No inventory, no owner	ASI10	NHI1
2	A distinct identity per agent	1. Human credentials; 2. Shared credentials	ASI03	NHI10, NHI2
3	Platform-issued, short-lived credentials	2. Shared and static credentials	ASI03	NHI2, NHI7, NHI9
4	Secrets kept out of code, prompts and context	2. Shared and static credentials	ASI03, ASI06	NHI2
5	Task-scoped least privilege and just-in-time access	3. Over-privileged agents	ASI02, ASI03	NHI5
6	Attributable delegation	5. Delegation without attribution	ASI03	-
7	Audience-bound tokens for tools and MCP servers	7. Uncontrolled tools and MCP servers	ASI02, ASI04	NHI3
8	Policy enforcement and approval outside the model	6. Guardrails instead of access controls; 8. Untrusted input meeting privileged action	ASI01, ASI02, ASI09	-
9	Authenticated agent-to-agent trust and identity-aware monitoring	9. Unverified agent-to-agent trust	ASI07, ASI08	NHI4
10	Revocation, kill switch and offboarding	10. No way to stop an agent	ASI08, ASI10	NHI1

OWASP names used here: ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI06 Memory and Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation, ASI10 Rogue Agents. See the OWASP Agentic Top 10 ASI03 Guide for the identity entry in depth.

Foundation controls: know, name and separate every agent

Control 1: Inventory every agent with an accountable owner

What it is: a register of every agent, including low-code and SaaS-embedded agents, with its owner, purpose, model, platform, the identities it uses, the tools and data it can reach, and its autonomy level.
How to implement: pull from the sources that already know: agent platform consoles, cloud IAM (service principals, roles, workload identities), the IdP's app registrations and OAuth grants, secrets managers and API gateway keys. Reconcile them into one record per agent. Make registration a deployment gate so nothing reaches production unregistered.
Test: pick ten credentials from cloud logs that called a model or tool API last week and trace each to a registered agent and owner. Anything you cannot trace is shadow agency. See the Know Your Agent (KYA) Guide.

Control 2: A distinct identity per agent

What it is: each agent, and where practical each agent instance or environment, authenticates as itself. No personal access tokens, no user sessions, no shared "ai-service" account across agents.
Mechanisms: agent identity objects where the platform provides them (for example Microsoft Entra Agent ID, AWS Bedrock AgentCore Identity, Google agent identities), cloud workload identities, or SPIFFE IDs of the form spiffe://<trust domain>/<workload identifier>. Separate trust domains or identities for staging and production.
Test: query sign-in and API logs for agent traffic authenticated as human users (user agent strings, automation frequency, off-hours volume). Every hit is a migration task. See the Cloud Agent Identity Services Compared (Entra, AgentCore, Google).

Control 3: Platform-issued, short-lived credentials

What it is: the runtime proves the agent's identity and receives a credential that expires in minutes or hours, rotated automatically, instead of a long-lived key pasted into configuration.
Mechanisms: cloud workload identity federation, managed identities, IAM roles for the runtime, X.509-SVIDs from a SPIFFE Workload API (SPIFFE recommends X.509-SVIDs where possible because JWT-SVIDs are more exposed to replay), OAuth client credentials with private key JWT or mTLS rather than shared secrets.
Test: report every agent credential by type and maximum lifetime. Static API keys that remain should have a documented reason (the provider supports nothing else) and a rotation interval. See the Dynamic Secrets and Ephemeral Credentials Guide.

Credential and access controls: limit what a credential can do

Control 4: Secrets kept out of code, prompts and context

What it is: agents never see raw long-lived secrets. A broker or vault injects credentials at the tool boundary, so the model's context window, memory and logs contain no key it could repeat or be tricked into disclosing.
How to implement: secret scanning on agent repositories and prompt templates; vault-backed tool connectors; output redaction for key patterns; a rule that support tickets and conversation stores never hold credentials.
Why it matters: an agent that reads files will find credentials in files (ATT&CK T1552.001 Credentials In Files is the attacker version of the same behaviour). See the Credential Vaulting for AI Agents Guide.

Control 5: Task-scoped least privilege and just-in-time access

What it is: permissions sized to the task the agent performs, not the system it touches, with write and delete rights granted only for the duration of an approved task.
How to implement: start from read-only roles; split read and write tools into separate identities; use resource-level conditions (one bucket, one repository, one workspace); grant elevated scopes through a just-in-time request that expires; deny destructive API actions by default with explicit allow per agent.
Test: compare granted permissions with permissions used over 30 days (cloud access analysers do this) and remove the unused. See the AI Agent Authorisation Guide.

Control 6: Attributable delegation

What it is: when an agent acts for a user, the access token identifies both the user (subject) and the agent (actor), and the agent can never hold more than the user could.
Mechanisms: OAuth 2.0 Token Exchange (RFC 8693), grant type urn:ietf:params:oauth:grant-type:token-exchange, with a subject_token for the user and an actor_token for the agent. RFC 8693 distinguishes delegation, where the actor keeps its own identity, from impersonation, where it is indistinguishable from the subject; choose delegation. The act claim names the current actor, nested act claims record a chain, and may_act lets the authorisation server check that this agent may act for this user.
Test: pick an agent action in a downstream log and confirm you can name the requesting user and the acting agent from the log alone. See the OAuth Token Exchange and Delegation Guide and Delegation Chains and Attenuated Authority for AI Agents.

Tool and action controls: bind tokens to targets, decide outside the model

Control 7: Audience-bound tokens for tools and MCP servers

What it is: a token issued for one tool or MCP server works only there, and no server forwards a client's token downstream.
Mechanisms: the MCP authorisation specification (version 2025-06-18) makes the MCP server an OAuth 2.1 resource server; servers MUST publish OAuth 2.0 Protected Resource Metadata (RFC 9728); clients MUST send the resource parameter (RFC 8707) in authorisation and token requests; servers MUST validate that tokens were issued for them and MUST NOT pass through the client's token to upstream APIs; clients MUST use PKCE. Tool allowlists and pinned server versions sit alongside.
Test: replay a token issued for MCP server A against server B; it must fail with 401. See the MCP Security Guide.

Control 8: Policy enforcement and approval outside the model

What it is: the decision to perform a high-impact action (delete, pay, send externally, change access) is made by a policy engine or a human, not by the model's own judgement, and the agent cannot bypass it.
How to implement: classify tools by impact; route high-impact calls through a policy decision point that checks agent identity, delegated user, resource, amount and context; require human approval above thresholds with the full proposed action shown; enforce spending and rate limits per agent identity.
Why identity: when untrusted content (email, web pages, tickets) manipulates the agent, this is the control that keeps the outcome inside policy. See the AI Agent Action Approvals and Spending Limits Guide.

Runtime controls: trust between agents, monitoring and the off switch

Control 9: Authenticated agent-to-agent trust and identity-aware monitoring

What it is: agents authenticate each other cryptographically (mTLS with workload certificates, signed tokens) and authorise each request, rather than trusting any message that arrives on an internal channel. Every action is logged with agent identity, delegated user, tool, resource and outcome.
Detection: baseline each agent's normal tools, resources, volumes and hours; alert on new tools, new resource types, permission errors, token use from unexpected networks (ATT&CK T1550.001 Application Access Token and T1528 Steal Application Access Token describe the attacker patterns), and bursts of destructive calls. See the Agent-to-Agent Authentication Guide and the AI Agent Behaviour Baselining and Anomaly Detection Guide.

Control 10: Revocation, kill switch and offboarding

What it is: a tested procedure to disable an agent's identity, revoke its tokens and refresh tokens, end its sessions and stop its runtime, plus a lifecycle that removes agents and their credentials when the project ends or the owner leaves.
How to implement: one disable action per agent identity at the IdP or platform; short token lifetimes so revocation takes effect quickly even where tokens are not introspected; owner departure triggers review in the joiner-mover-leaver process; quarterly drill with a timed target. See the AI Agent Kill Switch and Containment Guide.

Implementation roadmap

Weeks 1 to 4, discover: build the inventory (control 1) from platform, cloud IAM, IdP and secrets data; tag each agent with owner and impact level. Do not change access yet; measure.
Weeks 3 to 8, separate: issue distinct identities (control 2) to the highest-impact agents first; move them off human tokens and shared accounts. Run old and new credentials in parallel for one release, then disable the old one. Rollback: re-enable the old credential for a fixed window, never permanently.
Weeks 6 to 12, shorten and vault: replace static keys with workload-issued credentials (control 3) and move remaining secrets behind a broker (control 4). Pilot on one agent platform, then extend.
Weeks 8 to 16, reduce: right-size permissions using 30 days of usage data (control 5). Apply in audit or report-only mode first where the platform offers it, then enforce. Keep a documented exception path.
Weeks 12 to 20, bind and gate: introduce token exchange for user-delegated agents (control 6), audience validation on MCP and tool servers (control 7), and policy approval for destructive actions (control 8). Test with red-team prompts that try to trigger high-impact tools.
Ongoing, watch and stop: ship agent identity logs to the SIEM (control 9) and run a kill switch drill each quarter (control 10).

Decision guidance

Situation	Preferred credential pattern	Acceptable fallback	Avoid
Agent runs in your cloud and calls your cloud APIs	Workload identity or managed identity, role per agent	Role shared by agents of one purpose in one environment	Access keys in environment variables
Agent acts for a signed-in user on SaaS data	OAuth delegated token via token exchange, user-bound, short-lived	Per-user OAuth grant with narrow scopes	Admin-consented tenant-wide token
Agent calls a third-party model or SaaS API that only offers keys	Key in a vault, injected by a broker, scoped per agent, rotated	Per-agent key with spend limits	One organisation key shared by all agents
Agent calls internal MCP servers	OAuth with RFC 8707 resource indicator and audience validation	mTLS between agent runtime and server	Static bearer tokens in client configs
Agent talks to other agents	mTLS with workload certificates plus per-request authorisation	Signed JWTs with audience and short expiry	Network location as trust

Small organisations: use the agent platform's native identity and the cloud provider's workload identity; they deliver controls 2, 3 and much of 10 with little build. Focus effort on controls 1, 5 and 8.
Large organisations: agents span several platforms, so the inventory and lifecycle (controls 1 and 10) belong in identity governance alongside other NHIs, and delegation (control 6) needs a central authorisation server policy. See the Identity Governance for AI Agents Guide.
Trade-off: per-instance identities give the best attribution but multiply objects to govern; per-agent, per-environment identities are the usual compromise.

Measuring the controls

Coverage: percentage of production agents in the inventory with a named owner (target 100%).
Separation: number of agents authenticating with human or shared credentials (target zero, trending down weekly).
Credential quality: percentage of agent credentials that are short-lived and platform-issued; median age of remaining static keys.
Privilege: ratio of permissions used to permissions granted per agent over 30 days.
Attribution: percentage of agent actions in downstream logs that name both the agent and the delegating user.
Containment: time from decision to full revocation in the last kill switch drill.

Log sources: IdP sign-in and token issuance logs, cloud control plane logs, agent platform invocation and tool call logs, MCP server access logs and the policy engine's decision log. Retain them long enough to reconstruct a delegation chain after an incident. See the AI Agent Audit Trails for Regulators Guide.

Framework mapping

Control	NIST SP 800-53 Rev. 5	NIST CSF 2.0
1. Inventory and owner	AC-2 Account Management, IA-4 Identifier Management	GV.RR, PR.AA-01
2. Distinct identity	IA-4, IA-9 Service Identification and Authentication	PR.AA-01
3 and 4. Short-lived credentials, secrets handling	IA-5 Authenticator Management	PR.AA-01
5. Least privilege	AC-6 Least Privilege, AC-3 Access Enforcement	PR.AA-05
6. Attributable delegation	AU-10 Non-repudiation, AC-3	PR.AA-05
7 and 8. Bound tokens, policy enforcement	AC-3, AC-6	PR.AA-05
9. Monitoring	AU-2 Event Logging, AC-2(12) Account Monitoring for Atypical Usage, AC-6(9) Log Use of Privileged Functions, SI-4 System Monitoring	DE.CM-03
10. Revocation and offboarding	AC-2	PR.AA-01

NIST's NCCoE is also exploring this area through its concept paper "Accelerating the Adoption of Software and AI Agent Identity and Authorization", which was soliciting comments when checked in October 2026.

Common failure patterns

Inventory from one source only: the agent platform lists its agents, but the agents built in notebooks, CI jobs and SaaS low-code tools never appear, and they hold the broadest keys.
A "temporary" human token that becomes permanent: a developer's personal access token wires up the pilot and is still in place a year later, after the developer has moved teams.
Least privilege on paper: the agent's own role is narrow, but a broad token sits in a file or environment it can read, and the agent uses whatever works.
Delegation flattened into impersonation: the agent receives the user's own token, so logs show the user doing everything and there is no way to separate agent actions.
Approval prompts that approve themselves: "always allow" settings or approvals routed back to the same agent session turn control 8 into a formality.
Revocation never rehearsed: disabling the agent identity leaves refresh tokens, third-party grants and running containers alive.

Lessons from incidents

Scope and placement of tokens: in the PocketOS incident, a coding agent hit a credential mismatch on a staging task, found an account-scoped API token in an unrelated file and deleted a production volume and its backups in one call. Controls 4, 5 and 8 each would have broken the chain.
The key is the identity: the Moltbook database exposure left about 1.5 million agent API tokens readable, so anyone holding one could act as that agent. Controls 1, 3 and 10 limit both the value and the lifetime of such keys.
Integration tokens concentrate risk: in the Salesloft Drift breach, stolen OAuth tokens held by one chatbot integration opened hundreds of Salesforce tenants. Narrow scopes, inventory of third-party grants and fast revocation (controls 5, 1 and 10) are the defence.

Practitioner checklist

Build one agent inventory from platform, cloud IAM, IdP and secrets data, with an owner for each entry.
Make registration a deployment gate for production agents.
Move every agent off human and shared credentials onto its own identity.
Replace static keys with workload-issued, short-lived credentials; vault and broker what remains.
Right-size agent permissions from 30 days of usage and deny destructive actions by default.
Use token exchange with the act claim for user-delegated agents.
Require RFC 8707 resource indicators and audience validation on MCP and tool servers; forbid token passthrough.
Route high-impact actions through a policy engine or human approval the agent cannot bypass.
Log agent identity, delegated user, tool and resource for every action, and baseline behaviour.
Drill the kill switch quarterly and time it.

Top 10 Agent Identity Controls: What to Implement and How to Prove It