Shadow AI Examples Across Enterprise Departments
Source code and financial data leak fastest into unsanctioned AI tools across departments.

Shadow AI is not one problem with one fix. It's a different problem in every department, wearing the same trench coat labeled "productivity tool." Developers paste source code into chatbots. Finance analysts reach for whatever tool is free and fast. HR turns to AI screening tools that often bypass legal review entirely. Mapping where this actually happens, department by department, is the only way to see what's really at stake instead of treating "shadow AI" as one vague, undifferentiated threat.
What actually gets exposed when employees use AI without oversight
Source code is the single largest category of sensitive data leaking into AI tools, at 30% of exposures tracked in Harmonic Security's AI Usage Index 2025. Legal material comes second at 22.3%. M&A data is third at 12.6%. That distribution isn't random. It maps almost exactly onto the departments under the most pressure to move fast: engineering, legal, and finance or strategy teams racing deadlines nobody's willing to extend.
IBM's 2025 Cost of a Data Breach report puts a number on the downside: breaches tied to shadow AI carry a cost premium of $670,000 over standard incidents, and roughly one in five organizations has already had a breach connected to an unsanctioned AI tool. The part that makes this different from a normal data-loss problem is permanence. Once information goes into an external model, there's no getting it back out. You can revoke a login. You cannot revoke a training run. And this isn't confined to engineers with laptops full of code. Marketing teams, HR departments, finance desks, operations, legal, all of them show up in the exposure data. Anyone with a deadline and a free tab open for a general-purpose AI tool is a candidate.
Engineering and development: source code, API keys, and the "vibe coding" problem
Developers paste proprietary code into public chatbots to debug it, refactor it, or get a second opinion on a function that isn't behaving. Personal accounts on general-purpose AI tools run in parallel with sanctioned corporate tools, creating an information pipeline that nobody on the security team has ever seen a log from.
There's a newer pattern layered on top of this, sometimes called "vibe coding." A developer describes what they want in loose, conversational terms rather than a precise spec, the model spits out code, and that code gets merged with a light glance instead of a real review. Validation steps go missing. Insecure patterns slip in quietly. Nobody notices because the code runs.
The API layer compounds it. Engineering teams spin up prototypes wired directly into OpenAI, Anthropic, or Hugging Face endpoints, and production data has a way of wandering into testing environments that were never meant to hold it. Two incidents from the past year make the mechanism concrete. The Moltbook AI agent platform leaked roughly 1.5 million API tokens, including plaintext OpenAI keys exposed in the platform's data, an early look at how one credential leak can cascade across an AI deployment. Separately, Lasso Security reported in February 2025 that Microsoft Copilot could still reach more than 20,000 GitHub repositories that had since been made private, exposing code belonging to over 16,000 organizations. Deleting a repo, it turns out, is not the same as deleting its footprint.
Prompt injection adds a version of this risk that doesn't require anyone to steal anything. An indirect prompt injection got Cursor's AI agent to write a malicious .cursor/mcp.json configuration file without asking permission first, opening the door to remote code execution. In a separate case, a developer's agent read a booby-trapped GitHub Issue through the GitHub MCP server, got redirected into private repositories it had no business touching, and exfiltrated data through a public pull request. No credentials were stolen. The agent just did what it was told, by the wrong party.
Finance: earnings data, M&A information, and decisions made on unvalidated outputs
Analysts upload budget models, forecasts, and quarterly performance data into public AI tools because summarizing forty pages by hand takes an hour and asking a chatbot takes forty seconds. M&A data is the third-largest category of sensitive information leaking into AI tools industry-wide, at 12.6%. In a finance context that phrase covers deal terms, valuations, and details about transactions that haven't been announced yet.
Then there's the second-order risk: teams feeding AI-generated financial analysis straight into strategic decisions without checking whether the output is right. Models hallucinate. They also inherit bias from whatever they were trained on. Neither problem announces itself, and a forecast that's wrong reads exactly like a forecast that's right until the quarter ends.
Financial data carries its own regulatory weight, covered by securities law, GDPR, and various data residency requirements depending on where the company operates. Feeding it into an unapproved model is a compliance violation the moment it happens, whether or not anything ever leaks. And because a lot of this activity runs through personal browser logins or through AI features quietly built into spreadsheet add-ins and BI dashboards, standard audit trails show nothing unusual. Nothing crashed. Nothing tripped an alarm. The data just left.
HR and recruiting: candidate screening, employee data, and bias risk outside any policy
HR teams use AI to screen résumés, draft job postings, and summarize performance reviews, often without legal or IT ever hearing about it. What's flowing through these tools includes names, addresses, salary history, health information, and demographic data, all of it covered by GDPR, CCPA, HIPAA where health data is involved, and employment discrimination law.
The bias risk here is structural, not incidental. A screening model trained on historical hiring data will happily reproduce historical hiring bias, and without an audit trail, nobody can catch the pattern, let alone defend against it in court. This is why the EU AI Act puts employment systems in its high-risk category under Annex III, imposing compliance obligations for any AI used in hiring. Shadow HR tools satisfy none of it, because by definition nobody's tracking them.
The same behavior turns up outside HR proper. A customer support manager standing up an AI chatbot without routing it through IT or compliance is the same move, wearing a different department's badge. What makes HR's version worse is the nature of the harm. This is more than just a leaked spreadsheet. It's a hiring decision that might be discriminatory, made by a system with no paper trail, that nobody can reconstruct after the fact.
Sales and marketing: CRM records, customer data, and content that goes out under the company's name
Sales reps copy CRM records, names, deal stages, contact histories, into browser AI tools to draft outreach emails faster. That's customer data and pipeline intelligence sitting on servers the company has no contract with. Marketing runs its own version: drafting copy, generating images, testing headline variants, often through AI features baked directly into platforms the company already approved.
That last part matters more than it sounds. Approving a CRM platform doesn't mean approving every AI feature a vendor quietly adds to it later. A sales team turning on an AI-generated summary field inside an already-sanctioned tool has created shadow AI exposure without installing a single new thing. Nobody signed off on it because there was nothing to sign off on, technically.
Content that comes out of unapproved tools carries fuzzy intellectual property ownership, and any error or biased output that reaches a customer becomes a reputational problem with no clear source to trace it back to. Customer PII fed into these tools can violate GDPR processing agreements or CCPA disclosure rules on its own, regardless of whether anything else goes wrong. And once that data's gone, there's no reliable trail showing where it went.
Legal and compliance: the department least expected to generate shadow AI risk
Legal discourse is the second-largest category of sensitive data exposed through AI tools, at 22.3%, which is an odd thing to sit with given that legal is usually the department writing the data-handling policy everyone else is supposed to follow.
Lawyers use AI to draft contracts, summarize depositions, research case law, and prep regulatory filings, and in the process, privileged client communications and litigation strategy go straight into a model owned by someone else. That's not a minor technicality. Content shared with an external AI tool may not retain attorney-client privilege at all, and a court could compel disclosure of exactly what was shared, at exactly which point nobody kept a record of.
Compliance teams have a matching problem one layer down. They use AI to interpret regulatory requirements, then act on the answer without checking it. If that answer was hallucinated or built on outdated guidance, there is no audit trail showing how the conclusion got made, which is precisely the kind of failure compliance exists to prevent. The irony writes itself: if the department responsible for governance can't govern its own AI use, then policy documents alone were never going to solve this. It has to be enforced technically, at the point where the traffic actually flows, regardless of who's on the other end of the keyboard.
The pattern across departments: ungoverned AI agents that touch everything
Every department's shadow AI problem starts small: one tool, one data type, one employee trying to save an hour. The risk stops being small once those tools get chained into agents that touch multiple systems at once. An internal AI agent built to automate a workflow or answer employee questions can become an unintended backdoor into sensitive systems the moment it's deployed without tight access controls, and that's not an engineering-only problem anymore.
Adoption of the Model Context Protocol (MCP), the standard letting AI agents plug into internal APIs and data stores, has surged dramatically in 2025, and many of those deployments are reported to have bypassed formal security review. The GitHub MCP incident described earlier is the cross-department version of this in miniature: an agent holding a broadly scoped token got exposed to untrusted content in one system and used it to cross into a private repository in another. No credentials stolen, no dramatic breach. Just an agent with more access than anyone meant to give it, following instructions from a source nobody vetted.
GenAI traffic reportedly climbed more than 890% in 2024, and Menlo Security tracked a 68% jump in shadow generative AI use across enterprises in 2025. That's the base layer. Agents are stacking on top of it. Gartner projects that by 2030, more than 40% of enterprises will face a security or compliance incident tied directly to unauthorized shadow AI, and that number is the arithmetic of every department's small, individually reasonable shortcut compounding into something nobody sized correctly.
What detection actually requires, department by department
Standard network monitoring wasn't built for this. Employees reach AI tools through personal accounts, browser extensions, and features quietly embedded in software the company already approved, and to a firewall, that traffic looks identical to any other HTTPS request. There's no port to block, no obviously suspicious domain, nothing.
Real detection means layering several imperfect methods on top of each other: DNS monitoring and CASB tools to catch AI traffic at the network level, browser-layer visibility to catch extensions and web apps, SaaS audit logs checked specifically for AI feature activation, and expense report audits to surface the personal subscriptions employees are quietly billing back to the company. Anonymous surveys help too, though they come with a catch: a large share of employees actively conceal their AI use from employers, so getting honest answers requires making it clear nobody's getting fired for admitting it.
The signals worth watching differ sharply by department. Engineering: repository access patterns, outbound calls to AI provider endpoints, MCP traffic with no authentication headers attached. Finance: large document uploads to outside domains that spike right around earnings season or a deal closing. HR: employee record exports followed shortly by traffic to AI tool domains. Sales and marketing: CRM data exports that line up with AI platform logins. Legal: document uploads to external AI tools from accounts that hold privileged material. Cisco's research puts the share of organizations that can't reliably detect shadow AI at 60%, which means most companies reading this don't actually know what's already happened. Detection is an ongoing effort with no end date. It's ongoing, and every finding should feed back into policy and into which tools get formally approved next, not into a disciplinary hearing. Ban a tool outright and workers just find another way in, further from anyone's view than before.
Building a governed AI layer that addresses the department-level patterns
Policy documents don't fix this, and the legal department's own 22.3% exposure share is the proof. If the team that wrote the AI usage policy is itself pasting privileged material into public models, then awareness was never the missing ingredient. Behavior has to be governed at the technical layer, where the traffic actually moves, not at the layer where someone signs a memo saying they read the rules.
That means controls that sit close to the data: visibility into which AI tools are in use across every department, not just the ones IT happened to buy; access rules that follow the sensitivity of the data itself, whether it's source code, an earnings model, or a résumé, rather than trusting whichever employee touches it that day; and sanctioned alternatives good enough that people stop reaching for the unapproved option out of habit. None of this closes the gap by itself. Together, applied consistently across engineering, finance, HR, sales, legal, and whatever new department discovers a chatbot next quarter, it's the only version of governance that has a chance of catching up to how fast the shadow version is already spreading.
Sources
- 2025 Volume 19 From Shadow IT to Shadow AI Navigating the New Frontier of Enterprise Risk
- Shadow AI: The Silent Cyber Risk Every CISO Must Confront in 2025
- Shadow AI explained: risks, costs, and enterprise governance
- harmonic.security
- Real-World Shadow AI Examples & Governance Strategies
- labs.cloudsecurityalliance.org


