The short answer: Shadow AI governance means making AI use visible and accountable. When an AI agent becomes part of a team’s work, it needs a named owner, documented access to data and systems, controlled changes, a way to report failures and a measure of its value. ITIL 5 now includes AI governance guidance, which gives IT teams a familiar way to approach this.
Listen to a 3-minute summary
A sales team builds an AI agent to prepare first drafts of customer proposals. At first, one team member uses it, checks every result and decides what goes to the customer.
Then a colleague asks to try it. Soon the whole team uses it. The agent gains access to more documents and customer information. Proposal preparation becomes faster, and the team starts planning its work around it.
At what point did a useful experiment become something the business depends on?
From personal experiment to shared AI agent
People closest to a task often know exactly where the work gets stuck. Today, they can use readily available tools to connect an AI model to documents and workflows and build an agent that helps. They may not need to wait for a formal IT project to test the idea.
That speed can produce something genuinely useful. It also means an agent may become important before anyone has decided how to manage it.
A proposal agent used by its creator is different from one used by an entire sales team. Once colleagues rely on it, its output affects more decisions. It may need access to shared systems. Someone else may edit its instructions. If the agent produces an incorrect proposal, more people may encounter the mistake before it is caught.
This shift is already visible in workplace research. In Microsoft’s 2025 Work Trend Index, 46% of leaders surveyed said their companies were using agents to fully automate workflows or processes, and 81% expected agents to be moderately or extensively integrated into their company’s AI strategy within the following 12–18 months. The first figure reflects what leaders reported was happening; the second describes their expectations.
The question for an IT leader is therefore changing. Alongside “Can we build an agent?” comes “Which agents have become part of our operations, and who is responsible for them?”
What is shadow AI governance?
Shadow AI is AI used for work without sufficient organisational knowledge or oversight. It might be an employee using an unapproved chatbot. It might also be one of the shadow AI agents built for a legitimate team need but never recorded as part of a business process.
An employee-built agent is not automatically a problem. It may reveal a task that should have been improved long ago. The problem is the visibility gap: if nobody knows what the agent can access, who uses it or who looks after it, the organisation cannot reliably support it or judge its risk.
IBM’s 2026 Cost of a Data Breach Report examined 602 organisations that experienced data breaches between March 2025 and February 2026. Among those organisations, 68% had no AI governance to manage AI or detect shadow AI, up from 63% a year earlier. The share reporting security incidents involving shadow AI rose from 20% to 43%. These findings describe organisations in IBM’s breach study; they are not rates for all businesses.
A policy can set expectations. To govern an agent people actually use, someone must also answer practical questions about that specific agent.
What are the risks of shadow AI agents?
The main risk is not that employees experiment with AI. It is that an agent can become part of an important workflow without the organisation understanding what it can access, what it can do or who is responsible when something goes wrong.
- Sensitive data exposure. An agent may use customer, employee or company information in tools or models that have not been reviewed.
- Unclear ownership. The person who created an agent may not be responsible for the business process that has started to depend on it.
- Uncontrolled access and actions. An agent may gain broader permissions or begin taking actions rather than only preparing recommendations.
- Operational dependency. A team may rely on an agent without documented support, change control, monitoring or a human fallback.
Five questions for any AI agent the business relies on
| Question | What the answer should establish |
|---|---|
| Who owns it? | A named person accountable for its purpose, users and continued use, even if someone else built it. |
| What can it access and do? | The data it reads, the systems it connects to and whether it suggests actions or takes them. |
| Who approves changes? | Who reviews changes to instructions, models, data connections and permissions. |
| What happens when it gets something wrong? | How users report a problem, who investigates and when the work returns to a person. |
| How do we measure its value? | A baseline and a useful measure, such as time per task, turnaround time or error rate. |
Consider the difference between an agent that drafts an email and one that sends it. Both need an owner and appropriate access. But the second can affect a customer before a person sees the result. It needs tighter limits and a clear way to stop or correct its actions.
The five questions apply to both agents, but the answers will lead to different controls. A meeting-notes assistant should not have to pass the same approvals as an agent that changes customer records. At the same time, an agent with broad access should not be treated as harmless because it began as a small experiment.
Gartner made the same point in May 2026. It warned that applying uniform governance to all AI agents, regardless of their autonomy and scope of access, can lead to enterprise AI agent failure, and recommended matching AI agent governance to each agent’s level of autonomy.
Where should AI agent governance live?
Once agents become part of normal work, information about them needs to be available beyond the person who created them. Teams should be able to find out which agents exist, who owns them, what systems they connect to and how to request a change or report a problem.
For many organisations, existing IT service management provides a practical foundation:
- A service catalogue gives employees a route to request an approved AI tool or propose a new agent.
- A CMDB or another maintained AI agent registry records an agent, its owner and its connections to other systems.
- Change management defines which updates need review before they affect users.
- Incident management gives people a way to report incorrect outputs or actions and get help.
- Service reporting makes an agent’s value and ongoing performance visible.
A register is useful once an agent is known. It will not, by itself, discover every agent teams have built. Security teams also need visibility into unsanctioned AI tools and an understanding of where company data goes. Discovery helps find AI use; service management helps the organisation take responsibility for it.
RixMind combines AI delivery and service management experience to help organisations move useful AI agents from informal experiments into governed business workflows.
For organisations using ManageEngine, ServiceDesk Plus can support the catalogue, CMDB, change and incident processes needed to manage AI agents. RixMind helps teams implement the platform and adapt these processes to the way they work: explore ManageEngine with RixMind.
What this looks like in our own work
At RixMind, we use AI agents in daily work, including commercial proposal preparation and public tender evaluation.
Proposal preparation
2–3 days → 2–4 hours
Our proposal agent helps prepare proposal packages. A person still reviews and signs off every document before it goes out.
Tender evaluation
3–5 hours → 20–40 minutes
Our tender evaluation agent helps read and assess public tenders. The recorded time includes human review.
These are results from our own recorded workflows, with human review, not a promise that every organisation will see the same savings. The agents help people get to a decision faster, while people remain responsible for the decision and the external output. That review point is part of the workflow.
Give teams a way to build agents properly
Registration alone will not solve shadow AI. If a team has a good idea but the only official response is a long queue, the team has little reason to bring that idea forward.
A workable route should let employees propose an agent, explain the problem it will solve, check the data and systems it needs, and find people who can build or review it. When the agent is ready for wider use, it should be handed over with an owner, clear limits and a way to measure whether it helps.
Some organisations can do all of this internally. For others, worthwhile AI projects arise too irregularly to justify a permanent delivery team. RixMind AI On Demand provides a way to scope and deliver projects as needs arise, with ownership, review points and measurement considered from the start.
Teams that want to strengthen their shared service management practices can also explore RixMind’s ITIL 5 training for teams. Training helps people work from the same principles; the organisation must still decide how those principles apply to each agent. To see what changed in the framework, read ITIL 5: what changed and why it matters.
How to start governing AI agents in 30 days
You do not need to identify every AI tool in the organisation before taking the first step. Choose an agent that several people already use, especially one connected to customer information or an important process.
- Week 1: discover. Ask teams which agents they use, what those agents help with and which systems they connect to. Combine those conversations with the technical visibility your security team already has. Make it easy for people to disclose useful experiments without treating every disclosure as a problem.
- Week 2: classify. Separate agents that draft or recommend from agents that take actions. Prioritise those with access to sensitive information or the ability to change records.
- Week 3: register. Choose one valuable agent and answer the five questions. Name its owner and document its access, change route and human fallback.
- Week 4: measure and share the route. Agree how to judge its value and when to review it. Show other teams how to request an approved tool or bring forward an idea for a new agent.
The first month establishes a working approach; it will not bring every AI use under governance. Repeat the process for the next agent and improve it as you learn.
Frequently asked questions
Is every employee-built AI agent shadow AI?
No. An agent built by an employee can be approved and well managed. It becomes shadow AI when the organisation lacks sufficient visibility or oversight of its use, access or ownership.
Does every AI agent need to be in the CMDB?
An organisation needs a maintained record of agents used in shared or important workflows. A CMDB may be a practical home for that record when the organisation already uses one. A personal experiment with no shared access may need a lighter approach.
Who should own an AI agent?
The business area that relies on its work should have a named person accountable for its purpose and value. IT and security help manage its technical operation, access and risks. The responsibilities should be clear for each agent.
Can we govern AI agents without slowing teams down?
Yes, if the process reflects what an agent can access and do, and gives teams a usable way to get help. Start with agents people already depend on. Apply more review where an agent has greater access or autonomy.
Can ManageEngine ServiceDesk Plus help manage AI agents?
It can support the service management parts of the work: recording agents and their relationships, handling requests, reviewing changes and managing incidents. The full set of controls an agent needs depends on its connections, permissions and configuration.
Bring us one AI agent your team already uses
We’ll help you identify its owner, access, risks, change process and a practical next step.