TL;DR: Shadow AI used to mean pasting text into a chatbot. Now employees give AI agents standing OAuth access to Google Drive, Slack and the CRM, and the agents act on that data. Once that happens, the shadow AI risks that matter most are, in order: data leakage, unscoped OAuth grants, unlogged agent actions, compliance exposure and uncontrolled cost. Each one has a concrete control, and none of those controls is a ban.

Key takeaways

  • Agents change the risk: a chat window sees what you paste into it. An agent with an OAuth grant can read, change and send whatever the user can.
  • Rank, don’t list: data leakage, unscoped grants and missing logs cause most of the real exposure. Prompt injection and plugin risk usually reach you through those three.
  • One control per risk: inline DLP, least-privilege access per agent, a full audit trail, a governed catalog and hard spend limits.
  • Bans don’t remove risk: they push usage onto personal accounts where you can’t see it.
  • Give people a governed path: route agent access through an AI Gateway so people keep the tools and you keep control.

What is shadow AI (and what changed with agents)?

Definition: Shadow AI is any use of AI that IT doesn’t know about: an employee using a model, an AI app, an agent or an MCP server that nobody approved, reviewed or can see. The shadow AI risk is everything that tool can touch with nobody watching. Shadow AI is a branch of shadow IT, with one difference: an AI tool doesn’t just store data, it reads it, reasons over it and acts on it, through a model you never vetted. What changed in the last year is the jump from chat to agents. Employees now connect an agent to company systems with their own OAuth grant, or add an MCP server to their desktop AI app, and the agent works on its own from then on.

What is an example of shadow AI? A sales rep connects a desktop AI agent to the company CRM and shared drive with a personal OAuth grant so it can draft account plans. The agent can now read every account the rep can see and send it to whichever model it uses. For more on how desktop agents raise this risk, see our post on how Claude Cowork raises shadow AI risk.

The five shadow AI risks, ranked by exposure

1. Data leakage to models and third parties

What it is: sensitive data, such as PII, customer records, source code or credentials, ends up in prompts sent to a model nobody approved. With agents there’s a second path: indirect prompts. When an agent calls an MCP tool, the tool result (a document, a ticket, a database row) goes into the model context too.

Scenario: a developer asks an agent to debug a failing job. The agent pulls the config file through an MCP connection, and the API keys in it go to a third-party model along with the error log.

The control: inline DLP that redacts, tokenizes or blocks sensitive data in prompts and in tool results before it reaches a model, and a list of approved models so traffic only goes where you’ve agreed it can.

2. Unscoped OAuth grants

What it is: when a user connects an agent with their own OAuth grant, the agent usually inherits that user’s full access. One grant can reach a whole drive, an entire CRM or every Slack channel the person is in.

Scenario: an analyst connects an agent to Google Drive to summarize one spreadsheet; the grant covers payroll exports too.

The control: least-privilege access down to the individual tool and action, not just the app. Give each agent its own delegated identity instead of letting it act as the user, so you can scope and revoke it on its own. Our post on why MCP needs a new zero trust model for AI agents goes deeper on this.

3. Unlogged agent actions

What it is: nobody can say what an agent read, changed or sent. The app logs show the user did it, because the agent used the user’s token.

Scenario: a customer record is deleted in the CRM. The log shows a sales manager’s account at 2 a.m. An agent they set up weeks ago did it, and there’s no record of why.

The control: an audit trail of every AI and agent action and the policy that governed it, streamed to your SIEM, so agent activity sits next to the rest of your detection data.

4. Compliance and regulatory exposure

What it is: regulated data moves through tools nobody reviewed. That creates gaps under GDPR (where personal data goes and why), HIPAA (protected health information sent to a vendor with no business associate agreement) and SOC 2 (no evidence of access control or logging for a whole class of systems).

Scenario: a clinic’s operations team uses an agent to summarize patient intake forms with a personal AI subscription. The practice can’t show an auditor where that data went.

The control: a governed catalog of approved models and MCP servers, so teams only use what has been reviewed, plus audit evidence you can hand to an assessor.

5. Uncontrolled cost

What it is: personal AI subscriptions expensed one at a time, and agents that loop or pull huge context windows and burn tokens on a company key with no limit.

Scenario: a retry bug runs an agent on a shared provider key all weekend.

The control: spend visibility by user, team, agent and model, with hard limits and budgets.

Why banning AI doesn’t remove these risks

Blocking AI tools doesn’t work for long. People who get value from AI keep using it on personal accounts, with even less visibility. Palo Alto Networks makes the same point. The control that lasts is a governed alternative people actually want to use: the same models and agents, with access, DLP, logging and limits built in. For the process of deciding what to sanction, substitute or block, see our guide to shadow AI management best practices. For finding the usage you already have, see our roundup of shadow AI detection tools.

How Barndoor reduces shadow AI risk

Barndoor is the AI Gateway for enterprises. It governs the AI traffic routed through it, so it’s the governed path employees move to, not a scanner for tools outside it. Here is how it maps to the five risks:

  • Least-privilege access: Barndoor MCP Governance enforces least-privilege access from the user, role, group and MCP server down to the individual tool, model, data point and action. It supports OAuth, and people are scoped from your existing IdP roles. More on that in why your identity provider still matters for AI governance.
  • Delegated agent identity: every agent gets its own delegated identity, not a copy of the user’s access.
  • Runtime policy: policy is enforced at runtime on every request, so unauthorized actions are stopped before they execute.
  • Barndoor data protection: native DLP redacts, tokenizes or blocks sensitive data inline, so it never reaches a model.
  • Audit trail: a complete record of every AI and agent action and the policy that governed it, streamed to your SIEM.
  • Spend limits: see what every user, team and agent spends by model, and set hard limits and budgets.
  • Governed catalog: teams only use the models and MCP servers they’re approved for. Connect 100+ pre-built MCP servers plus custom ones, and all major LLMs.
  • Virtual keys: real provider keys stay in the Barndoor vault; developers, agents and AI apps get virtual keys instead.

If you’re new to the category, start with what an AI Gateway is and how it governs LLMs and agents.

Shadow AI risks: FAQs

What are the risks of shadow AI?

The main shadow AI risks are data leakage to unapproved models, unscoped OAuth grants that give agents a user’s full access, agent actions nobody logged, compliance exposure under rules like GDPR and HIPAA, and uncontrolled cost.

What are the security risks of shadow AI agents?

Agents act, not just answer. An agent with a personal OAuth grant can read, change and send anything the user can, often unlogged. The biggest risks are over-broad access, sensitive data in tool results flowing to a model, and no audit trail of what the agent did.

What is an example of shadow AI?

A sales rep connects a desktop AI agent to the CRM and shared drive with a personal OAuth grant to draft account plans. IT never approved it, the agent can see every account the rep can, and customer data goes to a model nobody reviewed.

How does shadow AI differ from shadow IT?

Shadow IT is any unapproved app or service. Shadow AI is the AI subset, and it’s riskier in two ways: data goes to a third-party model as prompts, and agents can take actions in your systems.

How do organizations identify shadow AI usage?

Most combine network and SaaS signals: AI domains in proxy logs, OAuth grants to AI apps in Google Workspace or Microsoft 365, browser extensions, and expense reports for AI subscriptions. Our roundup of shadow AI detection tools compares the options.

Can a CASB detect shadow AI?

Partly. A CASB can usually spot traffic to known AI domains and some OAuth grants to AI apps. It sees less of local agents, MCP servers calling APIs directly, or prompt contents. Treat it as one signal, not a full answer.

How do I stop employees using shadow AI without banning it?

Offer the models and agents people want through an AI Gateway with access control, DLP and logging built in, publish a short acceptable use policy, and make the approved path faster than a personal account.

How can procurement control shadow AI spend?

Start by pulling AI subscriptions out of expense reports and moving them to company accounts. Then route model and agent traffic through one gateway so you can see spend by user, team, agent and model and set hard budgets.

Related reading

Ready to put your top two shadow AI risks under control? Start a free trial and route your teams’ agent access through the Barndoor AI Gateway, with least-privilege access, DLP, audit and spend limits from day one.