Shadow AI: the use of AI tools at work that the company hasn't approved, doesn't manage, and often can't see.
Shadow AI doesn't look like a breach. It looks like a tired employee on a Friday, pasting a customer list into a free AI tool to get a report out the door faster. That's the tension every business is living right now. "Do more with less" has been the rule forever, and AI is the first tool in years that actually delivers it. So people use it. Quietly, on personal accounts, on devices IT can't see, whether or not anyone signed off.
Some companies have responded to this risk by banning public AI tools, but banning it doesn't eliminate the risk. No business wants employees pasting source code, credentials, client records, financial reports, or internal strategy into tools the company has never reviewed.
But a ban is not the same as governance. In practice, a ban often just pushes AI use into personal accounts, unmanaged devices, browser extensions, and tools IT cannot see. The behavior doesn't stop. It goes dark.
The better question isn't whether your employees should use AI. They already are, or soon will be. Recent Federal Reserve research puts the share of US workers using AI on the job at around 40 percent and climbing. The better question is whether you can govern it well enough to capture the productivity without exposing sensitive data or expanding access risk.
This is not usually reckless behavior. It is often a good employee trying to summarize a client email, clean up a proposal, troubleshoot code, or move faster under pressure.
None of this is a DTS opinion dressed up as a framework. AI governance has become its own discipline, with structure from NIST's AI Risk Management Framework, a risk catalog in OWASP's Top 10 for LLM Applications, and federal best-practice guidance on AI data security from NSA, CISA, and the FBI. What follows is how that translates for a business that has to run on Monday morning.
Start with visibility, not policy
The first move is not writing the perfect acceptable-use rule. The first move is understanding what is already happening. Which AI tools are in use, by which people and devices, and for what kind of work? Which tools have been granted access to email, files, browsers, SaaS apps, or code repositories? Are people using approved business tools, or personal accounts on unmanaged machines?
In practice, that means reading the signals you already have: DNS, firewall, proxy, EDR, browser, and SaaS logs. It also means looking for AI browser extensions, desktop tools, meeting assistants, code assistants, and personal-account use from unmanaged devices. It avoids the classic mistake of announcing a rule before anyone knows the real behavior.
Shadow AI is mostly copy and paste
Shadow AI often looks less like hacking and more like copy and paste. An employee copies a contract, spreadsheet, ticket history, client email, HR issue, source code, financial report, or operational detail into an AI prompt because they are trying to move faster. The intent may be good. The exposure may not be.
This is where shadow AI becomes a data security problem, and the same discipline you'd apply to data loss prevention applies here. Define what data may never go into public AI tools. Use sensitivity labels where you have them. Configure DLP for regulated, confidential, client, financial, HR, and operational data. Monitor paste, upload, and file-movement patterns where your tooling supports it. And give people approved AI tools that don't train on your business data and come with enterprise controls, so the safe path is also the easy one.
For Microsoft 365 environments, Purview is often part of the answer. It can help with sensitivity labels, DLP, retention, and compliance controls, including endpoint policies that warn or block someone before they paste sensitive data into a public AI site. Those controls only work if they're configured around the way the business actually handles data.
Clean up access before AI agents amplify it
There's a second exposure that gets less attention. AI assistants and agents increasingly act through the user's own permissions. That means bad permissions become worse permissions. An agent connected to a mailbox or a file store can reach whatever that account can reach, and do it at machine speed.
So access cleanup is AI governance. Review local admin rights and remove privileged access nobody needs. Separate admin accounts from daily-use accounts. Review Microsoft 365, Teams, SharePoint, OneDrive, and mailbox permissions, along with OAuth app consent and stale or service accounts. Require conditional access and MFA. And put an approval step in front of any AI agent before it connects to email, files, CRM, ERP, ticketing, or finance. Over-permissioned agents are exactly what OWASP means when it lists excessive agency and sensitive information disclosure among the top risks for LLM applications.
Replace "AI, yes or no" with an approved-use matrix
Most AI policies fail because they try to answer one question, "AI, yes or no?" Real work doesn't fit that. A more useful approach defines categories of use, so people know where the line is without having to guess.
| Use case | Status | Conditions |
|---|---|---|
| Brainstorming marketing ideas | Allowed | No client-confidential data |
| Rewriting non-sensitive emails | Allowed | Human review required |
| Summarizing client contracts | Approved tool only | No public AI |
| Writing code | Approved tool only | No secrets or proprietary code in public tools; review required |
| Analyzing HR issues | Restricted | Approved tool and policy review |
| Uploading customer data | Restricted | Approved enterprise tools only |
| Connecting AI agents to email or files | Approval required | Access review first |
| Letting AI send messages or change records | Approval required | Human approval and audit trail |
A matrix like this gives your team something they can actually follow, and gives you something you can actually enforce.
Provide a safe path, not just prohibitions
The difference between a policy people follow and one they route around is whether it offers a path, not just a wall. A mature model tells people which tools are approved, which use cases are encouraged, and which data types are off limits. It also tells them how to request a new tool, how new extensions and SaaS apps get reviewed, how risky behavior is monitored, what requires human review, and who owns the decision. That is a long way from "nobody use AI," and it is the version employees don't feel the need to evade.
Some of the largest firms have already walked this path. JPMorgan restricted public ChatGPT over data and compliance concerns, then gave employees a governed internal assistant instead, now in the hands of more than 200,000 of them. Restrict the risky route, then provide a safe one.
Govern development use specifically
Software development deserves its own guardrails, because it is where the most sensitive material and the most enthusiasm often meet. AI can be genuinely valuable in development, but it needs rules. Keep secrets, keys, credentials, connection strings, and proprietary or client code out of public AI tools. Use enterprise-approved coding assistants where you can. Require review for AI-assisted code, run secret and dependency scanning, and track AI-generated code like any other third-party contribution. Humans stay accountable for architecture, security, and the final call.
The risk here isn't hypothetical. Samsung temporarily banned generative AI tools company-wide in 2023 after engineers pasted internal source code into a public chatbot. The lesson isn't "ban AI." It's that development needs a governed path before the pasting starts.
Where DTS fits
AI shouldn't be unmanaged, and it shouldn't be ignored. We help Indiana businesses bring AI use into the open, protect sensitive data, and put practical governance in place so people can use AI safely and productively. That is what our AI Readiness Review looks at:
- Visibility: AI traffic, SaaS usage, browser extensions, installed tools, endpoint visibility.
- Data protection: Microsoft 365 access, SharePoint, Teams, and OneDrive sharing, DLP, sensitivity labels.
- Access control: local admin, privileged access, OAuth consent, stale and service accounts.
- Governance: approved-use policy, employee guidance, development-tool exposure, AI agent approval.
The companies that win with AI will not be the ones with the strictest bans or the loosest rules. They will be the ones that make useful AI easy, risky AI visible, and sensitive data hard to mishandle.
That is where DTS can help.
Sources
NIST AI Risk Management Framework and Generative AI Profile
OWASP Top 10 for LLM Applications (2025)
NSA, CISA, and FBI, AI Data Security: Best Practices (May 2025)
Microsoft Purview data security for generative AI
Federal Reserve and St. Louis Fed, generative AI adoption
JPMorgan's internal LLM Suite rollout (CNBC)
Samsung restricts generative AI after source-code leak (TechCrunch)



