Shadow AI becomes shadow agency

Unapproved use once meant an employee pasting information into a tool the organisation had not sanctioned. The risk changes when that tool can retain context, use credentials, connect to systems and act on the employee’s behalf.

Shadow AI has largely been treated as a familiar governance problem. Employees discover a useful service before procurement approves it, place company information into an external system and create a data exposure that security teams cannot fully see. The response has focused on acceptable-use policies, approved alternatives and warnings about confidential information.

Agents make that definition too narrow. A tool that drafts text creates an information risk, but an agent can also initiate a workflow, retrieve records or update a system. Unsanctioned software use becomes delegated authority without a clear record of who granted it or who is responsible when it behaves unexpectedly.

Creation has escaped central control

The first change is how easily agents can be built. Robotic process automation usually required specialist platforms, formal projects and lengthy change control. Agentic tools put comparable capability into the hands of employees who can create software through conversation rather than conventional development.

Alex Laurie, Senior Vice President at identity security company Ping Identity, sees that democratisation as a fundamental break from earlier automation. “I consider myself a novice when it comes to coding AI, but I can load up a studio and build agents by prompting and talking to it,” he says. “The creation of the capability has moved into the hands of everyone. I can build agents that sit on my machine and do things independently, whereas a large enterprise RPA system might have taken six months to get through change control.”

That accessibility removes delay between a problem and a working solution, but can also bypass controls that identify the owner, define the data sources and test behaviour before production.

Justin Sharrocks, Managing Director UK and EU at technology services provider TrustedTech, repeatedly encounters organisations moving faster than their foundations allow. “Everyone feels a little bit behind at the moment, so everyone is rushing in,” he says. “They want instant impact, but they are not taking a step back to understand the business problem, what the technology is aligned to and what they actually want to see happen.”

The organisation can then end up with approved licences that are barely adopted alongside unapproved agents sitting outside its inventories, controls and support model. Shadow agency also fills the gap between the speed at which employees want solutions and the speed at which formal programmes deliver them.

Access turns a tool into an actor

The security boundary changes when an agent stops producing content and begins interacting with enterprise systems. It may read calendars, retrieve customer data, submit forms or change records. Every useful connection expands what the agent can do, but also increases the damage possible from a mistake, compromised instruction or excessive permission.

Laurie argues that an agent cannot be treated like a conventional machine identity because it can choose how to reach an objective. “Traditional non-human identities are very constrained and deterministic,” he explains. “With agents, one of the important differences is that they can make their own decisions. They try to find the easiest path to do something, a little like water or a grey IT user, which is why an identity specific to the agent is important. You can scope, control, govern and manage that identity according to its role.”

The identity provides a chain of accountability that a shared employee credential cannot. An authorised agent should be registered, linked to an owner and given a defined role stating which applications and services it may use. Its permissions should be limited to what the assigned task requires rather than inherited wholesale from the person who created it.

The lifecycle also matters because agents may be temporary. Laurie describes internal experiments in which an agent spawned additional agents to complete tasks and destroyed them seconds later. “A traditional identity system might handle ten thousand, a hundred thousand or a million users,” he says. “We could be talking about hundreds of millions of agents being created, running through their existence and disappearing again within minutes. The scale, and the different way they interact, means this has to be handled differently.”

Governance must cover creation, operation and retirement. The organisation needs to know who or what created an agent, which credentials it received and when they should expire. It must also detect new capabilities, connections or behaviour outside the approved context.

Readiness begins with what the agent can reach

The immediate attraction of an agent can obscure the condition of the environment into which it is being released. A business may focus on time saved without identifying what data the agent can see, which permissions it inherits or whether the underlying records are accurate enough to support autonomous action.

Sharrocks treats those questions as part of deployment rather than a security review added at the end. “The first thing we do is run a readiness assessment,” he says. “What happens if we put AI into the environment now? What data is it going to read? What does it have access to, and what permissions are we giving the user? Different functions will have different rewards and different risks.”

These questions are easily skipped when a tool arrives through an individual employee. The creator may understand the task but not the consequences of connecting a personal agent to a corporate account. Convenient permissions can expose information beyond the intended workflow, while integrations remain active after the experiment is forgotten.

Organisational incentives contribute to the problem. Vendors promote rapid deployment, leaders promise productivity gains and technical teams inherit the controls after the purchasing decision. “Leadership signs the contract and hands it over to the technology team,” Sharrocks says. “A year later, they are asked why only twenty per cent of the licences are being used or why a data breach was not uncovered. The savings promised at the front end can be lost through licences nobody uses or risks nobody assessed.”

Blocking every unapproved experiment is unlikely to work. A more realistic response combines clear boundaries with approved routes that are easier to use than the workaround. Experimenting with synthetic information is one thing; giving an agent credentials to alter a live customer record is another.

Authority should rise in controlled steps

The answer is not permanent human approval attached to every action. That would remove much of the value of automation and create an approval burden that cannot scale. Authority should increase gradually, with stronger authentication and human intervention triggered when an action becomes difficult to reverse or carries greater financial, legal or personal consequence.

Laurie compares the approach with risk-based controls already familiar in financial services. “You may set the parameters and define the scope of the agent, but as soon as a transaction or action goes above a certain point, we mandate a human in the loop,” he says. “It is like using a card without a PIN up to a certain amount. When the perceived or real risk rises, you need a stronger authentication or authorisation step.”

Ian Roberts, Managing Director at public-sector technology company Granicus, applies a similar distinction to services moving from conversation towards action. Digital agents can gather information, connect to back-office systems and progress requests without forcing a resident to complete another form. The benefit is less friction, but only when the organisation establishes what is true before allowing the technology to act.

“Before scaling those solutions, standardise on what is true, connect the systems, build the use cases and then scale up,” he says. “Data quality is fundamental, as is information security, not only for compliance around the control and use of data, but for the ethical use of AI and the accuracy of the information and response being provided.”

Deployment also needs people who understand the service, not just the technology. Roberts has seen advanced pilots fail because staff and users were brought in too late. “Sometimes the experimentation and technology work well, but the user experience has not been worked through,” he adds. “Good pilots can fail to get out of the gate because the staff delivering the service or the people using it were not involved early.”

Those stakeholders help define where autonomy is appropriate. Some recommendations can be implemented automatically and reported afterwards; others need approval before the system changes a service, record or entitlement. The dividing line should reflect consequence rather than a general declaration that a human is somewhere in the loop.

Shadow AI becomes shadow agency when an unauthorised system gains the ability to do more than advise. The central question is no longer whether an employee used an approved model, but whether the organisation can identify the actor, constrain its authority, observe its behaviour and stop it when the context changes.

Enterprises will not regain control by attempting to prevent every employee from creating an agent. They need a route through which useful experiments become visible, registered and governed before they receive meaningful access. An agent should have an owner, an identity, a limited role and an expiry point, with additional authority earned through testing rather than granted by convenience. Without those foundations, the organisation may know which people work for it while having little idea which digital actors are working in its name.