IT administrators bank a correction by noting why they reversed or changed the agent's access grant or reset, and routing that reason to the agent owner as a change, usually to its bounds or group mapping source. Most IT corrections concern what the agent may touch, not what it knows, so the bound is where the fix lives.
What does the agent do, and what gets corrected?
A service desk agent in IT typically resets passwords and releases locked accounts within set rules (depth 3), drafts access grants for a person to approve (depth 2), and prepares joiner, mover and leaver changes. Administrators correct it in a few repeating ways.
It grants a new starter the group membership of their predecessor, including rights that belonged to a temporary project. It treats a mover as a joiner and leaves their old access in place. It drafts an access request to a finance system without noticing the requester is a contractor. Or it resets a password for a caller whose identity check was weak.
Every one of these is an access question, and that is the point to teach first. An IT agent rarely fails because it misunderstood a document. It fails because the bounds or the role-to-group mapping allowed something they should not. The wider role map is in AI agent skills by role.
What are the steps?
- Agent, depth 3: performs routine resets and account releases within the identity checks and limits set by the business.
- Agent, depth 2: drafts access grants and joiner, mover, leaver changes, citing the role-to-group mapping it used.
- Person (IT administrator): approves, amends or rejects, and records a reason: wrong mapping, stale mapping, bound too wide, bound too narrow, weak identity check, or one-off.
- Agent, depth 1: groups reasons weekly by system and request type.
- Person (IT lead): decides what to bank. Anything touching privileged access goes to the security owner as well.
- Person (agent owner): makes the change. A corrected role-to-group mapping replaces the old one as a sealed source from the identity system; a tighter rule on contractors goes into the customer's limits; a privileged group becomes a hard refusal for the agent.
- Attest replays the agent against past tickets and requests, then the IT lead accepts or rejects the result, and the change is logged as a normal change record.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Routine reset | Resets or releases accounts within checks | 3 | Exceptions and weak checks |
| Access draft | Proposes groups from mapping | 2 | Approving the grant |
| Correct | Nothing; reason filed | 1 | Reason code |
| Bank | Nothing | none | IT lead and security owner |
| Re-certify | Replayed in Attest | none | Accepting the result |
What must an IT administrator learn?
The core skill is telling a mapping problem from a bound problem. If the agent proposed the wrong groups because the mapping is out of date, fix the mapping source; every future request improves. If the agent proposed groups that the mapping allows but the business never should, the bound is wrong, and the fix is a limit, not a source.
The second is treating privileged access as a red line. Domain administration, production database rights and payment system administration should be refused for the agent at every depth by the customer's own limits. An administrator who corrects one such draft should not bank "the agent may propose this with approval"; they should bank "the agent refuses and hands back".
The third is linking banked changes to change management. In most IT teams any change to identity configuration is a change record. A brief or bound change for the agent is one too, and it should carry the same ticket. The habits behind this are covered in how IT administrators review an AI agent's decisions.
Which controls should be in place, and what evidence do they leave?
- Mapping from the identity system only. The agent reads group mappings as sealed facts from the system of record, not from a spreadsheet. Evidence: provenance on each mapping.
- Privileged access refused. Evidence: refused verdicts naming the bound that decided.
- Change records for banked changes. Evidence: the change ticket number on the brief or bound edit.
- Re-certification. Evidence: a dated certificate. A run that clears no depth drops the agent to depth 1, so resets go to people until fixed.
What should IT measure?
Measure repeat corrections per reason code, especially stale mapping and bound too wide. Measure leaver changes the agent got right first time; leavers are where leftover access hides. Measure how long a mapping change in the identity system takes to reach the agent. And measure refused requests that people then approved anyway, because that shows where the bound and the business disagree.
Where does it usually go wrong?
Mappings drift. Teams create groups for projects and never retire them, the agent copies them to new starters, and administrators correct case by case. Bank a rule that project groups are never inherited, and fix the mapping.
Administrators also loosen bounds to cut their queue. Approving thirty identical access requests a day is tedious, and the obvious fix is to let the agent grant them at depth 3. That may be right, but it is a depth change, which must be earned through Attest evidence, not a convenience edit. Payroll teams face similar pressure around access to pay data, as teaching payroll administrators to bank corrections describes, and public bodies add their own scrutiny, covered in AI agent training for IT administrators in the UK public sector.
Where the Academy fits
Pryme Intelligence Academy's Operator track covers how a governed agent decides, human review, teaching the agent and when something goes wrong, which together cover the work of banking corrections. Labs run in a free Build workspace, so administrators can practise changing a bound and reading the re-certification result before touching a live identity system.
Questions people ask
Should the agent ever reset passwords at depth 3?
It can, if Attest evidence supports it and identity checks are strong. Weak checks or high-value accounts should still hand back to a person.
Who should own the role-to-group mapping?
The identity or access management owner. The agent reads it; it should never maintain it.
What happens if a banked change breaks resets?
If re-certification falls short, the agent keeps only the highest depth it cleared, or drops to depth 1 the same day if it cleared none; below the depth resets need, every reset goes to a person until the change is fixed and re-certified.