How do I safely connect an AI assistant to our help desk tickets?

Yes, you can connect an AI assistant to your help desk, but treat every ticket it reads as untrusted input and start with read only access. Give the assistant the smallest set of permissions that does a useful job, put a named person in charge of it, and only let it change tickets once you have seen it behave well on real data.

The question usually arrives in a simple form: is there a plugin, connector or MCP server that lets Claude, ChatGPT or Copilot work with our help desk? Sometimes the answer is that the platform has no public API yet, so there is nothing for a connector to sit on. When there is a route, the harder question is not whether it can be connected but what the assistant should be allowed to do once it is.

## Why ticket data needs special care

A ticket is written by whoever raised it. If an assistant reads tickets and can then act, anyone who can log a ticket can try to give it instructions. This is prompt injection, and OWASP lists it as the first risk in its Top 10 for large language model applications. The UK National Cyber Security Centre has argued that because a model does not separate data from instructions, prompt injection may never be fully mitigated in the way SQL injection can. So the design aim is to limit what a fooled assistant could do, not to hope it will never be fooled.

OWASP calls the related problem excessive agency: an assistant with more functions, permissions or autonomy than its task needs. For a service desk that means an assistant that can close, reassign or reply to tickets, or email people, when all you wanted was a summary.

## Practical steps

1. Decide the outcome first. Faster triage, better first time fixes, trend spotting for problem management or drafting knowledge articles each need very different access. Write the outcome down before choosing a tool.

2. Start read only. Let the assistant analyse an export or a reporting dataset rather than the live system. Most of the early value, such as finding repeat incidents or gaps in the knowledge base, needs no write access at all.

3. Strip what the model does not need. Remove passwords, personal data and anything confidential from what you send to an external service, and check what your licence says about how prompts and data are stored and used.

4. Use a separate, limited account. If the assistant later creates tickets, give it its own service account that can only create, through a dedicated mailbox or API scope, so its actions are distinguishable from people's.

5. Keep a human yes for anything you cannot easily undo. Closing tickets, replying to users, changing priorities and touching accounts should wait for a person to approve.

6. Log everything. Record each action with the ticket reference and what changed. If you cannot trace an action back to what prompted it, the assistant should not be allowed to take it.

7. Be open with users. If an assistant drafts replies, say so. John Sansbury makes the same point about chatbots in The Journey to Service Excellence: "Good practice is to advise the user that they are dealing with a chatbot rather than try to disguise the fact".

## A short worked example

Imagine a service desk of eight analysts that wants help with triage. In month one, a nightly export goes to the assistant, which suggests a category and priority for each new ticket and flags likely duplicates. Analysts compare its suggestions with their own. In month two, with agreement rates tracked, the assistant drafts a first reply that an analyst must approve before it is sent. The service desk manager is named as the owner, the assistant cannot close anything, and any ticket text that looks like an instruction to the assistant is flagged for review. That is a hypothetical design, not a case study, but it shows the pattern: prove value on read only data, then widen access one step at a time.

## Common mistakes

Connecting first and deciding the purpose later. John's warning applies directly: "A sub-optimal process that is automated may simply fail quicker or in unexpected ways." If your categories and routing rules are a mess, an assistant will reproduce the mess at speed. Tidy the process, then automate it.

Giving the assistant an administrator's account because it was quicker to set up.

Treating the vendor's safety claims as your controls. Vendor documentation, such as the Model Context Protocol security best practices, is useful vendor material, but the permissions and approvals are yours to set.

Leaving ownership vague. As Ian Hughes puts it in What Stays the Same, "You can delegate the task. You can never delegate the accountability." His advice is to "Name the owner before you switch the agent on."

## Next step

For more on leading AI in service teams, browse the AI enablement articles on ESM's Exchange.

If this helped, John Sansbury's The Journey to Service Excellence covers support centre management, automation and the guiding principles in depth, and is available to Exchange members. Ian Hughes's What Stays the Same explores accountability when AI can act.