How should IT prepare for staff using their own AI agents at work?

Treat a personal AI agent the way you would treat a new member of staff who has been handed a set of keys: decide what it may touch, who answers for it, and how its actions get recorded. Blocking everything rarely works for long, so the practical goal is to make the safe route the easy route before agents arrive in numbers.

Why agents are different from chatbots

A chatbot gives someone an answer. An agent takes action: it books, sends, files, changes and deletes inside real systems, often using the person's own login. In What Stays the Same, Ian Hughes puts it simply: "The important thing about this wave of AI is not that it is cleverer. It is that it can act."

That changes the service management question. The worry is no longer only what data leaves the building in a prompt. It is what gets changed, by whom, and whether anyone can trace it afterwards. The OWASP Gen AI Security Project describes this risk as "excessive agency" and traces it to three root causes: excessive functionality, excessive permissions and excessive autonomy. Those three words make a useful checklist for any agent a user wants to connect to your systems.

Practical steps

1. Find out what is already happening. Ask teams which assistants and agents they use, and look at sign in logs and OAuth consent grants for third party apps. Ask without blame, or people will simply stop telling you.

2. Decide the categories. A short list works better than a long policy: agents you provide and support, agents people may use with personal or public information only, and agents that must not connect to company accounts at all.

3. Control consent, not just installs. Many agents work by asking the user to grant access to email, calendars or files. Requiring admin approval for new app consents, and reviewing existing grants, closes the most common back door.

4. Give every agent a named owner. Ian's line is worth putting on the wall: "You can delegate the task. You can never delegate the accountability." If an agent acts on a shared mailbox or a team folder, someone specific answers for what it does.

5. Make agent actions visible to your normal processes. A change an agent makes is still a change. In The Journey to Service Excellence, John Sansbury describes a systems team planning weekend changes that would be "user transparent" and therefore rarely raising change records, followed by incidents on Monday morning "for no apparent reason". Agents can produce exactly that pattern at much greater speed, so log what they do and connect it to your change and incident records.

6. Offer a sanctioned option. If people use personal agents because the approved tools are clumsy, the fix is a better service, not a sterner rule. Put a supported option in your service catalogue with clear guidance on what it may and may not do.

A short worked example

Picture a 300 person firm where several staff have started using a personal agent to tidy their inboxes and schedule meetings. The service desk notices calendar invitations being cancelled and recreated overnight. Rather than banning the tool, IT reviews app consents and finds a dozen grants to company mail. It keeps two, for staff who agree to a short set of rules, removes the rest, and switches on admin approval for new consents. It names the head of operations as owner for agent use on shared calendars, adds "connected AI agent" as a category in the incident form so issues are visible, and publishes a one page guide in the catalogue. Within a month the overnight calendar problems stop, and the desk has a clear way to say yes to the next request.

Common mistakes

Banning everything and assuming that ends it. Usage moves to personal devices and you lose sight of it.

Treating agents as an information security problem alone. They are also a change, incident and access problem, and they belong in your service management processes.

Automating before the underlying process works. John's guiding principle of optimise and automate warns that "A sub-optimal process that is automated may simply fail quicker or in unexpected ways." An agent bolted on to a messy approval route will simply make the mess faster.

Leaving ownership to a committee. Shared accountability usually means nobody acts when something goes wrong.

Writing a long policy nobody reads. A short, practical rule set, refreshed as tools change, does more.

Where to start

Use the Ownership and boundaries canvas (Tool 11) from the ESMi AI Enablement Toolkit, in the Exchange templates, to agree for each agent the intended outcome, the named owner, what it may do and what it must never do. For security design, the UK National Cyber Security Centre's guidelines for secure AI system development are a sound reference.

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

Tags: esm-questions, ai-agents, ai-governance, change-management, service-desk

Sources

• https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

• https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development

• https://exchange.esm.institute/templates