Shadow AI Is Now an Agent Problem: What Changes When Unsanctioned Tools Can Act

Verizon's 2026 Data Breach Investigations Report found that shadow AI detections rose fourfold year over year, making it the third most common non-malicious insider action in enterprise breach data. In the same period, Microsoft reported that active agents across the Microsoft 365 ecosystem grew fifteenfold.

Those two figures describe the same event from different angles. Employees are not just using unsanctioned chat tools any more. They are building and running unsanctioned agents, on corporate accounts, against corporate data, with credentials the security team never issued.

Most shadow AI coverage still treats this as a data leakage problem. It stopped being one.

What shadow AI is, and why the shadow IT comparison understates it

Shadow AI is the use of AI tools and agents inside an organisation without the knowledge or approval of the people accountable for security, compliance and data governance. The obvious historical analogue is shadow IT: the unauthorised Dropbox account, the personal email forwarding rule, the departmental SaaS subscription paid on a corporate card.

The analogue breaks in one specific place. Shadow IT was mostly a storage and access problem. An unsanctioned file-sharing tool held data it should not have held, in a location nobody had reviewed. Serious, well understood, and addressable with discovery tooling and policy.

An agent does not sit still. It authenticates, retrieves, decides and executes. It sends the email, updates the record, moves the file, triggers the downstream workflow. The exposure is no longer confined to what an employee pasted into a text box. It extends to everything the agent was permitted to reach and everything it subsequently did.

The barrier to creating one has also collapsed. Building an agent that reads a shared drive, summarises what it finds and posts the result into a team channel now requires no engineering involvement at all. That is a genuine productivity gain, and it is also the mechanism by which an ungoverned execution surface appears inside a regulated environment without anyone filing a ticket. If the distinction between a passive assistant and an autonomous agent is doing work in this argument, we set it out in detail in AI assistant versus AI agent.

Five risk vectors that did not exist under shadow IT

Persistent credentials with no expiry discipline

Connecting an agent to a business system usually means granting an OAuth token. That token persists. It does not expire when the employee closes the browser, and in most cases it does not expire when the employee leaves the company, because nobody in IT knows it was issued. An organisation running fifty employee-built agents is running fifty long-lived credentials against production systems, outside the identity lifecycle that governs every other access path.

Action without a record

When an ungoverned agent takes an action, the target system logs that something happened under a user identity. It does not log which agent acted, on what instruction, using which retrieved context, under which model version. The organisation has an outcome with no attribution. That distinction, between a record of output and a record sufficient to reconstruct a decision, is the whole subject of what an enterprise AI audit trail actually needs to contain.

Data egress that survives the session

Retrieved content leaves the perimeter and enters a third-party inference environment. Where enterprise agreements exist, that content is generally not used for training. The exposure is not primarily about training. It is that regulated data has been processed in a location the organisation cannot name, under a retention policy it has not reviewed, in response to a question no compliance function approved.

Compounding permissions across connected systems

An agent connected to three systems inherits the union of the employee's permissions across all three. That union frequently exceeds anything the access model was designed to allow in a single operation. A support agent with read access to a customer database and write access to a messaging platform can move data between them at machine speed, and no individual permission grant looks wrong in isolation.

No reconstruction path after an incident

The practical test arrives during an investigation. A regulator, auditor or customer asks what the system did, on what basis, and who approved it. For an ungoverned agent the honest answer is that the organisation cannot say. IBM's Cost of a Data Breach research found that 97% of AI-related breaches involved systems without proper AI access controls, and that organisations with high levels of shadow AI carried roughly $670,000 in additional breach cost, a 16% premium over organisations with little or none.

Why banning shadow AI does not work

The instinct is prohibition. It fails predictably, for a reason worth naming precisely: employees adopt these tools because the tools work. The productivity differential is real, it is visible to the individual, and it is not visible to the policy committee.

A ban does not remove the demand. It moves the activity onto personal devices and personal accounts, where the organisation has no telemetry at all. Prohibition converts a governance problem the security team can see into one it cannot. Every measurable outcome gets worse while the policy document reads better.

The second failure is competitive. An organisation that successfully suppresses AI use suppresses the productivity gain along with the risk. Competitors who solved the governance question keep both.

The workable answer is substitution. Give people a sanctioned path that is good enough to be the obvious choice, and make governance a property of that path rather than a condition attached to it. Adoption follows convenience. If the governed option is slower, harder or more restricted than the ungoverned one, the policy loses regardless of what it says.

If you are assessing what a governed agent platform would need to provide before it could displace ungoverned tools in your organisation, request Early Access to Booga Agents.

What a sanctioned path has to provide

Substitution only works if the sanctioned platform closes every vector above. That is an architecture requirement, not a policy one.

Access has to be evaluated at execution time rather than at session start. An agent traversing four systems in one run needs four checks, because permission granted at the beginning of a run does not describe what the agent is doing at step three. The mechanics of this are set out in runtime access control for AI agents.

Every action needs a record with enough structure to reconstruct the decision: what was retrieved, what was denied, which policies were in force, and which model and configuration produced the output. Retention has to be long enough to survive an audit cycle rather than a log rotation.

Data has to stay somewhere the compliance function has approved, with isolation between tenants enforced at the data layer rather than by application logic.

Credentials have to sit inside the organisation's identity lifecycle, so that an agent's access ends when the employee's access ends.

How Booga Agents addresses this

Booga Agents, the enterprise platform from Booga Enterprise, was built so that these properties belong to the platform rather than to the discipline of whoever configures it.

Access control is enforced at runtime with capability gating applied at each tool call. Of the platform's 600+ documented API endpoints, 469 are automatically blocked from API key access, which constrains what any agent can reach regardless of how it was configured. The audit event pipeline captures 14 event categories with a 7-year default retention period, exposed through the Audit & Compliance plugin as reviewable evidence rather than raw records. Tenant isolation runs at the data layer, with per-tenant Pulumi stacks provisioning dedicated storage, vector search and compute across Azure, AWS or GCP. Five compliance frameworks ship configured: SOX, GDPR, HIPAA, ISO 27001 and PCI DSS.

The agent builder matters as much as the controls do. If building a governed agent is meaningfully harder than building an ungoverned one, employees will keep building ungoverned ones, and the governance architecture will protect a platform nobody uses. Further detail on how these pieces fit together is on the Booga Agents platform page.

Where to start

Discovery first. Most organisations underestimate their own agent count because they are looking for AI tools rather than for OAuth grants and API keys issued against business systems. The credential trail is the reliable signal.

Then triage by what the agent can do rather than by what it can see. An agent with read access to a document repository is a data question. An agent with write access to a customer record, a payment system or an external communication channel is an operational one, and it belongs at the front of the queue.

Then substitute, starting with the highest-value use cases rather than the highest-risk ones. The objective is to make the governed path the default by making it the best available option, which is a product problem before it is a policy problem.

Regulatory pressure is arriving on a fixed schedule. Article 50 transparency obligations under the EU AI Act apply from 2 August 2026, and an organisation that cannot enumerate its own agents cannot demonstrate compliance for them. The inventory problem and the compliance problem are the same problem.

Shadow AI is a signal about demand, not a failure of employee judgement. People reached for these tools because the tools solved something. The organisations that come out of this period well are the ones that read the signal correctly and built the sanctioned version, rather than the ones that wrote a stronger policy.

Review the Booga Agents governance architecture against the agents already running in your organisation.

Frequently asked questions

What is shadow AI?

Shadow AI is the use of AI tools and agents within an organisation without the approval or knowledge of the teams accountable for security, compliance and data governance. It covers unsanctioned chat tools, browser extensions, API integrations and employee-built agents connected to business systems.

How is shadow AI different from shadow IT?

Shadow IT was primarily a data storage and access problem. Shadow AI adds execution. An unsanctioned agent authenticates to business systems, retrieves data, makes decisions and takes actions such as sending messages or updating records, usually holding a persistent credential that sits outside the organisation's identity lifecycle.

How common is shadow AI in 2026?

Verizon's 2026 Data Breach Investigations Report found shadow AI detections rose fourfold year over year and identified it as the third most common non-malicious insider action, with 45% of employees now regular AI users on corporate devices. Independent surveys through 2026 place unsanctioned AI use between roughly 45% and 67% of the workforce depending on methodology.

Should organisations ban unsanctioned AI tools?

Prohibition tends to move usage onto personal devices and accounts, where the organisation has no visibility at all, while also removing the productivity gain. Providing a sanctioned platform with governance built into its architecture addresses both the risk and the underlying demand, provided the sanctioned option is convenient enough to become the default choice.