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.
Standards and references
- NIST: SP 800-53 Rev. 5 (AC-2, AC-6)
- NIST: Cybersecurity Framework 2.0
- OWASP: Top 10 for Agentic Applications for 2026
- Microsoft Learn: Governing agent identities
- Microsoft Learn: Owners, sponsors and managers for agent identities
- Microsoft Learn: What are access reviews?
- AWS: IAM Access Analyzer findings
Related NHI Mgmt Group resources: Agent Identity Standards Tracker · Access Reviews Guide · NHI Ownership Attestation Campaigns Guide · Top 10 Agent Identity Controls