Shadow AI: visibility, policy, and a sanctioned path

TL;DR

• Shadow AI is a missing-oversight problem, not a banned-app list. An approved app can still hide an unapproved workflow, so classify the workflow, its data, and its authority before you decide anything.
• Discover use proportionately: voluntary inventory, procurement and expense signals, managed-identity app records, and integration metadata. Explain what you collect and why, and skip covert monitoring of employee prompts.
• Give each workflow an owner and a decision. Approve it with the right controls, constrain it, or block it, and offer a sanctioned route people actually want to use.

What is shadow AI?

Shadow AI is the use of AI tools, integrations, or workflows outside an organization’s required oversight. It can be an unapproved service, or an unsanctioned workflow running inside an approved application. The concern is missing visibility, ownership, and controls, not an assumption that every employee’s use is unlawful or leaks sensitive data.

That definition matters because it changes what you’re managing. You’re not policing a logo. You’re deciding whether a given workflow, with its specific data and authority, has an owner and a control that fits its risk.

Make the permitted path clear

The fastest way to shrink shadow AI is to make the sanctioned path the easy one. If the useful thing employees want to do is available through a governed route, most of the pressure that pushes AI underground goes away. Blocking alone doesn’t do that. It tells people what they can’t use without telling them what they can.

So the work has three moves. Inventory the workflow and name its owner. Discover more use with privacy-preserving, purpose-limited signals. Then decide: provide a sanctioned route, add controls, or restrict the uses whose risk you can’t contain.

The approved app with an unapproved workflow

Here’s the trap in most shadow-AI programs. They start with an app blacklist, and an app list can’t see the workflow running inside an approved tool.

Picture a support team that’s cleared to use an assistant for drafting public help-center copy. That approval is real and reasonable. Then someone wires an unreviewed ticket export into the same assistant to speed up triage. The tool didn’t change. The approval didn’t change. But the workflow now moves customer data through a path nobody reviewed for that purpose, under retention and training terms nobody checked against that data class.

Nothing here is automatically a breach. It’s a workflow whose data and authority shifted past what the original approval covered, and that shift is what should trigger a review rather than an alarm. This is a hypothetical, but it’s the recognizable shape of the problem: approval attaches to a tool, risk attaches to a workflow, and the gap between them is where shadow AI lives.

It’s also widespread. In PagerDuty’s 2026 Shadow AI Survey, among respondents who had ever used AI for work, 66% reported using AI tools they believed were disallowed by company policy.

That survey, conducted by Wakefield Research and fielded April 9 to 20, 2026, covered 1,250 office professionals outside IT and technology roles, at companies with at least $500 million in revenue across the US, UK, Australia, and Japan. The figure is self-reported belief within that subgroup, not a company-wide prevalence rate, but it says something plain: people are already using AI they think they’re not supposed to.

The question is whether you can see it and route it, which is part of your broader AI governance responsibilities.

Where do shadow AI risks enter the workflow?

Risk doesn’t live in the word “AI.” It lives in what a specific workflow touches and what it’s allowed to do. Five things determine the consequences: what data goes in, what happens to the output, whether that output is retained or used for training, what permissions the tool holds, and whether the tool can act on its own.

Those are different risks, and they don’t travel together. A confidently wrong answer is a reliability problem. A workflow that pastes customer records into a consumer tool is a data-disclosure problem. An agent that can send messages or update records is an action-authority problem. Not every tool acts, and not every unsanctioned use leaks data. Treating all three as one threat is how programs over-restrict harmless work while missing the workflow that actually matters.

Data inputs, retained outputs, and external actions

Walk a workflow through those five dimensions and the real exposure gets clear. What data class is the input, and is it confidential or personal? Where does the output go, and does anyone rely on it as fact? Does the provider retain inputs or use them to train? What resources can the integration read or write? And can the tool act, or does it only produce text? The answers, not the app’s reputation, set the control.

Discover workflows without covert surveillance

You can find most of this without watching what people type. Start with transparent, authorized signals: voluntary inventories where employees register the AI they use, procurement and expense records, managed-identity app records, and metadata from approved integrations.

Explain what you’re collecting and why, minimize personal data, restrict who can see it, set retention limits, and give people a review and appeal route. The goal is to surface workflows that need a decision, not to monitor prompts, private accounts, or unrelated behavior.

Identity attribution is one useful signal here, and identity controls for non-human actors go deeper on excessive delegated authority, but attribution is one control dimension, not the whole category.

Discovery feeds a short record you can act on. For each workflow, capture the workflow itself, its owner, the application, the data class, the purpose, the integration scopes, retention and training terms, the action rights, the decision, and a review date. That minimal inventory is the input to the next step.

A shadow AI policy should lead to a decision

A policy that only lists forbidden apps stops short of the thing that matters: a decision about the workflow. The point of discovery is to classify uses, not people, and to record who approves exceptions when the answer isn’t a simple yes.

The matrix below turns an inventoried workflow into a proportionate decision. The tiers are proposed policy examples, not law and not a universal taxonomy, and you should reassess a workflow whenever its data, integrations, provider terms, or action authority change. Obligations under the EU AI Act may also apply depending on the actor and use, and EU AI Act obligations and applicability covers who’s in scope; this page is operational guidance, not legal advice.

Build the minimum useful inventory

Keep the inventory small enough that people actually fill it in. Workflow, owner, application, data class, purpose, integration scopes, retention and training terms, action rights, the decision, and the review date. Ten fields, applied to a workflow rather than an app, are enough to tell you which tier a use belongs in and who owns the call.

Match acceptable-use tiers to data and authority

Apply the decision to a recorded workflow, including workflows running inside sanctioned applications.

In short: approve, constrain, or block the workflow according to its data and authority, not the logo on the application.

Notice what the matrix does. It never bans a category outright as a reflex, and it never waves a workflow through just because the app is approved. A restricted tier still has a permitted route when the controls fit, and a blocked tier names who owns the decision and how it gets reassessed. That’s the difference between a policy that channels demand and one that only pushes it out of sight.

How do you make the sanctioned route usable?

A sanctioned route only reduces shadow AI if people prefer it. That means access, usability, and ownership have to hold together, not just a rule that says “use the approved tool.”

Give the approved path a documented request process, a named decision owner, restrictions that are justified rather than blanket, training so people know how to use it, and a time-bounded exception process for the cases the standard route doesn’t cover. When the easy path is also the governed path, the incentive to route around it drops.

Review OAuth grants and connected workflows

The integration layer is where approved apps quietly acquire new reach. An app that’s approved today isn’t approved for every future connection it might make. Review OAuth consent grants and the scopes they request, keep them least-privilege, know which resources each integration can read or write, and test that revocation and denied access actually work. Approving an application is not the same as approving every workflow that later plugs into it.

Assign ownership and revisit changed uses

Every workflow needs an owner and a trigger for re-review. When the data class changes, when a new integration appears, when the provider’s terms shift, or when an agent gains authority to act, the earlier decision needs another look. You can track how much of your inventory has an owner and a current decision, and how many exceptions are still open, as working measures of coverage rather than as proof the problem is solved.

This is where a governed platform earns its place. In Computer, by DevRev, data access is permission-aware at the field and record level, so a sanctioned workflow sees what its user is entitled to see and nothing more. Actions are logged and auditable, and identity flows through SSO and SCIM so access follows the joiner-mover-leaver lifecycle.

The point isn’t that Computer finds or prevents shadow AI. It’s that a governed alternative can give people the AI they want inside the security framework, which is what makes the sanctioned route the one they’ll actually choose. Check that a workflow’s inputs are sound with validate data readiness for the task, and once it’s running, review agent behavior over time so a change in how it acts doesn’t slip past unnoticed.

Give each workflow an owner and a permitted route

You don’t fix shadow AI by publishing a longer block list. Pick one workflow you don’t fully understand, ideally one running inside a tool you’ve already approved. Find its owner. Write down its data class, its integration scopes, and whether it can take actions. Then make a decision: a permitted route with controls, a constraint, or a stop.

Give the workflow an owner, a boundary, and a permitted path, not just a place on an app list.

Frequently asked questions

Is shadow AI the same as shadow IT?

Shadow AI overlaps with shadow IT because both involve technology used outside required organizational oversight. AI adds questions about model inputs, generated outputs, retained data, and delegated actions. Not every AI tool takes actions, and not every unsanctioned use leaks data. Review the workflow and its permissions rather than assuming the risks are identical.

Can an approved AI tool still contain shadow AI?

Yes. An approved AI tool can still contain shadow AI when a workflow exceeds the approved purpose, data categories, integrations, or authority. Approval for public marketing drafts, for example, doesn’t automatically authorize uploading customer records. Keep application approval and workflow approval distinct, and reassess whenever an integration or a use changes.

How can organizations detect shadow AI without surveillance?

Organizations can start with transparent employee reporting, procurement records, managed-identity applications, and authorized integration metadata. Explain what’s collected and why, minimize personal data, restrict access, and set retention limits. Discovery should surface workflows that need review, not become covert monitoring of employee prompts, private accounts, or unrelated behavior.

Should organizations ban shadow AI tools?

Restrictions can be appropriate when a use exposes sensitive data, grants excessive authority, or can’t meet organizational requirements. A blanket ban alone doesn’t tell people which useful alternatives they may use. Pair proportionate restrictions with clear acceptable-use rules, a workable sanctioned route, and a process for reviewing exceptions as risks change.

How mature are AI policies right now?

Policy maturity is uneven. In ISACA’s AI Pulse Poll released May 5, 2026, drawing on more than 3,400 global digital-trust professionals, 38% reported a formal or comprehensive AI policy, 30% a limited policy, and 25% no active policy. That gap is why unsanctioned use spreads faster than the rules meant to govern it.

Sources and methodology

This guide reflects enterprise AI-governance practice as of September 2026. The PagerDuty 2026 Shadow AI Survey figure (66%) is scoped to respondents who had used AI for work and reflects self-reported belief within that subgroup, not company-wide prevalence; it was fielded by Wakefield Research, April 9 to 20, 2026, among 1,250 non-IT office professionals at companies with at least $500 million in revenue across the US, UK, Australia, and Japan.

The ISACA AI Pulse Poll figures (38% / 30% / 25%) reflect more than 3,400 global digital-trust professionals as released May 5, 2026. Product capabilities described for Computer, by DevRev reflect DevRev materials and are subject to review before external amplification. This is operational guidance, not legal advice.