An AI agent access review is a periodic, signed decision that each agent should keep, lose, or change each right it holds. Banks already run this cycle for people: extract every entitlement, send each line to an accountable reviewer, record certify or revoke, remove what was revoked, and keep the evidence. Agents need the same cycle with a wider line item. An agent right covers the tool, the action, the amount, the data, the environment, the approval gate in front of the action, and the date the right ends.
This guide describes how to run that campaign. The AI agent permissions guide explains how to design the rights in the first place, and the access-control pillar covers the operating model from identity to revocation. This article starts after the rights exist and asks how a reviewer certifies them. General information, current to 23 October 2026; it does not replace legal or audit advice.
What the reviewer certifies
A user access review asks whether a person still needs a role. An agent review asks a longer question: does this agent still need each action it can take, at this limit, on this data, with this approval gate, under this owner, until this date? A role name rarely answers it. Two agents in the same role can hold different tools, different amount limits, and different exceptions.
Certify effective authority, the rights the agent can actually exercise today. Compare four views of each right: what the owner requested, what was approved, what is configured in the identity provider, tool gateway, and policy, and what the agent used during the review period. A right that was approved and configured but never used is a removal candidate. A right that was used but never approved is a finding.
| Field | What the reviewer sees | Question to answer |
|---|---|---|
| Agent and Release | Agent name, Agent Registry identifier, current Release, accountable owner | Is the owner still in role and still accountable? |
| Action | Tool and operation, for example payments.create_transfer | Does the business process still need this action? |
| Limit | Per-action and per-day amount, destination rules, rate limit | Is the limit the lowest that still lets the process work? |
| Data Boundary | Systems, fields, regions, and purposes the agent may read or write | Does the agent read anything it no longer uses? |
| Approval gate | The policy rule that returns require_approval and the reviewer role it routes to | Is the gate still in place, and is the role still correct? |
| Credential | Identity, token or secret, issuer, lifetime, last use | Is the credential scoped to this agent and still needed? |
| Usage in period | Count of allowed, warned, approved, rejected, and blocked actions | Does observed use match the stated purpose? |
| End date | Mandate or exception expiry | Should the right end earlier than planned? |
Borrow the bank recertification cycle
A recertification campaign has a fixed population, a fixed cut-off date, named reviewers, a deadline, and a remediation step that someone checks. Keep that structure. Change the line item and add two tests that human reviews rarely need: proof that the approval gate still routes, and proof that revocation stops the next action.
| Stage | Work | Output |
|---|---|---|
| 1. Scope | Fix the cut-off date. Reconcile the Agent Registry with the identity provider, secrets vault, tool gateway, MCP server registrations, and runtime logs so the population includes agents nobody registered. | Population list with source of each entry and the agents found outside the registry |
| 2. Extract | Export effective rights per agent as line items, with usage for the review period. | Signed or hashed extract with its generation time |
| 3. Assign | Route each agent to its accountable owner. Route privileged rights and exceptions to a second reviewer outside the owning team. | Reviewer assignment with conflict check |
| 4. Decide | For each line: certify, modify, revoke, or record an exception with an end date. | One decision, reason, reviewer, and time per line |
| 5. Remediate | Apply each modify and revoke in the system that owns the right. | Change receipt per line, linked to the decision |
| 6. Verify | Re-extract and compare. Attempt one revoked action per agent in a test environment or through a policy simulation. | Closed-loop comparison and a denied attempt for each revoked right |
| 7. Sign off | The campaign owner records scope, completion rate, overdue items, findings, and limitations. | Campaign record ready for internal audit |
Set review frequency from risk and from events
For EU financial entities in scope of DORA, the ICT risk-management standard sets a floor. Article 21(1)(e) of Commission Delegated Regulation (EU) 2024/1774 requires account management procedures that assign roles and responsibilities for "granting, reviewing, and revoking access rights", withdraw access rights without undue delay when no longer needed, and provide for "the update of access rights where changes are necessary and at least once a year" for ICT systems, and "at least every 6 months" for ICT systems supporting critical or important functions. Article 21(1)(a) requires rights to follow need-to-know, need-to-use, and least-privilege principles, and Article 21(1)(c) requires users to be "identifiable for the actions performed in the ICT systems at all times".
The regulation addresses access rights to ICT assets generally and does not mention AI agents. An agent that holds credentials to an ICT system supporting a critical or important function holds access rights to that system. Ask your compliance function whether the 6-month floor applies to it. Many teams review agents more often than people, because an agent can use a right thousands of times between campaigns.
| Agent profile | Scheduled review | Event that triggers an immediate review |
|---|---|---|
| Moves money, changes customer records, or sends external communications | Quarterly | New tool, higher limit, new Release, owner change, incident, or a blocked action pattern |
| Supports a critical or important function without write access | Every 6 months | New data source, new region, or change of purpose |
| Internal, read-only, no personal data | Annually | Any request for write access |
Make each decision change something
A review that only collects approvals proves little. Each decision should leave a trace in configuration or in a dated exception register.
| Decision | Required follow-through | Evidence |
|---|---|---|
| Certify | No change. The right keeps its current end date. | Reviewer, time, reason, and the extract line certified |
| Modify | Lower a limit, narrow a Data Boundary, shorten an end date, or add an approval gate. | Before and after values, change receipt, policy version |
| Revoke | Remove the right in the owning system and revoke any credential that only served it. | Change receipt and a denied attempt after removal |
| Exception | Keep a right that breaks a rule, with a compensating control and an end date no later than the next campaign. | Exception owner, approver, compensating control, expiry |
| No response by the deadline | Escalate to the owner’s manager. Your policy decides whether the right is suspended at the final deadline. | Escalation history and the final state of the right |
Tests that catch what a sign-off misses
Run these tests on the extract before reviewers see it, and show the results on the line item. They turn a judgement call into a finding with a number.
- Unused right: granted for the whole period and never exercised. Default the line to revoke and ask the owner to justify keeping it.
- Unapproved use: the agent exercised a right with no approval record. Raise a finding before the campaign closes.
- Toxic combination: one agent can both create a beneficiary and release a payment, or both draft and approve. Split the rights or put a different human role on one side.
- Missing gate: a policy change since the last campaign removed or weakened a require_approval rule. Compare policy versions line by line.
- Self-review: the reviewer is the person who requested the right or sponsors the agent. Reassign.
- Orphaned owner: the accountable owner left or changed role. Suspend new rights until a new owner accepts.
- Shared credential: one secret serves several agents. Usage cannot be attributed, so the line cannot be certified.
- Expired exception still active: the exception end date passed and the right still works.
Worked example: quarterly review of a payments agent
The agent, figures, and identities below are synthetic. A treasury operations agent prepares and releases supplier payments. The review period is 1 July to 30 September 2026. Its owner is the head of treasury operations; privileged lines go to a second reviewer in operational risk.
| Line item | Observed in period | Decision | Follow-through |
|---|---|---|---|
| payments.create_transfer up to EUR 50,000 to existing beneficiaries | 1,412 allowed actions, 0 blocked | Certify | None |
| payments.create_transfer above EUR 50,000, gated by require_approval to a treasury checker | 37 approval requests, 35 approved, 2 rejected | Certify | None; gate confirmed in current policy version |
| beneficiaries.create | 3 uses, all for one supplier onboarding project that ended in August | Revoke | Right removed; attempt in test returned block |
| erp.read_invoices across all subsidiaries | Reads from two of five subsidiaries | Modify | Data Boundary narrowed to the two subsidiaries |
| Exception: release before sanctions re-screen for intra-group transfers | Granted in June with end date 30 September 2026 | Exception expired | Exception closed; right now follows the standard rule |
| Shared API key with the reconciliation agent | Usage cannot be split by agent | Finding | New per-agent credential issued; shared key revoked |
Where KLA fits in an access review
KLA has no access-review campaign module. The review runs in your identity-governance tool or workpaper. The KLA Control Plane holds several of the inputs a reviewer needs and enforces the revoke decision on the governed action path. This section describes current source code.
For agents that act through KLA agent action ingress, each agent works under an agent mandate: a versioned record with an accountable owner, an institutional principal, allowed tools, operations and destinations, purposes, environments, threshold constraints on action parameters, and a validity window with a required end date. The person who created a mandate cannot approve it. Listing an agent’s mandates returns this scope with its validity dates and lifecycle actors, which gives the reviewer the line items for that path.
A revoke decision maps to mandate revocation. Only the tenant administrator and compliance officer roles can revoke, and a reason is required. Revocation blocks open proposals bound to that mandate with the reason code mandate_revoked and cancels their pending Decision Requests. The next action the agent proposes under a revoked or expired mandate is refused before it is recorded as a proposal. An action that was already admitted may still complete. Each revocation is written to an append-only mandate lifecycle record that evidence export includes.
Every governed action receives one of four policy outcomes: allow, warn, require_approval, or block. Those outcomes give the usage counts in the line item. Decision Desk refuses decisions from the recorded requester, checks the required reviewer role, and records the decision with a note and the reviewer’s roles at that time. Rights held outside KLA, such as identity-provider groups, vault secrets, and target-system accounts, stay with their owning systems and need their own extract.
A certified line item only holds if enforcement checks the same agent identity. In August 2026, while writing a payment approval rule in our own test tenant, we found that the agent scope on a policy was not yet enforced at runtime. We changed policy matching to check the acting agent’s identity on each call and to fail closed when that identity is missing. Our automated acceptance runs in test tenants also use two identities, one to start a governed run and one to decide its Decision Requests, because Decision Desk refuses a decision from the requester and requires a reason for each decision.
Primary sources
Source review completed 23 October 2026. Commission Delegated Regulation (EU) 2024/1774 supplements Regulation (EU) 2022/2554 (DORA) with regulatory technical standards on the ICT risk-management framework. The quotations above come from Article 21, "Access control". The regulation sets duties for financial entities in DORA scope; the cadence table, line-item fields, tests, and worked example in this guide are implementation patterns with no legal force. Confirm with your compliance function which functions you classify as critical or important.
Frequently Asked Questions
What is an AI agent access review?
It is a periodic campaign in which a named reviewer decides, for each right an agent holds, whether to certify it, modify it, revoke it, or keep it as a time-bound exception. The right covers the tool, action, amount, data, environment, approval gate, credential, and end date.
How often should AI agent access be reviewed?
Set the cadence from risk and add event-driven reviews. For EU financial entities under DORA, Delegated Regulation (EU) 2024/1774 requires access rights to be updated at least once a year, and at least every 6 months for ICT systems supporting critical or important functions. Agents that move money or change customer records are often reviewed quarterly.
Who should review an AI agent’s entitlements?
The accountable owner of the agent reviews ordinary rights. A second reviewer outside the owning team reviews privileged rights and exceptions. The person who requested a right should not certify it.
How do you audit and certify AI agent access rights?
Reconcile the full agent population across the registry, identity provider, secrets, gateways, and logs. Extract effective rights with usage for the period. Route each line to a reviewer, record certify, modify, revoke, or exception, apply the changes, re-extract to confirm them, and attempt one revoked action to prove it is denied.
What evidence does an auditor expect from an agent access review?
The population and how it was reconciled, the extract with its generation time, reviewer assignments, one decision per line with reason and time, change receipts for every modification and revocation, the re-extract comparison, denied attempts for revoked rights, the exception register, and the campaign sign-off with limitations.
How is an agent access review different from a user access review?
The cycle is the same. The line item is wider, because an agent right includes amount limits, data scope, the approval gate in front of the action, and an end date. Usage data is richer, so unused and unapproved use can be measured. Revocation must also be tested, because an agent can act again within seconds.
Key Takeaways
Run the agent campaign with the same discipline banks apply to people: a fixed population, a reviewer for every line, a decision that changes something, a check that the change took effect, and a signed record. Start with the entitlement review checklist, take one high-risk agent through the seven stages, and keep the campaign record for the next audit.