Governing Shadow AI Without Blocking Adoption

Shadow AI is usually described as a control problem. Employees use an application that has not gone through procurement, connect a model to data that security has not reviewed, create an agent outside the approved platform, or start sharing prompts and skills through channels the organization cannot see. From the perspective of IT and security, the natural response is to increase control: restrict the application, require approval, move the work into a managed environment, or block what has not yet been evaluated. Some of those actions are entirely appropriate. There are AI services an organization should not use, data that should never be sent to particular systems, agents that should not have the permissions they request, and capabilities whose behavior creates enough risk that use should stop until someone understands what is happening. The mistake is not blocking risky activity. The mistake is treating blocking as the operating model for everything the organization has not seen before.

I think Shadow AI is better understood as both a governance problem and an adoption signal. When employees repeatedly route around the systems an organization has provided, at least some of them are telling you that they have found useful ways to work that the organization has not yet learned how to absorb. That does not make every unsanctioned tool safe or every employee-created workflow worth preserving. It does mean that a useful governance system has to distinguish between something being unknown, something being unreviewed, and something being unsafe. Those states are often collapsed into one another because unknown things make security teams appropriately uncomfortable. Operationally, though, they are different. If discovery itself causes a useful capability to be shut down, people learn very quickly that remaining undiscovered is the easiest way to keep working.

That incentive problem matters because AI adoption is increasingly producing more than one-off conversations with a chatbot. People are creating durable instructions, skills, agents, workflows, tools, knowledge packages, automations, and provider-specific configurations that encode how they perform repeatable work. A security engineer may develop a skill for triaging findings. Legal may refine a contract review process. Finance may build a recurring analysis workflow. An operations team may connect an agent to several internal systems and gradually teach it the sequence they use to resolve a class of customer issues. Some of those capabilities will be trivial. Some will be bad. A few may become surprisingly important. The organization needs a way to see that work, evaluate it, and eventually reuse the good parts without requiring every experiment to enter the same governance process as a production system with broad permissions and material business impact.

The principle I would start with is simple: the safest path should also be the easiest path. That means registration should create visibility before it creates friction. A capability entering the organization's inventory should not, by that fact alone, become less usable than it was five minutes earlier. Access should change when policy, evidence, or risk justifies the change. If a capability contains credentials, requests excessive privileges, violates data policy, performs dangerous actions, or crosses some other meaningful threshold, restriction may be exactly the right response. But making "we now know this exists" synonymous with "you may no longer use it" is an unusually effective way to teach people not to tell you what exists.

The incentive structure matters more than the policy language

Consider the employee who has spent several weeks developing a workflow that saves their team a few hours every Friday. They did not set out to create an enterprise application. They found a repetitive task, improved a prompt, added reference material, gave the model a tool, changed the instructions several times, and eventually arrived at something reliable enough that two colleagues started using it as well. At that point, the workflow has crossed an important boundary. It is no longer only personal experimentation. It is becoming reusable organizational behavior, even if nobody has formally described it that way.

Now imagine that the organization's governance process tells this employee that registering the workflow will immediately suspend it while a review ticket moves through several queues. The review may be well intentioned. The security team may have legitimate questions. But the employee's incentive is obvious. They can disclose the capability and lose something that is currently useful, or they can keep it where it is and continue working. A policy can tell them that disclosure is mandatory, but the system is still creating a structural incentive against disclosure.

This is one reason I am skeptical of governance approaches that begin with an approval queue. Approval is important, but it should not be the first state something can occupy. There needs to be room between invisible and organization-wide approved. A capability can be known to the organization while remaining available only to its creator. It can pass automated checks and become available to a team without being approved for every employee. It can be acceptable for use with public or internal information while remaining prohibited for regulated data. It can be reviewed for one set of permissions and require another review when those permissions expand. These are not compromises with governance. They are more precise expressions of governance.

The same incentive applies to administrators. A security team should not have to choose between ignoring employee experimentation and manually reviewing every new capability. If registration immediately creates a large review obligation, the governance program eventually becomes its own denial-of-service attack. Most low-risk experimentation does not deserve the same attention as an agent with write access to a financial system. The system should be able to collect inventory, provenance, ownership, permissions, security findings, and version information automatically, then direct human attention toward the things whose characteristics actually justify it.

When the incentives are aligned, the employee gets something from entering the governed system too. Their work gains a durable identity. They can preserve versions, establish ownership, understand where the capability came from, see whether a newer revision has been reviewed, and eventually make useful work available to other people without copying it through Slack messages or rebuilding it independently. Governance stops being something done to the employee's work and becomes infrastructure that helps useful work survive beyond the person who created it.

That is an important distinction. The objective is not simply to drag Shadow AI into a registry. It is to make the governed path more useful than the shadow path.

Approving the AI platform is no longer enough

Much of enterprise AI governance began at the application layer for sensible reasons. Organizations needed to decide whether ChatGPT could be used, whether Claude could process certain classes of information, whether engineers could call a particular API, whether training and retention terms were acceptable, and whether a provider met existing security requirements. Those questions remain important. But an approved provider can now contain a very large amount of behavior that the provider approval itself says almost nothing about.

An organization could approve Claude, ChatGPT, and an internal AI environment and still have hundreds of skills, agents, tools, prompts, workflows, and integrations moving through those systems. Some may only summarize text. Others may call external services, execute code, retrieve customer data, update business records, or send communications. Some may have been written internally. Others may have been imported from public repositories. One version may have been reviewed while another has changed substantially since that review. Two capabilities with similar names may be unrelated; two artifacts in different providers may actually be implementations of the same organizational capability.

The provider can be approved while the capability remains unknown.

That is why I think the unit of governance is moving upward. Provider governance asks whether the organization trusts the execution environment under particular conditions. Capability governance asks what the organization has actually placed inside that environment and what that thing is allowed to do. The two are complementary. Treating one as a substitute for the other leaves an increasingly large blind spot.

This also changes what "Shadow AI" means. The shadow is not limited to employees using unsanctioned applications. A capability can live entirely inside an approved enterprise AI product and still be effectively shadow infrastructure if the organization does not know it exists, who owns it, where it came from, what permissions it has, which version is in use, or whether other people have started depending on it. Conversely, something created experimentally outside the central platform can become governed once the organization has visibility, ownership, provenance, a defined audience, and a coherent trust state around it.

That is a more useful boundary than sanctioned application versus unsanctioned application because it tracks the thing the organization increasingly cares about: reusable behavior.

It also exposes risks that application-level controls cannot resolve by themselves. A reusable capability can embed outdated policy, contain a dangerous instruction, pull in an unsafe dependency, expose a credential, overreach in the permissions it requests, or quietly become business-critical while remaining owned by one employee's account. It can drift after review. It can be copied and modified until several teams are using versions that look related but have no clear lineage. These are capability lifecycle problems. Blocking another website will not solve them.

Progressive trust is a better model than binary approval

Once the capability is the object being governed, binary trust becomes difficult to defend. "Approved" is only useful if we can say what was approved, for whom, in which version, under what conditions, and for what type of use. A capability that is appropriate for a security engineer to experiment with against synthetic data may not be appropriate for organization-wide use. A workflow that is reasonable for one team may become materially riskier when connected to production systems. A version that passed review last month may deserve another look after someone adds a new tool, expands the audience, or changes the instructions.

Trust should therefore be progressive and scoped. Registration establishes that something exists. Automated analysis can establish basic facts and surface obvious problems. Ownership and provenance make responsibility and history explicit. A capability can remain constrained to its creator or team while those facts are being established. Broader distribution can follow when the evidence supports it. Higher-impact uses can require deeper human review. Explicit risk can narrow or block use at any point.

This is not a claim that every organization should use the same sequence of labels. The important thing is the separation of concepts. Visibility is not approval. Approval is not access. Access is not distribution. When those states are independent, the organization can know about a capability without pretending to trust it universally, and it can trust a version for one context without automatically exposing it everywhere.

Versioning is particularly important here. If the organization approves a capability and the capability subsequently changes, the old approval should not become an inherited property of the name. The relevant question is which revision the evidence applied to. A small documentation change may not require the same response as adding code execution or a new external integration, but that determination is possible only if the system knows that a change occurred. An approval system built around mutable artifacts eventually loses the ability to explain what was actually evaluated.

Risk itself should also be grounded in what the capability can affect. Data sensitivity matters. So do connected systems, permissions, external actions, autonomy, audience, provenance, and the consequences of failure. A private brainstorming workflow using public information does not deserve the same governance burden as an agent that can modify payroll data, even if both happen to invoke the same underlying model. Treating them equivalently does not create stronger governance. It consumes scarce review capacity on low-impact activity while making the high-impact activity harder to distinguish.

The purpose of progressive trust is therefore not to lower the bar. It is to put the bar in the right place.

The organization needs a way to absorb what employees learn

The most interesting part of Shadow AI may be what happens after visibility.

Suppose an employee creates a genuinely useful capability. It survives long enough to become part of the team's routine, and other employees begin asking for access. A governance system that can only decide whether the original application is allowed has very little to contribute at this point. The organization needs to capture the capability itself. It needs an owner, a version history, provenance, a defined audience, whatever automated checks are appropriate, a review process proportionate to the risk, and a way to distribute the trusted version so other employees do not have to recreate it independently.

This is where governance and adoption stop being opposites. The same infrastructure that allows security to understand what exists also allows the organization to reuse what works.

Without that infrastructure, successful experimentation tends to fragment. Someone posts instructions in a chat channel. Another employee copies them and makes a small improvement. A third team independently builds something similar because they do not know the first version exists. Nobody knows which copy is authoritative. The original creator changes roles. Six months later, the organization may be relying on several pieces of AI-enabled process without having intentionally adopted any of them.

That outcome is not especially safe, but it is also economically wasteful. People are spending time developing organizational knowledge, and the company is failing to compound it.

A mature Shadow AI program should therefore measure more than how many applications were blocked. Blocking can be necessary, but it is an odd primary measure of whether governance is working. I would care more about how much reusable AI activity is visible, how many shared capabilities have identifiable owners, how quickly low-risk work can move from personal experimentation to trusted team use, whether high-risk capabilities reliably receive deeper review, how much duplication exists across teams, and whether employees increasingly choose the governed path because it is actually useful.

The goal is not zero experimentation outside a central approval queue. I am not sure that is achievable, and I am not convinced it would be desirable. The goal is to reduce the blind spots and incentives that cause useful work to remain permanently outside organizational visibility. We should be able to distinguish an experiment from a shared capability, a shared capability from a production dependency, and an unknown artifact from one that evidence tells us should actually be blocked.

Commonset is being built around that incentive model. Capabilities can be discovered and registered without treating registration itself as a security finding. Ownership, provenance, versions, automated analysis, trust state, audience, and distribution can accumulate as the capability matures. Explicit risk can restrict use when necessary. Useful work can progressively earn broader trust rather than waiting outside the system until somebody is willing to declare it universally approved.

That is the governing principle I would use for Shadow AI: make visibility cheap, make trust explicit, and make restrictions follow risk rather than discovery.

If telling the organization what you built is the point where the useful work stops, people will continue finding reasons not to tell you.

If the governed path helps useful work become safer, durable, and easier to reuse, you have a much better chance of bringing it into the light.