Resolving a ticket means acting on the systems behind it, so permissions belong to actions, not the queue. An agent can categorise, answer from the knowledge base and run a short list of approved fixes at depth 3. Access grants, production changes and major incidents go to a person, and every action is written to the ticket.
What does resolving IT tickets involve, and who owns it?
An IT service desk handles a steady mix: forgotten passwords, locked accounts, a laptop that will not connect, a request for access to a shared folder, a new starter's equipment, a system that has stopped working for a whole team. The ITSM platform holds the tickets, the knowledge base, the service catalogue and the change records.
The service desk manager owns the queue and its service levels. System owners own the systems the fixes touch. The change manager owns what may change in production and when. Information security owns identity, access and anything that touches privileges. An agent that resolves tickets works across all of them, which is why "resolve" cannot be one permission.
Which actions should the agent get, and at what depth?
- Agent, depth 1: reads tickets, the knowledge base and the configuration records for the user's devices and services.
- Agent, depth 3: categorises and prioritises tickets using the platform's own categories and priority rules. A person can override.
- Agent, depth 3: answers how-to questions from approved knowledge articles, quoting the article it used.
- Agent, depth 3: runs catalogued fixes: releasing a locked account after identity verification, a mailbox quota increase within the standard limit, clearing a stuck print job, re-sending a software package already approved for that user's role.
- Agent, depth 2: prepares access requests. It fills the request with the system, the access level and the business reason, and routes it to the access approver. It never grants access itself.
- Agent, depth 2: drafts change requests for anything that alters a production system, for the change process to approve.
- Agent, depth 3: closes tickets once the user confirms the fix, or after the waiting period the desk's rules set.
- Agent, depth 1: escalates major incidents. When many users report the same failure, it links the tickets and calls the on-call person. It does not try fixes on a live incident.
- Refused for the agent: granting privileged or administrative access, disabling security controls, and changing its own permissions.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read | Tickets, knowledge, configuration | 1 | Nothing |
| Categorise, prioritise | Applies platform rules | 3 | Overrides |
| How-to answers | Replies from approved articles | 3 | Article approval |
| Catalogued fixes | Runs listed fixes | 3 | Adding fixes to the list |
| Access requests | Prepares and routes | 2 | Granting |
| Changes | Drafts the change request | 2 | Change approval |
| Close | Closes on confirmation | 3 | Reopening disputes |
| Major incidents | Links and escalates | 1 | Incident command |
| Privileged access | Nothing | refused | All of it |
Why must identity checks come before any fix?
The most common attack on a service desk is a caller pretending to be an employee and asking for a reset. An agent that releases locked accounts quickly is a gift to that caller unless verification is strict and the same every time.
Verification should use something the platform or the identity system holds, not what the caller says. A one-time code sent to the registered device is strong. A manager's name and the employee's start date are weak, because both are often public. If verification fails or is unavailable, the fix is refused and the ticket goes to a person, who may know the employee.
Why is the list of fixes closed?
An agent with access to administrative tools could, in principle, attempt anything it reads about. That is the problem. Each fix on the catalogue is a defined action with a defined scope, tested and approved by the system owner. A new fix enters the list the same way a new runbook would, and only then can the agent be certified on it.
The idea of resolving at first contact is not unique to IT. The approach in resolving complaints at first contact with an AI agent follows the same logic: resolve what is routine and proven, hand over the rest with the facts gathered.
What does each ticket record?
What the user asked, in their words, and how their identity was checked.
What the agent did, step by step: which knowledge article, which fix, with which parameters, and the result returned by the target system.
The verdict for each action and the bound that decided it. A refused privileged-access request shows the refusal and the reason.
The before and after state of anything changed, such as a quota or a group membership.
Who closed the ticket and on what basis: user confirmation or the waiting period.
The agent's own record keeps a copy of all this, so tickets edited later in the platform do not erase what happened.
What should you measure?
- Reopened tickets the agent closed, by category.
- Fixes that failed or needed a person to finish.
- Recategorisations by the desk, which show where the agent misreads requests.
- Verification failures, and how many led to a confirmed attempted fraud.
- Time to resolution for agent-resolved and person-resolved tickets of the same category.
Where does it usually go wrong?
The service account has administrative rights. It is easier to give one powerful account than many narrow ones. Then the agent's bounds are the only control. Narrow the account so the target systems themselves refuse what the agent should not do.
Major incidents are worked as single tickets. Fifty users reporting the same outage each get a password reset. The agent must recognise the pattern and stop.
Knowledge articles are out of date. The agent answers confidently from an article written for the previous system. Assign owners to articles and remove any article with no owner from the agent's sources.
The platform's assurance is assumed. Your auditors will ask how the agent platform itself is controlled. A report such as the one discussed in whether an AI agent platform should have a SOC 2 report helps, but it does not cover how you configured the agent.
Depth is widened by category, not by fix. Certify each fix separately, following train, shadow, certify, widen.
Questions people ask
Can the agent reset passwords?
It can trigger a self-service reset to the registered device after verification. It should never see, set or read out a password.
What if a user insists on speaking to a person?
Hand over at once, with the ticket and everything the agent gathered. Insisting is often a sign that the request is unusual, which is exactly when a person should look.
Should the agent work outside office hours?
Out-of-hours is when it is most useful and least supervised. Keep the same bounds, and make sure escalation reaches someone on call.