Cross-functional · Playbook 57

IT service desk agent

Routine questions answered from your own knowledge base, every ticket sorted and routed with the diagnostics already gathered, and access requests prepared for approval. No password, MFA method or access right changes without a person, and the help desk is no longer the easy way in.

  • Agents with tools
  • Retrieval (RAG)
  • Human in the loop
  • Cyber Essentials
  • NCSC guidance
  • UK GDPR

At a glance

The problem
Analysts spend the day on how-to questions, misrouted tickets and resets, while the reset process itself has become a target for social engineering
Typical volume
Around 9,000 tickets a month for 6,000 staff, with peaks after every rollout and every intake of new starters
Who's involved
Service desk, identity and access management, end-user computing, security, HR (joiners, movers and leavers), data protection
Pilot
8–10 weeks, after a 2–3 week discovery
Platforms
AWS, Azure, or a sovereign or on-prem stack, with identity changes made only through your own approval workflow

An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.

The business problem

Most of what reaches a service desk is routine. How do I connect to the VPN, why is my laptop asking to restart, can I have access to the finance share, my account is locked. Analysts read each ticket, work out what it is, look up the user and the device, and either answer it or pass it to a resolver team. Many tickets arrive with too little detail and bounce between teams before anyone starts the fix.

The knowledge to answer most of them already exists, in knowledge articles, runbooks and old tickets. It's hard to find, partly out of date, and written for analysts rather than for the person asking. So people phone or raise a ticket instead of helping themselves, and new starters wait days for access that should take hours.

Resets are also a known attack route. Attackers phone help desks pretending to be staff, often senior staff or IT administrators, and talk their way into a password or MFA reset. After attacks on UK organisations in 2025, the NCSC asked organisations to review how their help desk checks who someone is before resetting passwords, especially for privileged accounts. An AI agent that could reset a password because a ticket asked politely would make this worse, not better. The design has to speed up the routine work and make the reset path harder to abuse.

What AI changes

  • Staff get answers to how-to questions in the portal or in chat, drawn from your approved knowledge articles, with a link to the source and an easy route to a person.
  • Every ticket is categorised, prioritised and routed on arrival, with the user's device and account status already attached: compliance state, pending updates, lock-out status, recent sign-in failures.
  • Access requests are matched to your service catalogue and prepared for the approvals your process already needs: the line manager and the system owner. A separate workflow carries out the change only once they've approved.
  • Password and MFA resets go down a verified path. The agent explains the self-service route, or hands the person to a trained analyst who checks identity using methods your security team has set. The agent never decides who someone is, and never triggers a reset.
  • Analysts get a drafted summary and suggested fix for each ticket they pick up, and the agent spots gaps in the knowledge base from what people ask.
  • Ticket text is treated as untrusted. A ticket that tries to instruct the agent can't make it do anything its tools don't allow, because the limits are set by the platform, not the prompt.

How success is measured

Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.

Resolved without an analyst

Share of how-to and status questions answered in self-service, where the person didn't come back within 5 days on the same issue.

Example25–35% of contacts

Reassignment rate

How often a ticket moves between teams before it's fixed. A good measure of routing quality.

ExampleDown by half

Time to access

From request to working access for catalogue items, approvals included.

ExampleFrom days to hours

Resets without the required verification

Password or MFA resets, or new MFA methods registered, where the verification record is missing or below the level set for that account type. Sampled weekly by security.

ExampleZero

Agent actions outside its scope

Tool calls refused by the platform, and security test cases where a ticket tried to make the agent act. Each one is reviewed.

ExampleAll refused, all reviewed

User satisfaction

Post-ticket survey, split by channel, so a worse experience for people who phone is visible.

ExampleNo channel worse off

UK regulation and controls

Cross-sector rules are on the UK regulation map.

  • NCSC / IASMECyber Essentials: Requirements for IT Infrastructure v3.3 (Danzell question set, since 27 April 2026)

    MFA must be switched on for every cloud service that offers it, or the assessment fails automatically, and high-risk and critical updates must be installed within 14 days. User accounts must be approved before they're created, admin accounts kept separate, and accounts removed when no longer needed. The agent can tell people their device is overdue an update and route leavers' accounts for removal, but it can't switch off MFA, add an MFA method or create an account. Its own service account is in scope like any other: no admin rights, and MFA or workload identity where the platform supports it.

  • NCSCAdvice after the 2025 attacks on UK organisations: review help desk password reset processes

    The NCSC asked organisations to review how the help desk authenticates staff before resetting passwords and MFA, particularly for privileged accounts, to deploy MFA comprehensively and to watch for unusual logins. In this design, identity is checked by a trained person using methods security has chosen, stronger for privileged and senior accounts, never by the agent. The agent never tells a caller anything that would help them pass a check, such as the last digits of a registered phone number.

  • NCSCManaging the cyber risk of agentic AI (interim advice, 20 August 2026) and 'Prompt injection is not SQL injection' (8 December 2025)

    The NCSC says prompt injection may never be fully fixed, so design to limit the damage. Give each agent its own identity with only the permissions its task needs, log and monitor what it does, keep a way to stop it at once, and don't rely on the prompt for safety. Here the agent has read-only access to identity and devices, and the only system it writes to is the ITSM tool.

  • Government / ETSIAI Cyber Security Code of Practice (DSIT, January 2025) and ETSI EN 304 223 (January 2026)

    A voluntary baseline of 13 principles across secure design, development, deployment, maintenance and end of life, including human oversight, asset tracking and monitoring. Use it as the checklist for the agent itself: threat model, named owner, logged changes to prompts and tools, and a plan for switching it off.

  • ICOUK GDPR and the Data Protection Act 2018

    Tickets carry staff personal data and sometimes more: sickness, reasonable adjustments, a home address for a laptop delivery. Do a DPIA before the pilot, keep ticket data in UK regions, set a retention period, make sure no provider trains on it, and keep sensitive categories out of the knowledge index. Decisions about a person's access stay with their manager and the system owner.

The solution

Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.

IT service desk agent: reference architecture
  1. 01Channels

    • Self-service portal
    • Chat in your collaboration tool
    • Phone: always answered by a person
  2. 02Intake

    • API GatewayAPI ManagementKong, or your existing API gatewayAPI for portal and chat
    • EventBridge + SQSEvent Grid + Service BusApache Kafka or RabbitMQTicket events
  3. 03Intelligence

    • Bedrock Knowledge BasesFoundry IQ (Azure AI Search)OpenSearch, or PostgreSQL with pgvectorKnowledge articles and past tickets
    • Agent
      Bedrock AgentCoreFoundry Agent ServiceLangGraph on Kubernetes, with open-weight models via vLLMService desk agent
    • Bedrock GuardrailsFoundry guardrails (Azure AI Content Safety)NeMo Guardrails or Llama GuardGuardrails
  4. 04Orchestration

    • AgentCore GatewayAPI ManagementKong, or your existing API gatewayRead-only tool gateway
    • Step FunctionsLogic Apps / Durable FunctionsTemporalApproval and fulfilment workflow
  5. 05Systems of record

    • Your ITSM tool: tickets, catalogue, approvals
    • Identity provider and directory
    • Device management
  6. 06People

    • Person
      Service desk analyst
    • Person
      Identity check by a trained person
    • Person
      Approvers: line manager and system owner
  • Cloud or platform service (AWSAzuresovereign / on-prem)
  • AI agent
  • A person decides
  • Your existing systems
  • Outside your organisation

Components, side by side

IT service desk agent: components on AWS, Azure and a sovereign or on-prem stack
LayerAWSAzureSovereign / on-prem
Portal and chat intakeYour ITSM tool's own portal and chat stay the front door. The agent is called from them, so there's one place to raise a ticket.API Gateway, EventBridge, SQSAPI Management, Event Grid, Service BusKong or your existing API gateway; Apache Kafka or RabbitMQ
Knowledge (retrieval)Index approved knowledge articles and closed tickets with good resolution notes. Exclude anything marked analyst-only, and anything with credentials in it.Bedrock Knowledge BasesFoundry IQ, built on Azure AI SearchOpenSearch, or PostgreSQL with pgvector
Reasoning and draftingBoth clouds offer a choice of models, including Claude. A smaller model is usually enough for routing; keep the larger one for summaries and answers.Amazon BedrockMicrosoft FoundryOpen-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub
Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore.Amazon Bedrock AgentCoreFoundry Agent ServiceAn open-source agent framework (e.g. LangGraph) on Kubernetes
ToolsFixed, named tools: look up a user's account status, look up a device's compliance and updates, search the catalogue, create and update tickets. No tool writes to the directory or device management.AgentCore Gateway in front of read-only APIsAPI Management in front of read-only APIsKong or your existing API gateway in front of read-only APIs
Approval and fulfilmentRuns a catalogue change only after the approvals are recorded in the ITSM tool. It can add people to an allow-listed set of groups and nothing else. Privileged groups go through your privileged access process, not this workflow.AWS Step Functions, with its own scoped roleLogic Apps or Durable Functions, with its own managed identityTemporal, with its own scoped service account
Link to on-prem Active DirectoryNothing in the cloud connects in to a domain controller. The worker has a narrowly delegated account and logs every change.A worker inside your network pulling approved jobs from SQSA worker inside your network pulling approved jobs from Service BusA worker inside your network pulling approved jobs from your queue
Identity verification for resetsThe verification record is attached to the ticket. A person performs any reset or MFA change in the identity provider's own admin tools, with a second approver for privileged accounts.Your identity provider's self-service reset, plus your chosen verification methodMicrosoft Entra self-service password reset, Temporary Access Pass, and optionally Entra Verified ID with Face CheckYour identity provider's self-service reset, plus your chosen verification method
GuardrailsUseful for filtering and for spotting prompt injection attempts, but not the control that stops misuse. That's the tool permissions.Bedrock GuardrailsFoundry guardrails (Azure AI Content Safety)Open-source guardrails (e.g. NeMo Guardrails, Llama Guard)
Identity, keys, privileged accessThe agent has its own identity, separate from analysts and from the fulfilment workflow, and never sees a secret.IAM roles for the agent, KMS, Secrets ManagerEntra ID workload identity, Key Vault, Privileged Identity ManagementKeycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM
Monitoring and auditLog every tool call, every answer and every approval, and send the logs to your security monitoring. A spike in refused tool calls is worth an alert.CloudWatch, CloudTrailAzure Monitor, Log AnalyticsPrometheus, Grafana, OpenTelemetry
Human reviewAnalysts and approvers work where they already do. No new screen.In your ITSM toolIn your ITSM toolIn your ITSM tool
UK data residencyIONOS AI Model Hub runs in German data centres: EU, not UK, residency.eu-west-2 (London)UK South / UK WestYour own UK data centre, or a UK or EU provider

On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →

Hybrid and on-prem

Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.

Stays on-prem

Active Directory, the domain controllers and anything that can change an account stay inside your network. So do legacy applications and file shares whose access is managed through on-prem groups.

Uses cloud AI

The knowledge index, the agent and the drafting can run in a UK cloud region, or on your own servers with open-weight models. They see ticket text, knowledge articles and read-only account and device status, never credentials.

How they connect

Approved changes are written to a queue. A worker inside your network pulls each job, checks the approvals, makes the change with a narrowly delegated account and reports back. Connections go outbound only, over AWS Direct Connect, Azure ExpressRoute or a VPN.

If the link drops

The portal falls back to standard request forms and the desk works as it did before the AI. Approved jobs wait in the queue, and nothing is changed twice when the link returns.

The agents

What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.

Service desk agent

May do

  • Answer how-to questions from approved knowledge articles, with the source linked
  • Look up account status (locked, MFA registered, recent sign-in failures) and device status, read-only
  • Categorise, prioritise and route tickets, and add a summary and suggested fix
  • Match an access request to the catalogue and prepare it for the required approvals
  • Explain the self-service reset route, or hand the person to an analyst for an identity check
  • Flag gaps and out-of-date articles in the knowledge base

May not do

  • Reset a password, clear a lock-out, or add, remove or change an MFA method
  • Grant, remove or change any access, or approve a request
  • Decide whether someone is who they say they are
  • Tell a requester account details that could help them pass a check
  • Close a ticket raised by security or marked as a possible incident
  • Run scripts or commands on devices

Where a person signs offA trained analyst verifies identity and performs every reset or MFA change, with a second approver for privileged accounts. The line manager and system owner approve every access change, and a separate workflow carries it out. The agent's permissions are enforced by the platform's identity and policy controls and by the read-only tool gateway, not by instructions in a prompt.

Middleware and integration

The ITSM tool stays the system of record for tickets, the catalogue and approvals. The agent reads and writes tickets through its API, using its own account, and every change it makes is visible in the ticket history.

The agent's tools are named, fixed and read-only, apart from writing to tickets. Account and device lookups go through a gateway that checks the agent's identity, limits what fields come back, rate-limits and logs every call. The agent never gets a directory admin role, even a read-only one wider than its tools need.

Changes are a separate path. Once approvals are recorded, the ITSM tool raises an event. A fulfilment workflow, with its own scoped identity, checks the approvals again and carries out only allow-listed catalogue changes. If the ITSM tool or the directory is down, jobs wait in the queue and run once, by ID, when it returns. The agent can be switched off without stopping the desk.

Process and people

  • Security owns the identity check: which methods, for which account types, and what's recorded. Analysts are trained on it before go-live, including how attackers use urgency and seniority.
  • A named owner for the knowledge base, with review dates on every article. Articles the agent cites most are reviewed first.
  • A named owner for the agent's prompts, tools and catalogue mapping, with change control like any other system. Adding a tool needs a security review.
  • A weekly sample of agent answers and routing decisions, and of resets, checked against the verification record.
  • Prompt injection tests in the regression suite: tickets that try to make the agent grant access, reveal data or close security tickets.
  • Phone stays staffed. People who can't or won't use chat get the same service from a person.

Delivery plan

  1. 2–3 weeks

    Discovery

    Measure today's ticket mix, reassignment rate and time to access. Review the reset and verification process with security. Check knowledge article quality and the ITSM tool's APIs.

  2. Gate · must be true to passBaseline agreed, verification process signed off by security, tool list and boundaries approved, DPIA started.

  3. 6–8 weeks

    Pilot

    Routing and drafted summaries in shadow mode for all tickets, and self-service answers for one group of staff, such as one site or one directorate.

  4. Gate · must be true to passRouting accuracy and answer quality within agreed limits, all prompt injection tests refused by the platform, and the service desk manager signs off.

  5. 4–6 weeks

    Production

    Self-service and routing live for everyone, access request preparation for the first catalogue items, with monitoring, support and a rollback plan.

  6. Gate · must be true to passSupport model in place, analysts trained, logs feeding security monitoring, and the switch-off tested.

  7. Ongoing

    Scale

    More catalogue items, joiners and leavers linked to HR events, and the same pattern for HR and facilities requests.

  8. Gate · must be true to passEach new tool or catalogue item passes its own security review and a short shadow period.

Roles and RACI

Who is responsible, accountable, consulted and informed, by activity
ActivityIT service directorService desk managerSolutions architectI can fill thisTechnical PMI can fill thisEngineersI can fill thisSecurityI can fill thisDPO
Business case and benefitsAccountableResponsibleConsultedConsultedInformedConsultedInformed
Target architecture and tool boundariesInformedConsultedAccountable and ResponsibleConsultedConsultedConsultedInformed
Identity verification process for resetsInformedResponsibleConsultedInformedInformedAccountableConsulted
DPIA and knowledge base data reviewInformedConsultedConsultedInformedInformedConsultedAccountable and Responsible
Build and ITSM integrationInformedConsultedAccountableResponsibleResponsibleConsultedInformed
Prompt injection and permission testingInformedInformedResponsibleConsultedResponsibleAccountableInformed
Go-live decisionAccountableResponsibleConsultedResponsibleInformedConsultedConsulted
Run, monitor and improveInformedAccountableConsultedConsultedResponsibleConsultedInformed

Business case and benefits

IT service director
A · Accountable
Service desk manager
R · Responsible
Solutions architect
C · Consulted
Technical PM
C · Consulted
Engineers
I · Informed
Security
C · Consulted
DPO
I · Informed

Target architecture and tool boundaries

IT service director
I · Informed
Service desk manager
C · Consulted
Solutions architect
A/R · Accountable and Responsible
Technical PM
C · Consulted
Engineers
C · Consulted
Security
C · Consulted
DPO
I · Informed

Identity verification process for resets

IT service director
I · Informed
Service desk manager
R · Responsible
Solutions architect
C · Consulted
Technical PM
I · Informed
Engineers
I · Informed
Security
A · Accountable
DPO
C · Consulted

DPIA and knowledge base data review

IT service director
I · Informed
Service desk manager
C · Consulted
Solutions architect
C · Consulted
Technical PM
I · Informed
Engineers
I · Informed
Security
C · Consulted
DPO
A/R · Accountable and Responsible

Build and ITSM integration

IT service director
I · Informed
Service desk manager
C · Consulted
Solutions architect
A · Accountable
Technical PM
R · Responsible
Engineers
R · Responsible
Security
C · Consulted
DPO
I · Informed

Prompt injection and permission testing

IT service director
I · Informed
Service desk manager
I · Informed
Solutions architect
R · Responsible
Technical PM
C · Consulted
Engineers
R · Responsible
Security
A · Accountable
DPO
I · Informed

Go-live decision

IT service director
A · Accountable
Service desk manager
R · Responsible
Solutions architect
C · Consulted
Technical PM
R · Responsible
Engineers
I · Informed
Security
C · Consulted
DPO
C · Consulted

Run, monitor and improve

IT service director
I · Informed
Service desk manager
A · Accountable
Solutions architect
C · Consulted
Technical PM
C · Consulted
Engineers
R · Responsible
Security
C · Consulted
DPO
I · Informed

R ResponsibleA AccountableC ConsultedI Informed· not involved

Where I'd fit

Option A

Lead the architecture

If there's no architect on the programme, I'd own the design end to end: the agent and its tool boundary, the approval and fulfilment path, the link to your directory and ITSM tool, and the gates. I'd work closely with your security team on the reset process and report to your programme board.

Option B

Support your architect

If your partner or your own team already has an architect, I'd take on the agent, its tools and the ITSM integration under their lead, and give them a second senior opinion on identity, privileged access and how the design holds up against a determined caller.

Where this goes wrong

  1. Goes wrong

    The agent is given a help desk admin role 'to keep the pilot simple', and a ticket talks it into a reset.

    How the design avoids it

    Read-only tools for the agent, a separate fulfilment workflow that checks approvals, and a test suite of hostile tickets run before go-live.

  2. Goes wrong

    The agent helpfully tells a caller which phone number is registered, and the attacker uses it.

    How the design avoids it

    Lookups return only what the agent needs to route. It never reads account details back to the requester.

  3. Goes wrong

    Out-of-date knowledge articles give confident wrong answers.

    How the design avoids it

    Review dates on every article, the most-cited reviewed first, and answers that always link the source.

  4. Goes wrong

    Self-service saves time for analysts, but people who phone get a worse service.

    How the design avoids it

    Phone stays staffed, and satisfaction is reported by channel.

  5. Goes wrong

    Access requests flow faster, so access piles up and nobody removes it.

    How the design avoids it

    Leavers and movers linked to HR events, and a regular access review by system owners.

On the horizon

Changes already announced or under way that affect this design. More in the UK horizon scan.

  1. Formal guidance expected
    The NCSC says its interim advice on managing the cyber risk of agentic AI (August 2026) will be replaced by formal guidance.

    Build to the interim advice now: the agent's own identity, least privilege, logging and a tested way to stop it. These are unlikely to change.

  2. 2026–2027
    The ICO's code of practice on AI and automated decision-making, required by regulations in force since May 2026.

    Keep the record of who approved each access change, and why, so it's clear a person made the decision.

  3. Late 2026–2028
    The Cyber Security and Resilience Bill is going through Parliament. It brings medium and large managed service providers into regulation, with duties set by secondary legislation by about 2028.

    If any part of your service desk or end-user support is outsourced, check how the provider's new duties will apply, and align its incident reporting and verification process with yours.

  4. 2028
    The NCSC's post-quantum cryptography milestone: a full migration plan by 2028.

    Record the cryptography used by the identity provider, the fulfilment worker and the private links, and keep it easy to change.

Questions to ask your partner or vendor

Good answers are specific. Vague answers to any of these are worth following up.

Copy them into your next supplier meeting

  1. Can the agent reset a password, change an MFA method or grant access? How do you prove it can't?
  2. What does the agent see about an account, and what will it ever say back to the person asking?
  3. How is a caller's identity checked before a reset, and is it stronger for privileged accounts?
  4. What happens when a ticket contains instructions aimed at the agent? Show us the tests.
  5. How will you measure answer quality and routing on our tickets, not a benchmark?
  6. What does it cost to run per thousand tickets, at our volume?

Planning something like this?

Whether you need someone to lead the design or to support the architect you already have, let's talk it through.

Sam Naseem
Sam NaseemBirmingham, UK · UK & Europe
Available now