Agent Identity Recertification: Risk-Based Review Cadence

AI agents collect access faster than any human account, yet most organisations recertify them on the same annual cycle they use for employees, or not at all. An agent can gain new tools, OAuth scopes, delegated user rights and API keys in a week, change its behaviour when its model or prompt changes, and keep running long after its sponsor has moved on. This guide sets out a risk-based way to recertify agent identities: how to tier agents, which events should force a review between cycles, what evidence a reviewer needs, and which decisions to allow. It is written for identity governance teams, platform owners and the business sponsors who have to sign off agent access. For the wider field see the Agent Identity and Access Guide; for generic NHI owner campaigns see the NHI Ownership Attestation Campaigns Guide.

Key takeaways

Cadence follows risk, not calendar. Tier each agent by what it can touch, how autonomously it acts and whose authority it uses, then set review frequency per tier, from monthly to annually.
Events matter more than dates. A new tool, a scope increase, a model or prompt change, a sponsor departure or an anomaly should trigger a focused review within days, whatever the scheduled cycle.
Reviewers need usage evidence, not a list of names. Show granted versus used permissions, tool call history, data touched, credential age and recent incidents, or the review becomes a rubber stamp.
Expiry is the strongest control. Time-bound access assignments that lapse unless the sponsor renews them turn non-response into removal instead of silent continuation.
Recertify the delegation, not only the identity. For agents acting on behalf of users, review which users delegate, which scopes they delegate and whether the agent still needs standing application permissions at all.

Why agents need their own recertification model

Access reviews were designed for people: a manager confirms that a team member still needs a role. NIST SP 800-53 Rev. 5 control AC-2 asks organisations to review accounts at a frequency they define and to act when accounts are no longer required, and AC-6(7) asks for periodic review of privileges. None of that changes for agents, but four properties of agents break the human assumptions.

Access grows by configuration, not by request: a developer adds an MCP server or a plugin and the agent gains new reach without any access request. See the Agent Permission Drift page.
Behaviour changes without an identity change: a model upgrade, a new system prompt or a new memory source can change what the agent does with the same permissions.
Authority is often borrowed: many agents use delegated user tokens, so the effective permission set is the intersection of the agent's scopes and each delegating user's rights. See the Delegation Chains and Attenuated Authority for AI Agents page.
Nobody leaves: joiner, mover and leaver processes are triggered by HR events. Agents have no HR record, so the sponsor relationship is the only lifecycle anchor. See the Ownership for Orphaned and Abandoned AI Agents page.

The OWASP Top 10 for Agentic Applications (published 9 December 2025) lists ASI03 Identity and Privilege Abuse and ASI10 Rogue Agents among its risks. Recertification is one of the few controls that addresses both: it removes privilege that is no longer justified and surfaces agents that nobody is accountable for. See the OWASP Agentic Top 10 ASI03 Guide.

Tiering agents by risk

Score each agent on four factors, then take the highest tier any factor reaches. The thresholds below are our recommended starting point, not a published standard; adjust them to your risk appetite and record the rationale.

Factor	Tier 1 (critical)	Tier 2 (high)	Tier 3 (moderate)	Tier 4 (low)
Data and systems reached	Production write, payments, identity systems, regulated personal data	Production read of sensitive data, customer-facing actions	Internal non-sensitive data, test environments	Public data only
Autonomy	Acts without human approval on irreversible actions	Acts autonomously, human approval for destructive actions	Proposes actions, human executes	Answers questions only
Authority	Standing application permissions across tenants or many users	Delegated rights from many users, or privileged roles	Delegated rights from one user or team	No credentials beyond its own read-only identity
Exposure	Processes untrusted external input (email, web, tickets) and holds write access	Processes untrusted input, read access only	Internal input only	Sandboxed, no network egress

Cadence by tier

Tier	Scheduled recertification	Maximum access assignment duration	Reviewer	Evidence depth
Tier 1	Monthly	30 days, renewal requires sponsor and security approval	Sponsor plus security or resource owner (two-person)	Full: permissions used, tool calls, data volumes, anomalies, credential inventory
Tier 2	Quarterly	90 days	Sponsor plus resource owner	Permissions used, tool inventory, anomalies
Tier 3	Semi-annually	180 days	Sponsor	Permissions used, last activity
Tier 4	Annually	365 days	Sponsor	Existence, purpose and sponsor confirmation

Small versus large organisations: with fewer than about twenty agents, a single quarterly review of all agents by the platform owner and each sponsor is usually enough, with Tier 1 agents reviewed monthly. With hundreds of agents, automate tiering from metadata (scopes, connected tools, data classification of target systems) and reserve human review effort for Tier 1 and 2 and for event triggers.

Event-driven recertification triggers

Scheduled reviews catch slow drift. Most agent risk arrives as discrete changes, so define triggers that open a focused review of just the changed element, with a deadline.

Trigger	How to detect it	Review scope	Deadline
New tool, MCP server or plugin connected	Agent platform configuration change, MCP gateway registration	The new tool's permissions and data reach	Before use for Tier 1 and 2; 7 days otherwise
OAuth scope or role added	Directory audit log (consent grants, role assignments)	The added scope and whether it re-tiers the agent	Before use for Tier 1; 7 days otherwise
Model, system prompt or memory source changed	Release pipeline, agent registry version	Behavioural evaluation results and guardrails	Before production promotion
Sponsor leaves or changes role	HR leaver and mover events joined to the sponsor field	New sponsor accepts or the agent is disabled	Before the sponsor's last day
Agent idle	No sign-ins or tool calls for 30 days (Tier 1 and 2) or 90 days	Disable or justify	14 days
Security signal	Anomalous data volume, denied actions, policy violations, risk score change	Full Tier 1 review regardless of tier	Immediately; suspend first if needed
Third-party compromise	Vendor breach notification affecting the agent's platform or integration	Revoke and reissue credentials, re-approve scopes	Same day

The Salesloft Drift breach shows why the last trigger matters: OAuth tokens held by one chatbot integration gave attackers access to Salesforce data in what Google said were over 700 potentially affected organisations. Customers that knew which integrations held standing access, and who owned them, could revoke and re-approve quickly.

Evidence the reviewer needs

A reviewer who sees only an agent name and a list of roles will approve. Build a review pack per agent from platform data, so the sponsor answers specific questions.

Identity and accountability: agent identifier, platform, sponsor and owner, creation date, last change, tier and the reason for that tier.
Granted versus used: each role, scope, group and API permission with last-used date. In AWS, IAM Access Analyzer unused access findings report unused roles, unused access keys and unused service and action level permissions over a usage window you set. In Microsoft Entra, sign-in and audit logs give the equivalent for service principals and agent identities.
Tools and integrations: connected tools, MCP servers and plugins, with what each can reach and when each was last called. See the AI Agent Tool and Plugin Security Guide.
Delegation: number of users who delegated to the agent, delegated scopes, and whether the agent also holds application permissions that bypass user context.
Credentials: every secret, key, certificate and token the agent uses, its age, storage location and rotation date. Static keys found in code or files are an automatic finding.
Behaviour: volumes of records read and written, denied actions, guardrail interventions and incidents since the last review.
Change log: model, prompt, memory and tool changes since the last review.

Questions the sponsor must answer

Is the business purpose recorded at creation still valid, and is this agent still the way it is delivered?
Which permissions in the pack were not used in the review window, and why should any of them stay?
Does the agent need standing application permissions, or could it work with delegated, user-bound tokens?
Has any tool, model, prompt or data source changed in a way that changes the tier?
Are all credentials stored in an approved secrets manager and rotated on schedule?
Would you be comfortable explaining every action in the behaviour summary to an auditor?

Require a short free-text justification for any permission kept despite being unused, and sample those justifications in the security team's quality check of each campaign.

Decisions and what happens next

Decision	When to use it	Automated follow-up
Certify as is	All access used and justified, purpose unchanged	Extend assignments to the tier maximum
Certify with reduction	Unused or excessive permissions present	Remove the marked permissions, open a ticket to replace broad credentials
Re-tier	Reach or autonomy changed	Apply new cadence and assignment duration
Transfer sponsor	Sponsor no longer appropriate	New sponsor must accept within the deadline or the agent is disabled
Suspend	Unexplained behaviour or unknown purpose	Disable identity, revoke tokens, keep configuration for investigation. See the AI Agent Kill Switch and Containment Guide.
Decommission	Purpose ended or no accountable sponsor	Revoke credentials, remove grants, delete identity after the retention period

Non-response: for Tier 1 and 2, non-response should mean removal at assignment expiry. Microsoft Entra access packages already work this way for agent identities: an assignment with an end date notifies the sponsor as expiry approaches, and if the sponsor does nothing the agent loses access on the end date. For Tier 3 and 4, escalate to the sponsor's manager before removal.

Implementing on the platforms you have

Microsoft Entra Agent ID

Entra requires a human sponsor for every agent identity and agent identity blueprint; owners (technical) and managers are optional. Sponsors can make renewal and removal decisions, request access packages on the agent's behalf and disable the agent, but cannot re-enable it. Entitlement management access packages can target "All agents", bundle security groups, OAuth API permissions and Entra roles, and carry an expiry date. Lifecycle Workflows transfer sponsorship to the sponsor's manager when the sponsor leaves and can notify co-sponsors. Microsoft documents these features under Microsoft Agent 365 licensing. Use a dynamic group or more than one sponsor so accountability does not rest on one person.

AWS

Run an IAM Access Analyzer unused access analyzer across the organisation and feed its findings for agent roles into the review pack. External access findings show resource policies that let principals outside your organisation reach data an agent manages.

Other platforms

Where the agent platform has no governance features, register agents in a central inventory with sponsor, tier and credential fields, and run reviews from your IGA tool against that inventory. See the Cloud Agent Identity Services Compared (Entra, AgentCore, Google) page for what each provider offers.

Rollout

Inventory: discover agents across platforms, assign a sponsor to each and disable any that nobody claims within 30 days.
Tier: apply the four factors, starting with agents that have production write access.
Pilot: run one review cycle for Tier 1 agents in report-only mode, where decisions are recorded but not applied, and measure how many removals reviewers would make.
Enforce: switch on automatic application of decisions and assignment expiry for Tier 1 and 2.
Add triggers: wire configuration, consent and HR events into event-driven reviews.
Roll back safely: keep removed grants recorded for 30 days so a wrongly removed permission can be restored through a normal access request rather than an emergency change.

Measuring whether it works

Percentage of agents with a named, active sponsor (target 100 percent).
Percentage of granted agent permissions unused in the review window, trending down.
Median days from an event trigger to a completed review, per tier.
Reduction rate: share of reviews that removed at least one permission (very low rates suggest rubber-stamping).
Number of agents disabled for no sponsor or idleness per quarter.
Percentage of Tier 1 and 2 agents with time-bound assignments rather than standing grants.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	AC-2 Account Management (review at defined frequency, act when no longer required), AC-2(3) Disable Accounts, AC-6 Least Privilege, AC-6(7) Review of User Privileges, IA-4 Identifier Management, IA-5 Authenticator Management, AU-6 Audit Record Review	Core recertification controls applied to agents
NIST CSF 2.0	PR.AA-01, PR.AA-05, GV.RR-02, DE.CM-03	Identity management, reviewed entitlements, accountable roles, monitoring
OWASP Top 10 for Agentic Applications	ASI03 Identity and Privilege Abuse, ASI10 Rogue Agents	Risks reduced by recertification and sponsor accountability

Common failure patterns

Reviewing the agent, not its credentials: in the PocketOS database deletion, a coding agent found an account-scoped Railway API token in an unrelated file and used it to delete a production volume. A review of the agent's assigned roles would have missed it; a credential inventory that included tokens reachable from the agent's workspace would not.
One annual campaign for every agent: high-risk agents go eleven months without review while low-risk ones waste reviewer time.
No usage data in the pack: reviewers approve everything because they cannot tell what is used.
Sponsor is a departed employee or a shared mailbox: the review goes to nobody and access continues by default.
Ignoring delegated access: the agent's own scopes look narrow, but it also acts with the rights of hundreds of users who delegated to it.
No trigger on model or tool changes: the agent recertified last month is not the agent running today.

Practitioner checklist

Require a human sponsor, preferably more than one, for every agent identity at creation.
Tier every agent on reach, autonomy, authority and exposure, and record the rationale.
Set scheduled cadence and maximum assignment duration per tier.
Define event triggers for new tools, scope changes, model or prompt changes, sponsor departure, idleness and security signals.
Build review packs with granted versus used permissions, tools, delegation, credentials and behaviour.
Make non-response mean removal for Tier 1 and 2 through assignment expiry.
Include tokens and keys reachable from the agent's runtime in the credential inventory.
Track the six metrics above and report them alongside human access review results.

Agent Identity Recertification: Risk-Based Review Cadence, Evidence and Decisions