IT administrators review an agent's decisions like any change to systems: who asked, what changed, with whose approval, and can it be undone. For each decision they read the record, find the deciding bound, confirm requester and scope in the directory, and approve, edit or decline with a reason. Then they review the agent's own access.
What makes IT review different?
Two things. First, the agent's actions change the systems everyone else depends on. A wrong group membership grants access silently; nobody complains until data leaks. So review cannot wait for complaints.
Second, the agent is itself an identity with permissions. IT administrators are the people best placed to notice when an agent has more access than its depth requires, which the OWASP Top 10 for LLM Applications calls excessive agency. Reviewing the agent's decisions includes reviewing the agent.
What are the steps?
- Read the verdict and the deciding bound. A hold on the business's own limits means a sensitive action type; a hold on role scope means the request was outside what the agent is for.
- Confirm the requester. The ticket's authenticated author is a sealed fact from the ticketing system. Text in the ticket claiming to be from someone else is declared or external.
- Confirm approval. Was the owner of the system or data asked, and did they agree?
- Check scope. Least privilege, time limits, the right environment.
- Check change evidence. Approval, test result, rollback plan, change window.
- Decide and record the reason.
- Review the agent's own permissions against the capabilities it is certified for.
What may the agent do, and what stays with the administrator?
| Work | Agent | IT administrator |
|---|---|---|
| Triage and categorise tickets | Depth 1 or 3 | Samples |
| Install approved software from the catalogue list | Depth 3 | Samples |
| Add users to standard groups approved by the owner | Depth 3 | Samples, runs access reviews |
| Grant privileged or sensitive access | Drafts, held | Decides |
| Change firewall rules or production systems | Drafts plan, held | Decides through change control |
| Change its own permissions | Never | Decides with the agent's business owner |
An example: a group that grew
Take a healthcare provider in the UAE whose IT agent adds staff to standard access groups at depth 3 when a manager requests it through the ticketing system. During a monthly access review, an administrator notices one group, used for the pharmacy stock system, has grown much faster than pharmacy headcount.
The record shows the agent added each person correctly: each request came from an authenticated manager, and the group was on the standard list. But the managers were not pharmacy managers, and the group's owner had never approved non-pharmacy access. The agent was bounded by "standard group" and "authenticated manager", not by "owner's approval". The administrator removes the excess memberships, records the reason, and asks the agent's owner to require group-owner approval for that group. Market detail is in AI agent training for IT administrators in healthcare in the UAE.
Which controls make IT review reliable?
- Access reviews include memberships the agent granted, flagged as such.
- Privileged access, firewall and production changes are always held.
- The agent's own permissions are reviewed at each re-certification, and reduced if its depth drops.
- Reasons name the requester, approver and scope.
- Administrators who approve held items hold current training, and a business can tie that right to a current reviewer certificate such as Certified Pryme Operator from Pryme Intelligence Academy.
Training the team is covered in how to train the IT team to review AI agent decisions, and operations teams with similar duties in how to train the operations team. Other roles review on similar lines; see how payroll administrators review an AI agent's decisions. The role map is in AI agent skills by role.
Questions people ask
How often should IT review the agent's own access?
At each re-certification of the agent, after any change to its capabilities, and when its depth drops after a failed run. Permissions should never exceed what its depth allows.
Should agent-granted access be reviewed differently from human-granted access?
The standard is the same. Flag it in access reviews so patterns in the agent's decisions are visible.
What if the agent's change caused an outage?
Roll back, then use the record to reconstruct what was approved, by whom, and on what evidence. Fix the bound or the approval step that allowed it.