Shadow AI: Governing the Tools Your Team Already Uses

Someone on your team pasted customer data into a chatbot this week. You did not approve the tool, you cannot see the prompt, and a third party now holds a copy. That is shadow AI, and pretending a ban will stop it is the most expensive assumption in your security program.

Shadow AI is a demand signal, not a discipline problem

When employees route around IT to use ChatGPT, Claude, Gemini, or one of the hundreds of AI wrappers on the market, they are telling you something precise: the sanctioned toolchain is slower than the unsanctioned one. Treat that as product feedback, not insubordination.

Ban the tools and three things happen, every time:

• Usage moves to personal phones and personal accounts, where you have zero visibility and zero contractual protection.
• Your best people, the ones who automate their own work, are the first to defect. You end up policing your highest performers.
• The organization loses the productivity gain while keeping all of the risk, because the data still leaves. It just leaves through channels you cannot log.

In our experience, companies that run a discovery exercise find several times more AI tools in active use than leadership expected. Marketing has a copywriting tool on a personal card. Engineering has a code assistant in half the IDEs. Finance is summarizing contracts in a free-tier chatbot. None of it went through procurement.

The goal of governance is not zero shadow AI. The goal is to make the sanctioned path faster and safer than the shadow path, then verify with controls instead of trust.

Where the data actually leaks

"Data leakage" is vague. Be specific about the mechanisms, because each one needs a different control.

The four leakage paths

• Prompt content. An employee pastes source code, customer PII, financials, or credentials directly into a consumer chatbot. On free tiers, that content may be retained and used for model training under the default terms. This is the classic case and still the most common.
• Retained context. Even on paid tiers, conversation history, uploaded files, and "memory" features persist on vendor infrastructure. A compromised personal account exposes months of accumulated company context in one shot.
• Browser extensions and plugins. AI extensions often request page-read permissions. That means every internal dashboard, CRM record, and email the user views can be transmitted to the extension vendor. This path bypasses your DLP entirely because it reads the rendered DOM.
• OAuth grants and agents. "Connect your Google Drive" and "let the agent read your inbox" are standing grants, not one-time transfers. An AI agent with a Drive scope is a permanent exfiltration channel that survives the session. Attackers know this too, and increasingly target these grants directly, a pattern we broke down in AI-powered cyber attacks in 2026.

Rank these for your own environment. For most companies, extensions and OAuth grants are the underestimated pair: invisible in network logs that only watch for chatbot domains, and durable long after the employee stops using the tool.

Discovery: find what is already running

You cannot govern what you cannot see. Run discovery before you write a single line of policy, or the policy will regulate an imaginary environment.

• DNS and proxy logs. Pull 30 days of egress and match against known AI endpoints. Even a simple query surfaces the big picture:

SELECT domain, COUNT(DISTINCT src_user) AS users, COUNT(*) AS requests
FROM dns_logs
WHERE domain SIMILAR TO
  '%(openai|anthropic|gemini.google|perplexity|midjourney|huggingface)%'
  AND ts > NOW() - INTERVAL '30 days'
GROUP BY domain ORDER BY users DESC;

• OAuth audit. In Google Workspace or Entra ID, list third-party apps with granted scopes. Sort by scope sensitivity (mail.read, drive, files.readwrite). Revoke anything unrecognized, then set an admin-approval requirement for new grants.
• Expense and card data. Search for recurring charges from AI vendors. Personal-card SaaS is shadow IT's oldest trick and it works just as well for AI.
• Browser extension inventory. Enterprise browser management (Chrome Browser Cloud Management, Edge management) gives you the installed-extension list per user. Flag anything with read and change all your data on websites you visit.
• Amnesty survey. Announce a two-week no-consequences window: tell us what you use and why, and we will try to sanction it or find an equivalent. You will learn more from this than from any scanner, but only if you honor the amnesty.

A three-tier decision framework

Do not evaluate tools one by one from scratch. Classify every discovered tool into one of three tiers, with published criteria so the decision is predictable.

• Tier 1, Sanctioned. Enterprise agreement in place. Training on your data contractually excluded. SSO enforced, audit logs available, data residency acceptable. These tools get promoted internally, paid for centrally, and preloaded with your prompt libraries.
• Tier 2, Tolerated with guardrails. Useful tools without enterprise terms. Allowed only through the gateway (below), only with redaction active, and only for data classified as public or internal. Never for client data, PII, or source code of proprietary systems.
• Tier 3, Blocked. No acceptable terms, excessive permissions, or vendor opacity. Blocked at DNS and in the browser, with the block page linking to the Tier 1 equivalent. A block without an alternative is a request to be circumvented.

The tradeoff is real: a strict Tier 1-only posture is cleaner to audit but starves teams of niche tools, which regrows the shadow. A generous Tier 2 keeps people inside the tent but multiplies your monitoring surface. Pick based on your data sensitivity, not your ambition.

Put a gateway between your team and the model

The single highest-leverage control is an AI gateway: a proxy that sits between your users and every model provider. All sanctioned AI traffic flows through it. This converts an unobservable problem into an engineering problem.

A minimal LiteLLM proxy setup illustrates the pattern:

model_list:
  - model_name: chat-default
    litellm_params:
      model: azure/gpt-4.1
      api_base: https://your-tenant.openai.azure.com
  - model_name: chat-sensitive
    litellm_params:
      model: anthropic/claude-sonnet-4-5

litellm_settings:
  callbacks: ["presidio"]        # PII detection and masking pre-call
  max_budget: 2000               # monthly USD cap, org-wide
  budget_duration: "30d"

general_settings:
  master_key: os.environ/GATEWAY_MASTER_KEY
  database_url: os.environ/DATABASE_URL   # per-key usage logging

What the gateway buys you:

• Central logging. Every prompt and completion is logged under a per-user or per-team key. When an incident happens, you have forensics instead of guesses. Feed these logs into the same triage flow as the rest of your incident response playbook.
• Redaction before egress. PII masking (Presidio, custom regex, or a small classifier model) runs before the prompt leaves your perimeter. Imperfect, but it converts "everything leaks" into "some edge cases leak."
• Provider portability and cost control. One endpoint, many models. You can route by sensitivity tier, enforce budgets per team, and swap providers without touching client code. The same routing layer is where most teams later implement the techniques from our LLM cost optimization guide.
• Kill switch. One config change disables a compromised key or a misbehaving tool, instantly, everywhere.

The failure mode to avoid: a gateway that adds 800 ms of latency or breaks streaming. If the sanctioned path feels worse than pasting into a free chatbot, people will paste into the free chatbot. Budget real engineering time for latency, streaming passthrough, and IDE integration. The gateway must win on experience, not just on policy.

Write a policy people actually read

Most AI policies are eight pages of legal prose that nobody opens after onboarding. Yours should fit on one page. Here is the structure we deploy:

1. State what is allowed first. Open with the sanctioned tools and what they are approved for. A policy that opens with prohibitions trains people to stop reading.
2. Define data classes in plain words. Three classes are enough: public, internal, restricted. Give five concrete examples of each. "Restricted" must explicitly name customer PII, credentials, unreleased financials, and proprietary source code.
3. Map classes to tiers. One table: which data class may enter which tool tier. This single table is the entire operative policy. Everything else is commentary.
4. Ban personal accounts for work data, explicitly. The account boundary matters more than the tool boundary. Same tool, personal login, different legal reality.
5. Set the disclosure rule for AI output. Who must review AI-generated code, contracts, or client deliverables before they ship, and who owns the result. Ownership stays with the human. Always.
6. Publish the exception path. A named owner, a request form, a 5-business-day SLA. If getting a tool approved takes a quarter, the shadow returns in a week.
7. State the incident rule without menace. "If you pasted something you should not have, report it within 24 hours. Fast reporting is never punished. Concealment is." You want the report, not the confession under audit.

Review the policy quarterly. The AI tool landscape turns over fast enough that an annual review cycle guarantees the policy governs last year's tools.

Guardrails that hold under pressure

Policy without enforcement is a suggestion. Layer these controls, cheapest first:

• SSO everywhere. Every Tier 1 tool behind your IdP. This alone gives you provisioning, deprovisioning, and an audit trail, and it is the control auditors ask about first. It aligns with the identity-first model we cover in zero trust architecture.
• Managed browser policy. Block Tier 3 domains and unvetted AI extensions centrally. In Chrome enterprise policy, an explicit extension allowlist beats a blocklist you will never keep current:

{
  "ExtensionInstallBlocklist": ["*"],
  "ExtensionInstallAllowlist": ["approved_extension_id_1"]
}

• DLP on the paste boundary. Endpoint DLP that inspects clipboard and upload events to AI domains catches the classic paste. Expect false positives early. Tune for two weeks before enforcing block mode, or you will burn your political capital in three days.
• OAuth app allowlisting. Require admin consent for any third-party app requesting sensitive scopes. This closes the standing-grant channel that DLP never sees.

None of these is airtight alone. A motivated insider defeats all of them. The stack is designed for the honest majority who leak by convenience, not malice. That is where nearly all of the real risk lives.

The audit angle

If you are pursuing SOC 2 or ISO 27001, shadow AI is now a standard line of questioning: how do you inventory AI tools, where does regulated data flow, and can you demonstrate the controls. A gateway with per-key logs, an OAuth allowlist, and a one-page policy with review dates is exactly the evidence set auditors want. Teams that built this stack before the audit describe the AI portion as a non-event; teams that did not, describe it differently. If certification is on your roadmap, fold AI governance into the same control set from day one, as outlined in our SOC 2 guide for startups.

How Innovation T can help

Innovation T builds and operates this stack for companies across Tunisia, Europe, and beyond: discovery sweeps, AI gateway deployment with redaction and per-team budgets, browser and OAuth hardening, and policies written to be read. We are engineers first, so the sanctioned path we ship is the one your team actually prefers.

Explore our cybersecurity and cloud services, or talk to us about a shadow AI assessment. The tools are already inside. The only question is whether you govern them or discover them in an incident report.