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
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.
At a glance
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.
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.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
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
How often a ticket moves between teams before it's fixed. A good measure of routing quality.
ExampleDown by half
From request to working access for catalogue items, approvals included.
ExampleFrom days to hours
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
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
Post-ticket survey, split by channel, so a worse experience for people who phone is visible.
ExampleNo channel worse off
Cross-sector rules are on the UK regulation map.
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.
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.
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.
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.
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.
Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.
01Channels
02Intake
03Intelligence
04Orchestration
05Systems of record
06People
| Layer | AWS | Azure | Sovereign / 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, SQS | API Management, Event Grid, Service Bus | Kong 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 Bases | Foundry IQ, built on Azure AI Search | OpenSearch, 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 Bedrock | Microsoft Foundry | Open-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 AgentCore | Foundry Agent Service | An 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 APIs | API Management in front of read-only APIs | Kong 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 role | Logic Apps or Durable Functions, with its own managed identity | Temporal, 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 SQS | A worker inside your network pulling approved jobs from Service Bus | A 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 method | Microsoft Entra self-service password reset, Temporary Access Pass, and optionally Entra Verified ID with Face Check | Your 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 Guardrails | Foundry 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 Manager | Entra ID workload identity, Key Vault, Privileged Identity Management | Keycloak 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, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| Human reviewAnalysts and approvers work where they already do. No new screen. | In your ITSM tool | In your ITSM tool | In 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 West | Your 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 →
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.
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
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.
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.
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.
Gate · must be true to passBaseline agreed, verification process signed off by security, tool list and boundaries approved, DPIA started.
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.
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.
Self-service and routing live for everyone, access request preparation for the first catalogue items, with monitoring, support and a rollback plan.
Gate · must be true to passSupport model in place, analysts trained, logs feeding security monitoring, and the switch-off tested.
More catalogue items, joiners and leavers linked to HR events, and the same pattern for HR and facilities requests.
Gate · must be true to passEach new tool or catalogue item passes its own security review and a short shadow period.
| Activity | IT service director | Service desk manager | Solutions architectI can fill this | Technical PMI can fill this | EngineersI can fill this | SecurityI can fill this | DPO |
|---|---|---|---|---|---|---|---|
| Business case and benefits | Accountable | Responsible | Consulted | Consulted | Informed | Consulted | Informed |
| Target architecture and tool boundaries | Informed | Consulted | Accountable and Responsible | Consulted | Consulted | Consulted | Informed |
| Identity verification process for resets | Informed | Responsible | Consulted | Informed | Informed | Accountable | Consulted |
| DPIA and knowledge base data review | Informed | Consulted | Consulted | Informed | Informed | Consulted | Accountable and Responsible |
| Build and ITSM integration | Informed | Consulted | Accountable | Responsible | Responsible | Consulted | Informed |
| Prompt injection and permission testing | Informed | Informed | Responsible | Consulted | Responsible | Accountable | Informed |
| Go-live decision | Accountable | Responsible | Consulted | Responsible | Informed | Consulted | Consulted |
| Run, monitor and improve | Informed | Accountable | Consulted | Consulted | Responsible | Consulted | Informed |
R ResponsibleA AccountableC ConsultedI Informed· not involved
Option A
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
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.
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.
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.
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.
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.
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.
Changes already announced or under way that affect this design. More in the UK horizon scan.
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.
Keep the record of who approved each access change, and why, so it's clear a person made the decision.
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.
Record the cryptography used by the identity provider, the fulfilment worker and the private links, and keep it easy to change.
Good answers are specific. Vague answers to any of these are worth following up.
Whether you need someone to lead the design or to support the architect you already have, let's talk it through.