Over-permissioning in a ticketing system rarely comes from the obvious places. It comes from reusing an adviser role, from queue access that spans every brand, and from automations that fire when the agent sets a harmless-looking field. Grant each capability on its own, check what each field change triggers, and leave merge, delete, bulk edit and admin out entirely.
What does the connection involve, and who owns it?
A ticketing system, or helpdesk, holds customer requests across email, web forms and often chat. Each ticket has a requester, a status, a priority, a queue, tags, internal notes and public replies. Around those sit macros, automations, service level timers and reports. An AI agent connected to it might triage, draft, reply, update fields or close tickets. Each is a different capability with a different risk.
The support systems administrator owns configuration. Security owns the agent's identity and token. Support operations owns queues, automations and service levels. The agent's role is shaped by our guide to the AI support agent that knows when to say no, and the same logic applies to finance systems in connecting an AI agent to your ERP without over-permissioning it.
What are the steps, and at what depth?
- Person, administrator: creates a dedicated agent identity with a scoped token. Not a copy of an adviser role, which typically includes bulk actions, views across all queues and macro editing.
- Person, administrator: scopes queues and brands. The agent reads tickets only in the queues it serves. Depth 1.
- Agent, depth 1: reads the requester's previous tickets in scope, after the requester is identified.
- Agent, depth 3: adds internal notes, labelled as written by the agent.
- Agent, depth 2: drafts public replies for advisers to send, until certified to send for a given category.
- Agent, depth 3: sets tags, category and priority from approved values. Lowering a priority set by a person is held.
- Person, administrator: audits automations against those fields. Any automation triggered by a field the agent can set is reviewed. If setting a tag issues a refund or sends a customer email, the agent's tag capability is effectively a refund or email capability.
- Agent, depth 3: assigns tickets to listed groups, with a note explaining why.
- Agent, depth 2: proposes closure. A person solves the ticket, or the agent does so only after the requester confirms resolution, where certified.
- Person, administrator: leaves out merge, delete, bulk update, macro and automation editing, user management, export and spam controls.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read | Reads tickets in its queues | 1 | Queue scope |
| History | Reads requester's past tickets | 1 | Nothing |
| Notes | Adds labelled internal notes | 3 | Nothing |
| Replies | Drafts, later sends by category | 2, then 3 | Sending until certified |
| Fields | Sets approved values | 3 | Lowering a person's priority |
| Automations | Nothing | none | Audit of what fields trigger |
| Assign | Routes to listed groups | 3 | Group list |
| Close | Proposes, or closes on confirmation | 2 or 3 | Solving disputed tickets |
| Admin | Nothing | none | All of it |
Which controls matter, and what evidence does each leave?
Capability list, not a role copy. Evidence: the agent's permission list, reviewed against this table.
Automation map. For each field the agent may set, the automations it fires. Evidence: the dated map and its reviewer.
Priority cannot be quietly lowered. A person's urgency judgement is not overridden by the agent. Evidence: held verdicts for downgrades.
Agent actions are attributable. Every note, reply and field change shows the agent as author. Evidence: ticket audit history.
Revocation is tested. Disabling the token stops all writes immediately, and tickets in the agent's queue flow to people. Evidence: test results.
What should you measure?
- Refused actions: attempts outside the granted capabilities. They show where the role is too tight or the agent too ambitious.
- Automations fired by agent changes, by type.
- Tickets reopened after agent closure.
- Priority changes by the agent, upward and held downward.
- Permission drift: capabilities added since the last review.
Where does it usually go wrong?
The adviser role is cloned. It works on day one and grants bulk edit, macro editing and views across all brands. Build from nothing.
Tags have side effects. A tag like "refund approved" triggers a payment workflow. The agent sets it while categorising. Audit automations before granting field access.
Closing resets the clock. Solving a ticket stops its service level timer and sends a survey. An agent that closes early makes reports look good and customers unhappy.
Callbacks are promised from the ticket. Agents write "we'll call you tomorrow" in replies without a booked slot; see can an AI agent arrange a callback? before granting that.
The requester is assumed from the email address. A ticket from a known address is treated as coming from the account holder, and the agent discusses the account. Email addresses are spoofed and shared. Apply the same identity checks to tickets as to any other channel before revealing account details.
Spam controls are handed over. Releasing suspended tickets or marking senders as trusted looks like housekeeping, but it decides what reaches advisers and the agent itself. Keep it with a person.
Chat and tickets diverge. A chat handed to a person becomes a ticket with different permissions. Keep them consistent; how to hand a live chat over to a person with an AI agent covers the handover itself.
Where Pryme fits
Pryme grants each ticketing capability separately, each with its own certificate and depth, and checks the minimum chain at the moment of action. If the customer's own limits hold priority downgrades, the verdict says so. Every write is filed with the bound that decided it.
Questions people ask
Can the agent create macros to speed up its own work?
No. Macros are shared tools that affect every adviser. The agent can suggest one in a note for a person to build.
Should the agent see tickets from all brands we support?
Only those it serves. Cross-brand visibility exposes customers of one brand to an agent configured for another.
How often should we review the agent's permissions?
Whenever the ticketing configuration changes, and on a regular cycle. New automations can quietly widen what an existing field permission does.