Shadow AI Is the New Shadow IT: Own the Data Path Before Buyers Ask
Shadow AI is unsanctioned chat tools and wide copilot access. See what to inventory, what to gate, and which proof buyers want, then contact Grey Wing.
6 min read
Shadow IT was an unsanctioned tool, an account nobody owned, and data that moved before anyone wrote a rule. Shadow AI is that pattern in a prompt box.
An employee pastes a customer ticket into a public chat tool, often a consumer ChatGPT account, because the draft is faster. A coding copilot gets repo access because the trial was one click. A browser extension reads pages that include contracts. Nobody has recorded which tool is allowed, which account it uses, or which data must stay inside the company.
SaaS and fintech teams of about 10 to 200 people meet that gap in diligence. Where can customer data go? Which tools are approved? Who said yes? If the honest answer is habit, you do not own the data path yet. This note is operating work for that path. It is not a penetration test of a model, and it is not a certificate.
How the shadow IT pattern shows up in AI tools
Shadow AI means people using AI tools the company did not approve, or sending company or customer data into tools that were not approved for that data. You do not pass this like an exam. You name it, decide, and keep evidence.
Keep a neighbor off this page. If an automated agent holds standing credentials and can take actions, ask how narrow those keys are and what the agent may call. An employee chat policy does not cover that. Give the agent its own row, and review it on its own.
What to inventory
You cannot gate what you have not named. Five columns are enough for a team this size.
Tools. Chat tools, copilots, note takers, browser extensions, and features that send text or code off the laptop, including free consumer accounts used for work. Mark each row sanctioned or not.
Accounts. Company tenant, personal login, or shared seat, and whether entry is single sign on, a local password, or a token. Buyers trip over personal accounts used for work. A company tenant is not a privacy proof. Retention and training settings differ by vendor and plan, so record the setting you checked.
Data classes. Public docs, internal runbooks, source code, customer data, secrets, production logs. A support note with an account number is customer data even if the sender calls it a sample. No named class means no rule.
Integrations. Repo, ticket queue, drive, chat workspace, customer store. A chat box with no connector is not the same exposure as a copilot that can read the repository.
Who approved. Person, date, and reason on every sanctioned row. An owner and a next decision (block, allow with limits, or retire) on every other row. "Everyone uses it" is not an approval.
What to block or gate
A gate is a decision with an owner, plus a control you can enforce. It is not a promise that no prompt ever leaves. A browser rule on one site does not prove the data never left through another tab, a phone, or a personal laptop. Say you reduced a known path. Do not say you closed it.
High risk data into public models. Customer data, secrets, production logs, and material a contract says you may not hand to an unapproved processor do not belong in a consumer chat account. State that in a policy people can repeat. Back it with single sign on into a company tenant, device or browser limits where you have them, and a written deny for those classes. If you have no data loss prevention, say so. Name the gap if a control is missing.
Uncontrolled repo access and copilot scopes. A repository a coding assistant can read is on the data path. Choose orgs, repos, and roles. Prefer company accounts over personal tokens. Review scopes as you review admin access: retain, narrow, or revoke.
Unmanaged keys. Model provider keys, copilot tokens, and extension grants need an owner, a home, and an offboarding step. Rotate what you cannot attribute.
Where the work needs a tool, name the product, the account type, and what must not be pasted. A deny with no approved path sends people back to personal accounts.
What evidence buyers actually want
These buyers are in diligence. They are not issuing an attestation, and they are not asking you to certify that AI use is safe. They want a few artifacts, with owners, that match practice.
A policy for allowed tools, data classes that must stay out of public or personal models, and who may approve an exception.
An inventory of what is in use, sanctioned and not. "We do not use AI" fails when a copilot is enabled.
An approved tools list that matches the inventory and the apps on the identity provider. If they disagree, the list is theater.
Control notes on single sign on, copilot and repo scope, extension installs, and data loss prevention only where it is actually on. Include the gaps. Do not describe a product you have not deployed.
Training people can repeat: what not to paste, which account to use, how to ask for a tool.
An exception log: who asked, who approved, which data class, expiry, and close. Real exceptions on a log beat a claim that exceptions never happen.
What this evidence is not:
- It is not a SOC 2 Type I or Type II report.
- It is not a certification that AI use is compliant.
- It is not an audit opinion.
- It is not proof that a block stopped every prompt.
Whoever owns security and GRC day to day can run the cadence: inventory, allow and deny, evidence a buyer can read, and exception follow through. That is readiness help. It is not an auditor's opinion. An independent firm still owns any formal report.
Grey Wing takes ownership of that security and GRC work for growing SaaS when a team asks. The work is the inventory, the policy, the approved list, and questionnaire answers that cite them. We do not certify AI use. We do not audit you. We do not issue the report.
Practical next steps
If you cannot point to the data path today, use the next month:
- List the tools. Chat tools, copilots, extensions, note takers, model keys. Company account or personal account.
- Name data classes per sanctioned tool, including what must not be pasted. Check the vendor setting rather than assuming the tenant is private.
- Name one approver. Date a decision for every unsanctioned row.
- Gate the sharp edges. High risk data stays out of public models, using policy and controls you can enforce. Narrow copilot and repo scopes. Rotate keys with no owner.
- File the buyer pack. Policy, inventory, approved list, control notes with gaps, training outline, exception log.
- Separate agent credentials. Standing keys on an automated agent get their own review. The chat policy is not that review.
If you want help standing that up, contact Grey Wing. Bring the tools you suspect people already use, and the last questionnaire that asked where customer data goes. We will talk through ownership of the work, not promises about certificates we do not issue.