Shadow AI is the use of AI tools or agents for work outside an organization's approved processes. The practical response is to find the task people are trying to complete, decide which parts can be approved, and give them a usable route for doing it. That route might be an approved personal AI account, a shared team agent, or a process that should stay with a person.
The UK National Cyber Security Centre (NCSC) advises organizations to understand why staff use unapproved tools and provide suitable alternatives. Its goal is to reduce the risk, not assume every private AI session can be found or stopped. This guide turns that advice into a workflow decision an operations owner and IT colleague can make together.
What counts as shadow AI at work?
An employee pastes customer notes into a personal AI account to draft a proposal. A developer runs an unapproved agent against a work repository. A team connects an AI service to a shared inbox without the people responsible for that inbox reviewing its access. The tools differ, but in each case the organization has not decided which information or actions belong in that workflow. The NCSC's shadow IT guidance describes this pattern as a gap between the work people need to do and the tools their organization has approved.
The term covers more than accidental data disclosure. An agent can read files, call connected services, edit a record, or send a message, depending on its tools and permissions. The decision therefore has two parts: what information the agent may receive, and what it may do with that information. The NCSC notes that an exploited agent can expose the services and privileges it can legitimately access.
If someone reports unapproved use, treat the report as information about a missing workflow. The NCSC recommends a no-blame approach, since punishment can make the work harder to see. Ask what outcome the person needed, which approved route they tried, and where that route failed.
How do you find the task without pretending to see every tool?
Start with interviews and the workflows people already discuss with their managers. Ask a small group to show the last work task for which AI was helpful, using a sample they are allowed to share. The conversation is about the task, not a list of personal accounts. Record:
- The output. Was it a draft, an answer, a changed record, or a message sent to someone?
- The inputs. Which customer data, internal files, code, or connected apps were involved?
- The blocker. Why did the approved route feel slower, unavailable, or unsuitable?
- The people. Who asked for the work, who needs to see it, and who is accountable for the result?
- The next action. Who reviews the output before it affects a customer or an internal system?
Technical discovery has a separate role. For example, Microsoft's Shadow AI experience in the Microsoft 365 admin center is a public preview for detecting certain unmanaged desktop agents on managed devices, with prerequisites and narrower blocking support. It can help an eligible IT team see part of the picture. It does not tell the team why a proposal writer chose a personal tool or whether a replacement solves that writer's problem.
ChannelGate does not discover or block unrelated private AI tools. It is one option for the approved workflow after the team has identified a suitable use case. Detection and workflow design answer different questions.
Which approved route fits the work?
Keep the decision tied to the task. A shared agent is useful when several people need to supply context, inspect the work, or reuse a method. It adds overhead when one person only needs help phrasing a public sentence. Some actions are better kept outside an agent workflow altogether.
| Route | Good fit | Decision to make first |
|---|---|---|
| Approved personal AI tool | One person drafts or analyzes within an approved data policy | Which data may be entered, and who checks the output? |
| Shared team agent | Several colleagues need a common request, approved sources, and a visible review path | Which people, tools, accounts, and actions belong to the shared workflow? |
| Human or existing system | The task lacks a safe data source, clear owner, or acceptable review point | What must change before automation is considered? |
These are routing choices, not a maturity ladder. An approved personal tool can be the right answer. A shared agent can be the wrong answer if it would expose a private account to colleagues or make an irreversible change before someone checks it.
What would one transition look like?
Consider an illustrative sales workflow. A colleague uses a personal AI account to turn CRM notes and a pricing document into a proposal draft. The goal is a draft the sales team can review, but the private account has no agreed boundary for the customer notes. Moving the exact prompt to another tool would leave the decision about data and review unresolved.
First, the sales owner and IT colleague list the sources: approved CRM records, the current pricing document, and notes the team is allowed to share. They decide whether an agent needs direct access to the CRM or whether a person should supply a limited brief. They name the proposal owner and decide that sending the final proposal remains a human action.
If several people need to shape the draft, they can evaluate a shared agent workflow. In ChannelGate's Slack collaboration model, colleagues can add context and review the result in the same conversation. The operator still has to authorize users, select tools, and choose whether a connected account is personal to the requester or shared with the channel. ChannelGate's connection model keeps those identities distinct; membership in the conversation does not grant another person's personal account. These are documented product controls, not a claim that every proposal is safe to process.
The pilot's first successful result is a reviewed draft produced from approved inputs. If the team later wants the agent to update CRM fields or contact a customer, that is a new access and approval decision. The AI agent governance checklist covers those detailed pilot settings after the use case has been selected.
What should an approved shared workflow expose?
For an agent workflow, write down the boundaries where a request becomes an action. The following questions can be answered on one page before a pilot begins:
| Boundary | Question to answer | Example for the proposal pilot |
|---|---|---|
| People | Who can request and review work? | Named sales staff use the pilot conversation; the proposal owner checks the draft. |
| Information | Which files and records may be used? | The approved brief and current pricing document; no unrestricted customer archive. |
| Identity | Whose connected account reaches each app? | A named requester uses a personal connection, or the team configures a separate shared connection. |
| Action | What may the agent change or send? | Drafting is in scope; sending and CRM updates need a new decision. |
| Evidence | How will the team see the outcome? | Keep the request, resulting draft, corrections, and final human decision together. |
ChannelGate's governance controls let operators set approved users, channel tool grants, Read-only, Worker, or Admin modes, and approval behavior. A shared Slack thread can hold the request, corrections, and result; channel memory and reusable skills can preserve an agreed working method. The selected model provider still receives prompt and context, and connected services receive the relevant requests, as the privacy and data-flow documentation explains. Evaluate those flows against the organization's own data policy before giving the agent access.
How do you know the approved path is useful?
Run one narrow pilot and review it with the people who used the private workaround. Before the pilot, record what slowed them down and what they needed from the output. After a few real attempts, inspect the work rather than counting prompts alone:
- Task completion: Did the approved route produce the draft or answer they actually needed?
- Correction burden: What did a person have to fix, and was the source of each error visible?
- Time to review: Could the named owner inspect the result before an external action?
- Access friction: Did staff need missing files, tools, or permissions to finish the task?
- Return to private tools: Did participants still use the workaround for this same task, and why?
These are pilot questions, not promised results. A route that staff cannot use will leave the original need in place. The NCSC's guidance puts it plainly: "understanding why people are using shadow AI" helps organizations provide suitable alternatives. If the pilot fails, revise the workflow or choose another route rather than widening agent access by default.
Where does this approach stop?
An approved workflow gives the team a place to make access and review decisions for work done there. It does not reveal every personal AI account, prove that no sensitive data was shared elsewhere, or make all agent output correct. Endpoint discovery, data protection, training, and incident response remain separate responsibilities. Microsoft's public-preview detection feature illustrates one such adjacent control, with specific device and license prerequisites.
Nor does a shared conversation replace human ownership. Someone still decides which customer data may be used, checks the draft, and authorizes any external message. The useful test is whether the approved route handles the task well enough that the team chooses it again.
Frequently asked questions
Is shadow AI the same as shadow IT?
Shadow AI is a type of shadow IT: AI tools or agents used for work outside approved processes. AI adds decisions about prompts, model outputs, and what an agent may do through connected tools. The NCSC includes unapproved AI in its shadow IT guidance.
Should we block every unapproved AI tool first?
The right response depends on the tool, the data, and the organization's policy. The NCSC recommends understanding the work need and reducing risk through usable approved alternatives. Blocking alone will not explain which task staff still need to finish.
Can ChannelGate find employees' private AI accounts?
No. ChannelGate governs work that runs through its configured conversations and connected tools; it is not an endpoint discovery product. The Microsoft 365 Shadow AI public preview is an example of a separate detection capability with defined coverage and prerequisites.
Does a shared agent need a shared app account?
No. ChannelGate distinguishes a requester's personal connection from a configured shared connection, so the account choice should follow the work and its owner. A shared conversation should not silently expose one person's private account to everyone else.
What should we test before expanding the pilot?
Check whether the workflow completes a real task with approved inputs, whether people can review the result, and where access or corrections slowed them down. Then use the AI agent governance checklist to revise the policy before granting broader tools or actions.