How to set an approver rule for the IT team

Service desk analysts approve the access requests and resets the agent holds. Privileged access needs the system owner plus security. Production changes go through your change process with a named approver. And one line is easy to miss: any change to another agent's connections or sources needs that agent's owner as well as IT. Rights lapse with certificates.

What does the IT team's approver rule decide, and who owns it?

IT teams use agents on the service desk and in operations: answering tickets, resetting passwords, granting standard access, restarting services, drafting change requests. IT also connects other teams' agents to systems, which gives IT approvals a reach beyond its own work. The approver rule names who may release each held action.

The head of IT owns the rule, with the information security lead signing it off. The agent owner configures it. Our explainer on what an agent approver is covers the role, and our guide to AI agent skills by role covers what IT administrators need to know.

What are the steps?

1. Head of IT: lists the agent's actions by depth. Depth 1: reads tickets, logs, monitoring and the asset register. Depth 2: drafts change requests, incident reports and user replies. Depth 3: resets passwords and re-enables locked accounts after verification, grants access from the pre-approved role catalogue, restarts named services. Depth 4: grants privileged access, changes production configuration, deletes accounts or data, changes an agent's connections.
2. Head of IT: assigns non-standard access requests to service desk analysts, with the requester's manager approving the business need.
3. Head of IT: assigns privileged access to the system owner plus a security approver, time-limited.
4. Head of IT: routes production changes to your change process, with the agent's draft as the request.
5. Head of IT: adds the agent-owner line. Changes to any agent's connections, credentials or sources need that agent's owner and an IT approver.
6. Head of IT: ties each role to a current certificate. Agent owner configures and files.

Why do changes to agent connections need the agent's owner?

Every agent's depth is earned on a specific set of sources and connections. If IT changes the data feed a lending agent reads, or gives a support agent a new connection to the payments system, the agent may behave differently from how it was certified. IT can see that the change is technically sound; only the agent's owner can judge whether it changes what the agent will decide.

So the rule asks for both. The agent owner then decides whether the change needs re-certification before the agent uses it. A new sealed source might be harmless; a new connection that could move money changes the agent's reach and should be certified first.

Password resets deserve a word too. Social engineering targets the service desk because it can reset access. The agent should verify through a channel already on file, and refuse when verification fails, passing the request to an analyst. A caller's urgency is declared, not evidence.

Which controls make the rule work, and what evidence do they leave?

Pre-approved catalogue for depth 3 access. Evidence: the catalogue, versioned, and each grant matched to it.

Two approvers on privileged access. Evidence: system owner and security names on each grant, with an expiry.

Agent owner sign-off on connection changes. Evidence: owner approval on each change, with any re-certification linked.

Verification before reset. Evidence: the verification channel and result on each reset; refused verdicts when it failed.

Rights lapse with certificates. Evidence: certificate status on each approval date, matched to the approver authority matrix for the IT team.

What should you measure?

• Privileged access grants without expiry. The target is none.
• Resets refused for failed verification, and how many turned out to be attacks.
• Agent connection changes made without the owner. The target is none.
• Tickets resolved by the agent at depth 3 against tickets held, to see whether the catalogue fits real demand.

Where does it usually go wrong?

The catalogue grows without review. Each new role is added "because people keep asking", and privileged combinations creep into depth 3. Review the catalogue with security at least quarterly, and remove roles nobody has requested.

IT approves its own access. An administrator approves their own privileged request because they are the system owner. Name a different approver.

Leavers keep access. The agent grants access quickly; nobody tells it when people leave. Make removal of access a depth 3 action triggered by the HR leaver record, a sealed source, so access ends as fast as it began.

Agent changes are treated like any software change. The change process approves the release; nobody asks the agent's owner. Add them to the route.

Borrowing from support or operations. The approver authority matrix for the support team and the approver rule for the operations team deal with customers and processes, not access. Lending teams also depend on IT getting this right; see the approver rule for the credit team for the other side of a data feed change.