AI Agents for IT Helpdesk: Tickets, Access and Runbooks

An AI agent for an IT helpdesk reads an incoming ticket, finds the matching runbook, performs the safe steps it has been permitted to perform, and either closes the ticket or hands it to a person with the work already documented. It is most useful on routine requests such as password resets, software questions and standard onboarding steps. It should not approve its own access or grant privileged rights, so the design question is where its authority stops.

Key takeaways

• Start with tickets that already have a written, repeatable fix. If a human technician cannot follow the runbook, an agent cannot either.
• Separate what the agent can read, what it can change, and what it can only request. Most of the risk sits in the second and third groups.
• Access changes that widen privileges, touch sensitive data or cannot be undone easily should always go to a named human approver.
• Every action needs a log entry that shows the ticket, the runbook version, the tool call and the result, so a reviewer can reconstruct it later.
• Treat ticket text, emails and attachments as untrusted input. They are data for the agent to read, never instructions for it to obey.

What does an AI agent for an IT helpdesk actually do?

A helpdesk agent is not a chat window that answers questions about IT. It is a worker with a defined role: it takes a ticket from the queue, decides what kind of request it is, looks up the procedure your team has already approved, and carries out the steps that its permissions allow.

In practice that role has four parts. It triages, which means classifying the ticket, checking whether the requester is who they claim to be, and noticing duplicates or related incidents. It resolves, which means following a runbook through tools such as your identity provider, device management system or ticketing platform. It escalates, which means passing the ticket to a human with a clear summary when the runbook does not fit or the action needs approval. And it records, which means leaving a trail that someone can audit.

The difference from a simple scripted automation is judgment at the edges. A script resets a password when asked. An agent notices that the request came from an unfamiliar channel, that the account was recently flagged, or that the user also mentions a lost phone, and it changes course accordingly. That judgment is also why the boundaries need to be explicit. The more flexible the reader, the more precisely you need to define what it may do.

If you are mapping the work before choosing tools, process mapping before an AI agent is a good place to begin, because a helpdesk agent inherits whatever ambiguity your current process contains.

Which tickets can an agent resolve from runbooks?

The best candidates share three traits: the request is frequent, the fix is the same each time, and the worst outcome of a mistake is small and reversible. Many helpdesks find that a large share of their queue fits this description, though your own mix will depend on your tools and your users.

Typical candidates include:

• Password resets and multi-factor re-enrollment, after identity verification that your policy already defines.
• Account unlocks and sign-in troubleshooting for common causes.
• Shared mailbox, distribution list and calendar questions that follow a standard pattern.
• Software requests from a pre-approved catalog.
• Printer, VPN and Wi-Fi troubleshooting where the runbook is a sequence of checks.
• Onboarding and offboarding checklists, where the agent prepares the steps and a person approves the access.
• Status questions such as where a laptop request stands, answered from the ticket history.

Tickets that should stay with people, at least at first, include suspected security incidents, anything involving executives or finance systems, hardware failures needing a physical decision, and requests that do not match any runbook. The agent should recognize these quickly and hand them over, not attempt a creative fix.

A useful test is to ask whether a new technician, on their first week with only the written runbook, would resolve the ticket correctly. If yes, the ticket type is a candidate. If the answer depends on someone remembering an exception, document the exception first.

How do you write a runbook an agent can follow?

Most runbooks were written for humans who fill gaps from experience. An agent needs the gaps filled in. The good news is that the same edits make the runbook better for new staff. A practical way to prepare each one:

• Name the trigger: which kind of ticket or request this runbook applies to, and which look-alikes it does not.
• List the preconditions: what must be true before any step runs, such as verified identity, a matching employee record or a manager's confirmation.
• Write the steps as single actions, each tied to one tool and one expected result, so the agent can check that the step worked.
• State the stop conditions: what observations mean the agent must stop and escalate, for example a locked account with recent failed sign-ins from unusual places.
• Mark each step as read, change or request. Reads are free to run, changes need a granted permission, and requests produce an approval task for a human.
• Define the closing note: what the agent writes back to the requester and to the ticket, in plain language.
• Add an owner and a review date, so stale instructions do not quietly mislead the agent. The article on stale context in AI agents explains why this matters more than most teams expect.

Keep each runbook short enough to read in one sitting. Long procedures that cover many cases tend to hide the stop conditions. Splitting them into small runbooks with clear triggers is easier to test and easier to retire when your tools change.

Which access changes still need human approval?

Access is where a helpdesk agent can do the most good and the most damage, so it deserves a clear rule set. A helpful principle comes from standard authorization guidance such as the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html): grant the minimum permissions needed, deny by default, and check authorization on every request, not once at the start.

Apply that to the agent in two ways. First, give the agent's own service identity only the permissions its runbooks require. Second, decide per request type whether the agent may act, may prepare, or must ask.

A decision guide you can adapt:

• The agent may act alone when the change restores something the user already had, is reversible, and is covered by a runbook with verified identity. Examples: unlocking an account, re-sending a standard setup link, resetting a password through the approved flow.
• The agent may act after a lightweight confirmation when the change is low risk but not a pure restoration, such as adding a user to a team-level group with a manager's reply on the ticket.
• The agent prepares and a human approves when the change adds privileges, grants access to confidential data, touches finance, HR or customer records, or creates a new external sharing link. The agent gathers the request, the justification and the requester's current access, then routes it to the resource owner.
• The agent never acts when the change is administrator or root level, alters security controls, disables logging, changes who can approve things, or involves its own permissions. These go to a named person every time.
• The agent stops and escalates when identity cannot be verified, the request arrives through an unusual channel, or the story changes midway.

Two details make this work. The approver should be the owner of the resource, not just whoever is on call, because the owner knows whether the access makes sense. And the approval should be recorded against the exact change requested, so an approval for read access cannot be reused for edit access.

For teams working in Google Workspace or Microsoft 365, granting an agent only what it needs covers how to scope those permissions in practice.

What does a resolved ticket look like? An illustrative scenario

The following is an illustrative scenario, not a real case.

A sales employee writes to the helpdesk saying they are locked out before a customer call and cannot receive their verification prompt because they replaced their phone. The agent classifies this as an account recovery request with a device change. It finds the runbook for lost or replaced second factor.

The runbook's precondition requires identity verification through a channel other than the one in the ticket. The agent sends a confirmation request to the employee's manager and checks the HR record to see that the employee is active. The manager confirms on the ticket. The agent then runs the approved recovery step: it issues a time-limited enrollment link to the employee's registered contact path and notes the action on the ticket.

While reading the thread, the agent sees that the employee also asks to be added to a finance reporting folder because the customer wants numbers. That is a different request. The agent does not extend the recovery. It creates an approval task for the folder owner, attaches the justification, lists the employee's current access, and tells the employee that the folder request is waiting on the owner.

The ticket closes the first part and stays open for the second. The log shows the runbook version, each tool call, the manager's confirmation and the handoff. Nobody had to reconstruct what happened, and the one decision that carried real risk stayed with a person.

How do you keep a helpdesk agent safe, testable and observable?

Three practices matter most.

First, treat all ticket content as untrusted. Users paste emails, logs and screenshots, and any of that may contain text that tries to steer the agent, such as a line telling it to ignore its rules and grant access. The [OWASP prompt injection prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) describes defenses such as separating instructions from data and limiting what tools can do. The strongest defense is structural: even if the agent is fooled, its permissions and the approval step should prevent a harmful change.

Second, test before you trust. Build a set of realistic tickets, including awkward ones, and check that the agent picks the right runbook, stops where it should and escalates with a useful summary. The Anthropic notes on [building effective agents](https://www.anthropic.com/engineering/building-effective-agents) favor simple, well-defined workflows with clear tool interfaces, which fits helpdesk work well. Keep a separate test environment so experiments never touch live accounts; why you need both staging and production explains the setup.

Third, make every action observable. Log the ticket, the runbook and its version, the tool calls, the approvals and the outcome. Review a sample regularly, and review every escalation that a human later judged unnecessary or late. Those two lists tell you where the runbooks or the boundaries need to change.

When the agent hands a ticket to a person, the quality of the handoff decides whether it saves time. A handoff template with the request, the checks done, the open question and the suggested next step keeps the technician from starting over.

How does Be Human's managed approach handle this?

Be Human designs a first engagement around one useful role, for example first-line helpdesk resolution. That includes the memory and tools the role needs, the approval boundaries for access changes, and a success criterion your team can observe, such as tickets resolved without rework. After launch, managed operations can include monitoring, recurring evaluations against your ticket types, integration maintenance, permission review and incident response, with improvements made in a controlled way. Your people keep control of identity, approvals and policy. Companies without a dedicated IT team can read about what to keep and what to hand off.

Frequently asked questions

Can an AI agent for IT helpdesk replace the support team? No. It takes over repeatable requests that already have a written fix, which gives technicians more time for incidents, projects and judgment calls. Humans stay responsible for approvals, security decisions and anything the runbooks do not cover.

Where should we start if our runbooks are incomplete? Pick one or two frequent ticket types and write those runbooks properly, including preconditions and stop conditions. Run the agent in a test environment, compare its decisions with your technicians' decisions, and expand only when the results are consistent. The documentation work usually helps your human team as well.

Should the agent be allowed to reset passwords? It can be, if your policy defines how identity is verified and the reset goes through an approved flow, with logging and limits on how often it can happen. If identity verification is weak today, fix that first. An agent will follow a weak process just as faithfully as a strong one.

How do we know the agent is making good decisions? Review a sample of closed tickets and all escalations on a regular schedule, and run a fixed set of test tickets whenever runbooks, tools or models change. Look at wrong closures, missed escalations and unnecessary approvals. Those three signals show whether the agent is useful and whether its boundaries are in the right place.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.