What Is Shadow AI, and Why Does It Add $670K to a Breach?
Your employees are already using AI tools you never approved, usually to meet a deadline rather than bypass security. When someone pastes a customer record into a public chatbot or connects a personal API key to an internal workflow, data leaves both your control and your compliance boundary.
TL;DR: Shadow AI is the use of AI tools, models, or accounts without IT or security approval. IBM found that breaches involving shadow AI cost approximately USD 670,000 more than average and were associated with roughly 20% of breaches in its 2025 research. The practical fix is not a blanket ban. It is a sanctioned path that routes every AI call through one governed control point.
Key Takeaways Shadow AI includes employees using public large language models (LLMs), personal accounts, or unmanaged provider keys for company work. Shadow AI is widespread: 78% of workplace AI users bring their own unauthorized tools, according to the LayerX Enterprise AI & SaaS Security Report 2025. IBM’s Cost of a Data Breach 2025 reported that shadow-AI-related breaches cost approximately USD 670,000 more than the average breach. Banning AI without providing a sanctioned alternative pushes usage underground and removes visibility. A guarded LLM gateway can provide approved model access while enforcing personally identifiable information (PII) masking, audit logging, access controls, and data residency.
What is shadow AI?
Shadow AI is the use of AI tools, models, or accounts inside an organization without the knowledge, approval, or oversight of IT and security. It is the AI-era equivalent of shadow IT: an employee pastes a contract into a personal chatbot, or a developer connects an internal application directly to a model provider using an unmanaged key.
The issue is not AI adoption itself. The issue is that security teams cannot inspect, govern, or protect traffic that bypasses corporate controls.
LayerX reported that 78% of AI users at work bring their own unauthorized AI tools. Its 2025 research also found that 77% of employees paste data into generative artificial intelligence (GenAI) prompts, with 82% of that activity coming from unmanaged accounts. Approximately 22% of those paste operations contained personal or payment data, according to the same report.
Common examples include:
- A finance employee uploading a spreadsheet containing customer account details to a personal chatbot.
- A software engineer using a personal OpenAI or Anthropic key in a prototype.
- A sales team copying customer relationship management notes into an AI writing assistant that procurement never reviewed.
- An AI agent calling external tools without an allowlist, audit trail, or regional routing policy.
- An employee using a browser-based AI extension that can read documents, source code, or web applications.
For organizations in Indonesia and Southeast Asia, the exposure also has a sovereignty dimension. Customer names, Indonesian NIK, Singapore NRIC, Malaysian MyKad, addresses, phone numbers, and financial records can leave the approved processing region without a clear record of where they went.
Shadow AI is a control-plane failure, not an employee failure
Shadow AI becomes a breach multiplier when AI traffic bypasses the controls used for other sensitive systems. The root problem is not that employees want to use AI. It is that the organization has not provided a convenient, governed route for doing so.
IBM’s Cost of a Data Breach 2025 found that approximately 20% of breached organizations identified shadow AI as a factor. Those breaches cost about USD 670,000 more than the average breach, reaching approximately USD 4.63 million. IBM also reported that 97% of organizations experiencing an AI-related security incident lacked proper AI access controls, while 63% had no AI governance policy.
The contrast is operationally important:
| Governed AI | Shadow AI |
|---|---|
| Approved model access through a controlled endpoint | Public tools and personal accounts outside IT oversight |
| PII detected, masked, tokenized, or blocked before transmission | Customer records and source code pasted directly into external services |
| Scoped, revocable virtual keys replace shared provider credentials | Personal or hard-coded API keys remain active and difficult to inventory |
| Prompts, responses, and tool calls are logged for investigation | Security teams cannot reliably reconstruct what was sent or returned |
| Routing is pinned to Jakarta, Singapore, or another approved location | Data is sent to whichever endpoint the user or application selected |
| Budgets, rate limits, and model policies apply per team or application | Costs and model usage are difficult to attribute |
A policy document cannot secure a traffic path it cannot observe. When AI requests go directly from an employee’s browser or application to a public provider, data loss prevention (DLP), role-based access control (RBAC), and audit processes may never see the request.
That is why shadow AI should be treated as an architecture problem. The control must exist where the request is made, before sensitive data reaches an external model provider.
Why does shadow AI keep happening? Five root causes
Shadow AI persists because employees are solving real workflow problems faster than internal governance programs are supplying approved tools.
- There is no sanctioned alternative. When employees cannot access an approved model quickly, they use a public service. LayerX found that 78% of workplace AI users bring their own unauthorized tools. The behavior is predictable when the sanctioned path is slower or unavailable.
- Productivity pressure overrides abstract policy. Employees are measured on delivery, response time, and output. A public chatbot can produce an initial draft or code explanation immediately. If the organization removes that tool without replacing the capability, the deadline remains while the activity becomes less visible.
- AI use is fragmented across departments. Engineering may use coding agents, legal may use document tools, and customer operations may use browser assistants. Each team can create a separate provider account, key, and data flow. Without a central inventory, security cannot establish which models process company information.
- Governance has not caught up with the traffic. IBM reported that 63% of organizations affected by a breach involving AI had no AI governance policy. A policy should define approved models, data classes, tool permissions, retention, regional routing, and incident response. It should not stop at “do not paste confidential information.”
- AI agents expand the attack surface. Gartner projects that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from under 5% in 2025. Agents can access files, databases, APIs, and business tools. A compromised prompt or excessive tool permission can therefore create an action path, not merely a data disclosure.
The answer is not to assume employees will stop using AI. The answer is to make the approved route more useful than the unapproved route, then enforce controls at that route.
How do you govern shadow AI and close the gap?
You close the shadow-AI gap by providing a fast sanctioned path and routing every AI request through a single control point. A vendor-neutral design has four layers: approved access, pre-call inspection, controlled execution, and post-call evidence.
1. Provide approved access to the models people actually need
The sanctioned service must support the workflows that created shadow usage. That may include coding agents, document analysis, customer-support drafting, and internal copilots. A limited model catalog or a slow approval process will send users back to personal accounts.
An LLM gateway is the practical control point. It abstracts multiple providers behind one application interface, allowing platform teams to change models without distributing new credentials or rewriting every integration. Anoman AI provides one OpenAI- and Anthropic-compatible API for routing to 400+ models.
The goal is not to force every team onto one model. It is to give every team an approved way to use the models they need.
2. Inspect and minimize data before it leaves the boundary
PII masking should run before a prompt is sent to a model provider. Useful detection policies identify data types such as email addresses, phone numbers, credit cards, IP addresses, URLs, person names, physical addresses, Indonesian NIK, and Singapore NRIC.
The appropriate action depends on the data and workflow:
- Redact values that the model does not need.
- Tokenize values when the application needs reversible substitution.
- Synthesize realistic replacements for testing or development.
- Block requests that violate a non-negotiable policy.
Anoman’s LLM guardrails apply pre-call checks for prompt injection, PII, credentials, and policy violations, followed by post-call checks for unsafe content and sensitive data. The exact policy should be determined by the organization’s risk model, not by a generic default.
Secret detection should cover cloud credentials, GitHub tokens, private keys, JSON Web Tokens (JWTs), and other high-entropy secrets. Prompt injection detection is also important when an agent processes untrusted documents or web content. The objective is to prevent instructions in retrieved content from changing the agent’s authorized behavior.
3. Replace provider credentials with scoped virtual keys
Applications should not contain shared production provider keys. Use virtual keys that can be scoped to an application, team, environment, model set, budget, rate limit, and concurrency limit. Revoke them without rotating every provider credential.
This is a basic control for both security and cost management. It also makes ownership explicit. When a key is associated with a service or team, security and finance can identify who made a request, which model processed it, and whether usage exceeded policy.
Anoman supports virtual keys with the anm-sk- prefix, per-key budgets, rate limits, and in-flight request caps. These are product capabilities, not universal requirements. Any gateway or internal control plane should provide equivalent scoping if it is used as the organization’s enforcement point.
4. Enforce data residency and maintain evidence
Data residency must be enforced at request time, not merely documented in a vendor questionnaire. For Indonesia, teams may need to align processing with UU PDP, the Personal Data Protection Law, Law No. 27 of 2022. In Singapore, organizations must account for the Personal Data Protection Act (PDPA).
A sovereign routing policy should select approved providers and regions, such as Jakarta or Singapore, and reject non-compliant fallbacks. Anoman’s sovereign lock returns HTTP 403 when a request cannot be routed through an allowed provider or region. That fail-closed behavior is materially different from a routing preference that silently falls back elsewhere.
The AI compliance platform supports data-residency policies for Indonesia and Singapore, with append-only audit logging. Audit records should include the identity or service, model, timestamp, policy result, region, token usage, and request outcome. Full prompt retention should be separately governed because auditability and data minimization are not the same requirement.
For teams that cannot send raw traffic to a cloud gateway, an on-premises Edge Collector can provide local guardrail enforcement before requests continue to an approved route.
The architecture succeeds when the compliant path is also the easiest path. A control that users consistently bypass does not govern the organization’s real AI usage.
What does good shadow-AI governance look like? A checklist
A security or platform lead can use this checklist during the next sprint:
- [ ] Maintain an inventory of AI applications, agents, browser extensions, provider accounts, and API keys.
- [ ] Offer a sanctioned AI endpoint that supports required models and developer tools.
- [ ] Route application and agent requests through one LLM gateway or equivalent control point.
- [ ] Detect and handle PII, credentials, and regulated data before provider transmission.
- [ ] Define separate policies for development, production, customer data, and internal data.
- [ ] Replace provider keys in application code and continuous integration (CI) systems with scoped, revocable virtual keys.
- [ ] Enforce Jakarta, Singapore, or another approved region with a fail-closed policy.
- [ ] Log model, identity, policy result, region, usage, and response status for investigation.
- [ ] Define which tools an agent may call, with an explicit allowlist.
- [ ] Test prompt-injection defenses using realistic documents, websites, and tool-call arguments.
- [ ] Review anomalous volume, model changes, unusual regions, and unexpected sensitive-data detections.
- [ ] Measure adoption of the sanctioned path. Low adoption is a control signal, not a user-compliance problem.
The most useful first question is simple: can your team identify which AI tools are processing company data today? If the answer requires a manual survey, visibility is incomplete.
Bring shadow AI into the light with one guarded gateway
Anoman AI gives security and platform teams a single governed route for AI calls, with model access, prompt-injection detection, PII masking, virtual keys, audit logging, and regional routing in one OpenAI- and Anthropic-compatible API. It is designed for teams that need kedaulatan digital and kepatuhan without blocking legitimate AI use.
Book an Anoman demo to review your AI traffic, governance requirements, and Indonesia or Singapore data-residency options.
Frequently Asked Questions
What is shadow AI?
Shadow AI is the use of AI tools, models, or accounts without IT or security approval. Examples include employees using personal chatbot accounts for work, developers connecting applications with unmanaged provider keys, and agents calling external tools without an audit trail. Because the traffic bypasses corporate controls, security teams cannot reliably inspect, govern, or protect the data involved.
How much does shadow AI cost in a data breach?
Shadow-AI-related breaches cost approximately USD 670,000 more than the average breach, according to IBM’s Cost of a Data Breach 2025. IBM associated shadow AI with roughly 20% of breaches in that research and reported an approximate total cost of USD 4.63 million for those incidents. The figures are IBM’s 2025 findings, not a universal fixed cost for every organization.
Why are employees using unauthorized AI tools?
Employees use unauthorized AI tools primarily because the sanctioned alternative is unavailable, slow, or unable to support their workflow. LayerX reported that 78% of workplace AI users bring their own unauthorized tools. The practical response is to provide convenient approved model access, then enforce security and data-residency controls at the point where AI requests leave the organization.
Can you stop shadow AI by banning AI tools?
A ban alone usually does not solve shadow AI because employees can switch to personal accounts, browser tools, or unmanaged API keys. It also reduces visibility. A stronger approach is to provide a sanctioned fast path and make it the default route, with PII masking, access controls, logging, model policies, and regional enforcement applied to every request.
How does an LLM gateway reduce shadow AI risk?
An LLM gateway reduces shadow AI risk by giving teams one approved endpoint for multiple models while enforcing policy on every call. Controls can include prompt-injection detection, PII and secret masking, scoped virtual keys, rate limits, content moderation, audit logs, and region-locked routing. The gateway does not eliminate all risk, but it turns invisible traffic into governable traffic.
Conclusion
Shadow AI is not primarily a story about careless employees. It is a capability and control-plane gap: people need AI to do their jobs, but their requests are bypassing security and compliance boundaries. IBM’s 2025 research linked shadow AI to higher breach costs, while LayerX showed how widespread unmanaged AI use has become.
- Provide a sanctioned path that is as useful as the tools employees already use.
- Inspect prompts, responses, and tool calls for PII, secrets, injection, and policy violations.
- Enforce identity, audit, and data residency through one guarded gateway.
The next step is to inventory actual AI traffic, not only approved applications. For the broader architecture, read What Is an AI Gateway? and evaluate where a single control point can enforce your organization’s AI policy.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "What Is Shadow AI, and Why Does It Add $670K to a Breach?",
"description": "Shadow AI creates unmanaged data and compliance risk. Learn why it increases breach costs and how guarded LLM gateways enforce PII masking, audit, and data residency.",
"author": {
"@type": "Organization",
"name": "Anoman AI",
"url": "https://www.anoman.io/"
},
"publisher": {
"@type": "Organization",
"name": "Anoman AI",
"url": "https://www.anoman.io/"
},
"mainEntityOfPage": "https://www.anoman.io/blog",
"keywords": ["shadow AI", "AI governance", "data loss prevention", "LLM security", "UU PDP", "SEA compliance"]
}
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://www.anoman.io/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Blog",
"item": "https://www.anoman.io/blog"
},
{
"@type": "ListItem",
"position": 3,
"name": "What Is Shadow AI, and Why Does It Add $670K to a Breach?"
}
]
}
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What is shadow AI?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Shadow AI is the use of AI tools, models, or accounts without IT or security approval."
}
},
{
"@type": "Question",
"name": "How much does shadow AI cost in a data breach?",
"acceptedAnswer": {
"@type": "Answer",
"text": "IBM’s Cost of a Data Breach 2025 found that shadow-AI-related breaches cost approximately USD 670,000 more than the average breach."
}
},
{
"@type": "Question",
"name": "Why are employees using unauthorized AI tools?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Employees generally use unauthorized AI tools because the sanctioned alternative is unavailable, slow, or unable to support their workflow."
}
},
{
"@type": "Question",
"name": "Can you stop shadow AI by banning AI tools?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A ban alone usually does not solve shadow AI. A sanctioned, convenient path with centralized controls is more effective."
}
},
{
"@type": "Question",
"name": "How does an LLM gateway reduce shadow AI risk?",
"acceptedAnswer": {
"@type": "Answer",
"text": "An LLM gateway provides one approved endpoint for multiple models while enforcing PII masking, access controls, audit logging, and regional routing."
}
}
]
}