IT Helpdesk Agents

Deflection is not the goal; the goal is the action, and the action is the risk.

Most internal-helpdesk pilots are scoped as retrieval: index the wiki, answer "how do I connect to the VPN", report a deflection rate. That version ships in three weeks and moves almost nothing, because the tickets that consume your service desk are not questions.

• Look at your actual ticket mix before scoping. In most organisations the top categories by volume are password and MFA resets, access requests, software and licence provisioning, device problems, and onboarding/offboarding tasks. Four of those five end in a mutation of an identity system. None of them is answered by a document.
• An answer-only agent competes with search, which already exists. If the outcome of the conversation is "here is the article", the employee still has to do the work, and your deflection metric is measuring people giving up. This is the same trap that customer-support agents fall into, with the difference that internal users cannot go elsewhere and will simply stop using it.
• The value curve is discontinuous. Answering questions saves a minute of an employee's time. Completing an access request end to end saves a day of their blocked work plus a technician's context switch. There is no gradual path between those two products — the second one requires an authorisation architecture, and you either build it or you do not.
• Sequence by blast radius, not by frequency. The highest-volume action, password reset, is also the one that owns your entire estate. Start with actions that are reversible and low-privilege — licence assignment, distribution-list membership, ticket routing, status lookups — and use them to shake out the identity plumbing while the failure mode is embarrassment rather than an intrusion.

Identity proofing is the security boundary, and an agent is structurally worse at it than the technician it replaces.

A human technician runs an unwritten model of plausibility. Wrong time zone, an unfamiliar accent on a colleague they have spoken to before, an unusual urgency, a story that does not fit — none of it is in the runbook and all of it stops attacks. An agent has none of that and is optimised to be helpful to whoever is talking to it, which is the definition of a social-engineering target.

• Never proof identity conversationally. Knowledge-based questions — employee ID, manager's name, start date, last four of anything — are answered by a LinkedIn profile and an org chart. If the proofing happens inside the chat, the attacker's job is to be a convincing employee, which is the job they are already good at.
• Proof out of band, through a channel bound to a registered factor. Push to the enrolled authenticator, a signed device attestation from managed hardware, a one-time code to the number of record — the check has to be something the caller possesses, verified by a system, not something the caller knows, assessed by a model.
• Recovery of a factor may never be authorised by that factor's absence. "I lost my phone so I cannot do MFA" is both the most common legitimate request and the exact script of the attack. The only safe resolutions are a second registered factor, a video call with government ID checked by a human, or in-person verification. Route it to a person, always, and say so in the design document so nobody optimises it away in quarter three.
• Bind sensitive actions to a step-up, not to the conversation's history. Proofing at the start of a session does not authorise an action requested twenty turns later, after the context has been filled with whatever the requester chose to type. Re-challenge at the point of mutation.
• Assume the transcript is adversarial input. A helpdesk agent reads text written by whoever is asking, which is the textbook prompt injection surface, and it holds credentials to an identity provider. Nothing in a message may be allowed to widen scope, and that is an enforcement question in code rather than an instruction in a prompt.

Scope every action by entitlement, computed from systems of record, never inferred from the request.

The single most important architectural decision is that the agent does not hold administrative power and decide when to use it. It holds the ability to execute a specific action on behalf of a specific verified identity, and what that identity may obtain is derived, not judged.

• Derive the allowed action set from the identity provider and HR system at request time. Role, department, manager, employment status, location. A contractor whose end date passed yesterday must not be able to obtain anything, and the agent should not be the component that knows this — the entitlement query should return an empty set.
• Model approvals as data, not as conversation. If a request needs the manager's sign-off, the approval is a record created by the manager in a system they authenticated to. An agent that reports "your manager approved this over Slack" has invented an approval, and the audit trail needs the real one.
• Give the agent short-lived, narrowly scoped credentials per action. A token that can add a user to one pre-approved group for ten minutes is a different security posture from a service account with directory-wide write. This is the whole argument in scoped credentials for agents, and helpdesk is where it pays for itself fastest.
• Keep a hard deny-list that no entitlement can satisfy. Privileged groups, anything touching the identity provider's own administration, security tooling, finance systems, executive accounts. These are human-only forever, and encoding them as a fail-closed check means a future entitlement misconfiguration cannot open them.
• Make every mutation idempotent and logged with the identity, the evidence and the entitlement that authorised it. Retries are guaranteed — the four stacked retry sources apply here as everywhere — and a group membership added three times is a noisy log, while a licence purchased three times is an invoice.

Your knowledge base is wrong, and the ticket history is the corpus that is actually true.

Every IT organisation has a wiki, and every IT organisation knows its wiki is stale. Pointing retrieval at it produces an agent that confidently recommends the VPN client you decommissioned last year — and unlike a human technician, it has no memory of the migration to override the document.

• Resolved tickets are your ground truth. They contain the actual fix, applied recently, by someone who verified it worked. Mine the resolution notes for the top failure categories and treat those as the authoritative source, with the wiki as background.
• Attach freshness to every retrieved chunk and let the agent see it. A document last edited two years ago in an estate that migrated last quarter should be surfaced with that fact, and the agent should be instructed to prefer recent ticket evidence when they conflict. See knowledge cutoffs and time for why undated retrieval is a systematic error rather than an occasional one.
• Environment state beats documentation for anything device-specific. Before advising, read the actual configuration — OS build, agent versions, group memberships, recent changes, open incidents. "Is there an active outage on this service" is one API call and it correctly answers a large fraction of tickets that documentation cannot touch at all.
• Close the loop so the corpus improves. When a ticket the agent could not resolve is fixed by a technician, that resolution is the exact document that was missing. Route it back — an agent whose gaps feed the knowledge base gets better weekly; one that does not is frozen at launch quality.

Half of IT is physical, and the agent's job there is to be honest about it early.

Device-management actions look like ordinary tool calls and behave nothing like them. A remote wipe is irreversible. A forced reboot interrupts work. A configuration push takes effect when the device next checks in, which may be tomorrow. And a swollen battery cannot be resolved by any amount of automation.

• Treat destructive device actions as a separate privilege tier with human approval. Wipe, lock, and certificate revocation should require a second party regardless of entitlement, because the failure is unrecoverable and the legitimate urgent case — a stolen laptop — is also the attacker's cover story.
• Say when the action will actually happen. Management actions are asynchronous and eventually consistent. An agent that reports "done" when it has queued a command has lied about the only thing the user cared about. Report the queued state, then confirm on check-in.
• Recognise the unresolvable class fast and route it well. Hardware faults, physical access, anything needing a human hand on the machine. The failure mode here is a twenty-turn conversation that ends in a dispatch that could have been raised in turn two, and it is worse than no agent because it burned the user's afternoon first.
• Carry the diagnosis into the ticket. When the agent hands off, the technician should receive the device state it already pulled, what it tried, and what it ruled out. This is the same discipline as interruption and handoff: a transfer that loses the work is worse than a transfer that happens sooner.

Measure resolution and reopen rate; deflection will lie to you in the direction you want.

Deflection rate is the metric the tooling reports by default and the one that most reliably rewards a bad agent. A conversation where the employee gave up and messaged a colleague instead is counted as a success, and the shadow support economy that results is invisible to every dashboard you own.

• Verify resolution in the system of record. Was the group actually joined, the licence actually assigned, the account actually unlocked? Check the downstream state rather than the agent's claim — the outcome-versus-trajectory distinction, in a domain where the outcome is queryable and therefore has no excuse.
• Track reopen and re-contact within seven days. The same employee asking the same thing again is the truest available signal that the first resolution was cosmetic, and it is the number that correlates with what people say about the agent in private channels.
• Report escalation quality, not escalation rate. A low escalation rate on a helpdesk agent is a warning sign, not an achievement. What matters is whether the escalations arrive with context and whether the technician had to start over.
• Instrument the security path separately and review it like a control. Count identity-proofing failures, step-up challenges declined, deny-list hits, and requests that attempted to widen scope. That series is your early warning that someone is probing the agent, and it belongs in front of the security team on a schedule rather than in a quarterly review.
• Watch cost per resolved ticket, not cost per conversation. An agent that is cheap per turn and resolves nothing is expensive; the comparison that matters is against a fully loaded technician-hour, and unit economics is where that argument gets made honestly.

Related: agent identity and permissions for the ground floor, the agentic threat model for how to draw the blast radius, and security operations agents for the other half of the internal-tooling problem.