Consider a sales team using an agent to prepare proposals. One employee connected it to the customer system and wrote the instructions. Six months later, that employee has changed roles. Who now knows what the agent can access and who should maintain those instructions?
This is the practical concern behind agent sprawl. Teams keep adding agents and integrations, but the organisation loses track of them. As with shadow IT, useful local tools can become difficult to oversee.
From useful shortcut to invisible risk
Shadow IT is technology used outside the organisation’s agreed set-up and out of its sight. It emerged because teams wanted to move faster than central IT could deliver. They started using their own tools, spreadsheets, cloud apps and automations, often with good intentions and real productivity gains. But over time, questions appeared.
- Who has access?
- Where is the data stored?
- Which version is the source of truth?
- What happens when someone leaves?
- Who steps in when something goes wrong?
AI agents add new questions. You need to know which actions an agent may perform on its own, which sources it uses to prepare decisions and which instructions and permissions shape its behaviour. It also has to be clear who reviews the result, who deals with errors and how you check that the agent still does what it was meant to do.
Conventional business software can also change records or send messages. With an AI agent, you must also consider how much discretion the model has to choose its next step. Its permissions, data access and permitted actions need to be explicit.
Why agent sprawl happens so quickly
AI agents are attractive because they sit close to the work and solve a concrete, everyday problem. So the risk also feels small. But agents are rarely used in isolation. They get access to documents, mailboxes, customer systems, project tools or databases. They are connected to other workflows. Their instructions shape the choices they make. And they produce results that people begin to trust.
Before long, the organisation has dozens of small AI initiatives running side by side. That need not be wrong, but it leaves the organisation exposed if nobody sees the whole picture.
Who takes responsibility when things change?
Teams need room to experiment without a lengthy approval process for every small change. Someone must still take responsibility for the application: reviewing changes to its purpose and access, following up on problems and retiring it when it is no longer needed. A name in a register is useful only if that person has the time and authority to act.
What organisations need
Rules for managing and using agents do not have to start heavy or bureaucratic. If they become too heavy, people will work around them, and you recreate the problem you were trying to prevent.
A practical foundation starts with a few simple agreements.
-
Make agents visible. Start with a register that records which agents exist, what they are used for, which systems they can access and who is responsible for them.
-
Define ownership. Every agent needs a named owner who is responsible for its purpose, behaviour and risks. A technical contact is not enough.
-
Limit access deliberately. An agent should not receive more permissions than it needs, and certainly not broad access to mailboxes, drives or customer data “just to make things easier”.
-
Log important actions. If an agent retrieves information, prepares decisions or performs actions, you want to be able to see what happened afterwards. Record what you need for that review, and agree who can see it and how long it is kept.
-
Review periodically. Agents change along with processes, data and teams. What is valid today may be outdated three months from now.
-
Retire agents that are no longer needed. Temporary experiments can stay temporary. Cleaning up is part of normal use.
Make support easy to access
With classic shadow IT, IT was often seen as the brake. With AI agents, the need to experiment is strong and the technology is moving fast. What helps teams most is support they can find easily: a named contact, a list of approved integrations and a route for exceptions. Teams should know what is allowed, what is not, and when to ask for help. That way teams can resolve questions before putting an agent into use.
Start with one team
List the agents one team uses, who can change their access and who follows up when something goes wrong. That will show you where the gaps are. Extend the inventory before adding the next experiment.
Want to map the agents already in use in your organisation? Discuss a first step with Orbis Neo.