Shadow AI is the unsanctioned use of AI tools, models, and agents by employees without IT knowledge or approval. The practice is widespread and largely invisible to security teams — which is exactly what makes it expensive.
According to IBM's 2025 report, organizations with high levels of shadow AI pay $670,000 more per breach than those with low or no shadow AI, bringing the expected total to $4.63M. That gap reflects unmonitored data flows, ungoverned model access, and credentials passed to third-party AI services outside any security perimeter.
The scale is harder to dismiss than most security teams expect. Developers, finance staff, HR, and operations are all adopting AI tools on their own terms. This article breaks down what shadow AI actually looks like in enterprise environments, why it creates security and compliance exposure, and what IT teams can do to get ahead of it.
What is Shadow AI?
Shadow AI is any AI tool, model, plugin, or agent used within an organization without explicit IT or security approval. It sits at the intersection of Shadow IT and generative AI, inheriting the governance blind spots of the former and adding the data-processing risks of the latter. According to Varonis data, 98% of organizations have employees using unsanctioned apps, including shadow AI.
The scope is wider than most security teams assume.
| Category | Examples | Primary risk |
|---|---|---|
| Generative AI tools | Personal ChatGPT, Claude, Gemini accounts used for work tasks | Sensitive data sent to third-party servers without enterprise data agreements |
| AI browser extensions | Grammar checkers, summarizers, meeting assistants | Silent processing of page content, including internal documents and credentials |
| Unapproved AI SaaS | Legal AI, marketing copy tools, code assistants adopted by individual teams | No procurement review, no DPA, no visibility into data retention policies |
| AI agents | Autonomous systems with OAuth permissions to read files, call APIs, take actions | No organizational-level logging; delegated access persists after employee departure |
| AI-powered IDE plugins | Cursor, Tabnine, unapproved Copilot instances in developer environments | Proprietary codebases and internal API schemas exposed to external model providers |
| AI meeting tools | Otter.ai, Fireflies, Notion AI connected to video conferencing | Conversations recorded and stored on third-party servers without IT approval |
| AI data analysis tools | AI analytics platforms receiving internal datasets and financial reports | Customer records and financial data processed outside the approved data stack |
| AI-enhanced email and calendar tools | Plugins with full mailbox access granted via OAuth | IT-invisible access to communications; OAuth tokens rarely audited or revoked |
AI agents represent a qualitative shift in risk. A spreadsheet stored in an unapproved cloud drive is a data exposure problem. An AI agent with delegated access to your email, calendar, and file system is an access governance problem.
Shadow IT vs. Shadow AI: Understanding the risk multiplier
Shadow IT and Shadow AI both involve employees using tools outside IT's visibility. The risk profile is fundamentally different.
Shadow IT (unauthorized SaaS, personal cloud storage, unmanaged devices) primarily creates data residency and compliance problems. Data sits somewhere IT doesn't control. The exposure is largely static.
Shadow AI processes data. It reasons over it, summarizes it, generates outputs from it, and in the case of agentic systems, acts on it. The exposure is dynamic and often irreversible.
| Dimension | Shadow IT | Shadow AI |
|---|---|---|
| Primary risk | Data residency | Data processing + model training |
| Exposure type | Static (data at rest) | Dynamic (data in motion, in prompts) |
| Reversibility | Moderate (revoke access) | Low (data may train public models) |
| Autonomous action | None | Yes — AI agents act without human review |
| Audit trail | Partial | Often none on personal/free-tier accounts |
| Compliance scope | GDPR, data sovereignty | GDPR + AI Act, IP, trade secrets |
The SaaS sprawl problem compounds this. Employees use 665+ AI tools across a typical enterprise environment, according to Harmonic Security's analysis of 22 million enterprise AI prompts (2025). Six applications account for 92.6% of sensitive data exposure but blocking the remaining 659 is operationally futile and destroys productivity. The governance challenge is visibility, classification, and controlled access.
The financial impact: Why Shadow AI costs enterprises $670K per breach
According to IBM's 2025 Cost of a Data Breach Report, breaches involving high levels of shadow AI add $670,000 to the average breach cost compared to those with low or no shadow AI — a 16% increase, bringing the expected total to $4.63M per incident.
Two underlying statistics explain the mechanism:
- 97% of organizations that experienced an AI-related security incident lacked proper AI access controls.
- 63% of breached organizations had no governance policies for managing AI or detecting unauthorized use.
The causal chain is direct. Employees adopt AI tools faster than security teams can evaluate them. Without access controls, sensitive data flows into models that IT never approved and cannot audit. When a breach occurs, the absence of logging and governance extends detection and containment time — and in breach economics, time is the primary cost driver.
The Shadow AI chain
controls
revocation
trail
validation
governance
For CFOs, the calculation is straightforward: the expected cost of a shadow AI-related breach is $4.63M. The cost of an enterprise AI governance program — access controls, CASB deployment, approved tool licensing, credential management — is a fraction of that. The risk-adjusted case for governance investment is not ambiguous.
Security teams also face a DLP (Data Loss Prevention) blind spot: most DLP tools inspect structured data transfers. Conversational AI prompts are unstructured text. An employee typing a database connection string into a free-tier LLM account generates no DLP alert. The data leaves the organization silently.
The hidden threat: Credential exposure and AI agents
The most direct and underreported shadow AI risk is credential exposure. Employees paste secrets into public LLMs constantly because it's the fastest path to getting help.
A developer debugging a production issue pastes a database connection string into ChatGPT along with the error log. A DevOps engineer shares a Kubernetes config file, including embedded API keys, with an AI assistant to ask about a deployment failure. A finance analyst uploads a Q3 projection spreadsheet to an unapproved AI summarization tool to prepare for a board meeting.
According to Harmonic Security's analysis of 22.4 million enterprise AI prompts (2025), code, legal documents, and financial data comprise 74.5% of sensitive data exposed to AI tools. Source code alone carries embedded secrets (hardcoded API keys, access tokens, and service account credentials) that most developers treat as configuration details rather than security-critical material.
The agentic risk layer adds a second attack surface. AI agents — systems that use delegated OAuth permissions to read files, send emails, query databases, and call external APIs — operate with broad access grants that were never designed for autonomous use. When an employee authorizes a productivity AI agent to access their corporate email and file storage, that agent may have broader effective permissions than the employee's own role warrants.
Most organizations have no inventory of which agents hold which OAuth grants, and no process for revoking them when an employee leaves.
16.9% of all sensitive data exposures in Harmonic's dataset flowed through personal free-tier accounts — where IT has zero visibility, no audit trail, and data may be used to train public models (Harmonic Security, 2025).
The combination of credential exposure and agentic access creates a compounding risk: a compromised AI agent with access to a vault of unmanaged secrets can exfiltrate far more than a single leaked API key.
Real breaches tied to Shadow AI
These three incidents share a common thread: in each case, an AI component operating inside a trusted environment accessed far more data than anyone had explicitly authorized.
Microsoft AI Research: 38 TB of internal data exposed
What happened. A Microsoft AI research team published an open dataset on GitHub for training image recognition models. To share the files, they used an Azure SAS token — but configured it with full access to the entire Storage Account instead of the target folder. Anyone following the repository link got unrestricted access to 38 TB of private company data.
What leaked. Workstation backups from two employees, over 30,000 internal Microsoft Teams messages from 359 staff members, private keys, service passwords, and secret tokens. The token carried "full control" permissions and was set to expire in 2051.
Why this is a Shadow AI incident. The breach happened directly in the course of AI dataset work. Researchers, moving fast to ship AI models, bypassed standard access review procedures. Wiz Research, which discovered the exposure, described it as "a new class of risk organizations face as they accelerate AI adoption." Because the token granted write access, an attacker could have injected malicious code into AI models that other developers were actively downloading.
Response. Wiz disclosed the incident publicly in September 2023. Microsoft revoked the token and closed access. The case became a reference example in IBM's Cost of a Data Breach 2025 report.
Slack AI: Data exfiltration from private channels via prompt injection
What happened. Researchers at PromptArmor found a critical vulnerability in Slack AI — the built-in assistant that lets employees query their entire Slack history in natural language. The attack class was indirect prompt injection: a threat actor posts a message in a public channel containing hidden instructions for the LLM. When a target uses Slack AI to search for information, the model treats the malicious instructions as legitimate and executes them.
What was at risk. API keys and other secrets stored in private channels the attacker had no direct access to. Slack AI aggregated data from both public and private channels when answering user queries — that cross-channel access was the attack vector. A second scenario allowed Slack AI to render a phishing link to capture credentials.
Why this is a Shadow AI incident. Slack AI is a textbook embedded shadow AI case: an AI feature activated inside an already-approved corporate tool, with no separate security review of its AI component. IT teams had no visibility into the fact that the assistant could reach private channels and serve as an exfiltration vector. On August 14, 2024 (the same day the vulnerability was disclosed) Slack expanded the assistant's capabilities to index uploaded documents and Google Drive files, widening the attack surface further.
Response. Slack initially classified the behavior as "intended," then issued a patch. The company stated there was "no evidence of unauthorized customer data access." The incident was widely covered as the first documented case of data exfiltration via prompt injection in a production enterprise SaaS product.
Microsoft 365 Copilot: EchoLeak, zero-click data exfiltration
What happened. Researchers at Aim Security disclosed CVE-2025-32711 (CVSS 9.3 — Critical) in Microsoft 365 Copilot, named EchoLeak. It is the first documented zero-click prompt injection with confirmed data exfiltration in a production AI system. The attack required no action from the victim.
How it worked. An attacker sent the target an email containing hidden instructions disguised as reference-style Markdown links. When Copilot processed the email, it bypassed the built-in XPIA classifier (prompt injection protection) and the link-redaction mechanism. Copilot then automatically accessed the victim's files in OneDrive, SharePoint, and Teams, constructed a URL through the Microsoft Teams Proxy API — which sits on Copilot's allowlist — and sent the data to the attacker's server. No clicks required.
What was at risk. Any file or conversation accessible to the user within Microsoft 365: OneDrive documents, SharePoint files, Teams messages. By mid-2024, more than 10,000 companies were already running Microsoft 365 Copilot, according to Netrix Global.
Why this is a Shadow AI incident. EchoLeak represents the next generation of shadow AI risk: an AI agent with broad access to corporate data, operating inside a sanctioned tool, with no adequate security review of its AI component. The attack left no traces in standard monitoring systems — all traffic moved through trusted Microsoft domains.
Response. Microsoft issued an emergency patch in June 2025. The case fundamentally changed how the industry assesses risk for AI agents with wide access permissions.
How to detect and prevent Shadow AI in the enterprise
Detection and prevention require a structured approach. Banning AI entirely does not work — Harmonic's data shows employees use AI tools regardless of policy, often through personal devices and accounts that bypass corporate controls entirely. The goal is governance, not prohibition.
The 5-step Shadow AI governance framework
- Discover AI exposure. Deploy network monitoring to identify outbound traffic to known AI domains. Use a Cloud Access Security Broker (CASB) to gain visibility into SaaS usage across managed devices. Audit browser extensions on corporate endpoints — many AI tools operate as extensions with broad page-content access. Build an inventory of what's actually in use before writing policy.
- Define acceptable use policies. Classify AI tools into three tiers: approved (enterprise-licensed, data processing agreements in place), conditional (permitted for non-sensitive tasks only), and prohibited (no data sovereignty controls, public model training). Publish the policy.
- Implement RBAC for AI tools. Role-based access control (RBAC) applies to AI tool access the same way it applies to any other system. Developers should not have access to financial AI tools. Finance teams should not have access to code repositories fed into AI pipelines. Scope access grants to the minimum required for each role. Review quarterly.
- Provide sanctioned alternatives. Employees adopt shadow AI because approved tools are slow to procure or inadequate for the task. For every prohibited tool category, provide a sanctioned alternative with equivalent capability. If developers need an AI coding assistant, give them one with enterprise data controls. Governance without enablement creates resentment and workarounds.
- Secure the underlying credentials. This is the step most governance frameworks skip. Even with policies and CASB in place, employees who have direct access to raw API keys, database passwords, and service account credentials can paste them into any tool. Centralizing secrets management — so that credentials are stored, injected, and rotated programmatically rather than copied manually — removes the most direct path from shadow AI to credential compromise.
How Passwork secures the foundation against Shadow AI risks
You cannot physically prevent an employee from opening a browser tab and typing into a public LLM. What you can control is what they have access to paste.
The core principle: remove plaintext from the equation
If API keys, database credentials, production secrets, and service account passwords live in a centralized encrypted vault — accessed programmatically rather than copied manually — the credential exposure risk from shadow AI drops substantially. The developer who wants to debug a production issue with an AI assistant cannot paste the database connection string because they never had it in plaintext to begin with.
What Passwork provides
Passwork is available as both a self-hosted deployment and a cloud-hosted solution. Both share the same core architecture: AES-256 encryption under a zero-knowledge model, where credentials are encrypted client-side before leaving the device.
Four controls matter most in the shadow AI context:
- Role-based access control. Administrators scope vault access to specific teams and roles. A developer gets access to development environment secrets, not production. Access is granted by function, not by seniority or convenience.
- Audit logs. Every access event is recorded: who retrieved which credential, when, and from which system. If a credential surfaces somewhere it shouldn't, you have a trail.
- Service account management. Shadow AI risk isn't limited to humans pasting secrets into chat windows. AI agents and automated pipelines run under service accounts — and those accounts accumulate permissions over time with no one actively reviewing them. Passwork lets you store, rotate, and scope service account credentials the same way you manage human access: with explicit roles, expiry policies, and a full access history.
- API-first credential delivery. Passwork's REST API lets pipelines and applications retrieve secrets programmatically at runtime instead of reading them from environment files or config repositories. The credential never touches a developer's clipboard. It goes directly from the vault to the process that needs it — and the retrieval is logged.
Self-hosted vs. cloud
The self-hosted option keeps all data within the organization's own infrastructure — the right choice for teams with strict data residency requirements or regulated environments. The cloud option removes the operational overhead of running your own instance while preserving the same encryption guarantees and access controls. Neither option sends plaintext credentials to Passwork's servers.
How Passwork addresses Shadow AI risks
| Shadow AI risk | How it happens | How Passwork addresses it |
|---|---|---|
| Credential exposure in prompts | Developer pastes API key or database connection string into a public LLM to debug a production issue | Secrets are stored encrypted and delivered programmatically via REST API — developers never hold plaintext credentials to paste |
| Hardcoded secrets in source code | API keys and tokens embedded in code get shared with AI coding assistants or committed to repositories | API-first credential delivery keeps secrets out of config files and environment variables entirely |
| Overprivileged access | Employees have access to more secrets than their role requires — any of which can end up in an AI prompt | Role-based access control scopes vault access by team and function; a developer sees dev secrets, not production |
| Unmanaged service account credentials | AI agents and pipelines run under service accounts with accumulated permissions and no review cycle | Service account credentials are stored, scoped, and rotated in Passwork with explicit roles and full access history |
| No audit trail after exposure | A credential surfaces in an unexpected place — no way to determine who accessed it, when, or from where | Every retrieval is logged: credential, user, timestamp, source system — full forensic trail available immediately |
| Stale access after offboarding | Departing employee retains access to shared credentials, AI agent OAuth grants, and service account passwords | Access revoked once at vault level; security dashboard flags all credentials the employee could access as potentially compromised |
| Secrets sprawl across environments | Credentials stored in spreadsheets, Slack messages, .env files, and personal password managers — no central inventory | Single encrypted vault for all credentials across teams; AD/LDAP sync keeps access aligned with directory groups automatically |
Conclusion
The $670K breach cost premium for shadow AI is the cost of using AI without governance. The organizations paying that premium are not outliers. They are the 63% that had no AI governance policies and the 97% that lacked proper access controls when an incident occurred.
Governance starts at the credential layer. An employee who cannot access raw production secrets cannot accidentally expose them — regardless of which AI tool they open. That is the control point that most shadow AI frameworks miss, and the one that delivers the most immediate risk reduction.
Audit which credentials your teams can access in plaintext today. That list is your shadow AI exposure surface.
FAQ: Shadow AI in the enterprise
How do you detect Shadow AI?
Organizations can detect shadow AI by monitoring network logs for unusual outbound traffic to AI domains, deploying a Cloud Access Security Broker (CASB) to audit SaaS usage across managed devices, and reviewing browser extensions on corporate endpoints. Endpoint DLP tools can flag large text transfers to known AI services, though free-tier personal accounts remain a persistent blind spot.
What is an example of Shadow AI?
A common example is a developer pasting proprietary source code into a personal ChatGPT account to debug a production issue — exposing hardcoded API keys and internal architecture in the process. Another is a marketing team uploading confidential customer data to an unapproved AI summarization tool, or a finance analyst sharing Q3 projections with a free-tier AI assistant to prepare board materials.
Why is Shadow AI more dangerous than Shadow IT?
Shadow IT creates data residency problems — data sits somewhere IT doesn't control. Shadow AI processes data: it reasons over it, generates outputs from it, and in agentic deployments, acts on it autonomously. Exposure through shadow AI is often irreversible, especially when data flows through free-tier accounts where it may be used to train public models.
What credentials are most at risk from Shadow AI?
API keys, database connection strings, OAuth tokens, and service account passwords are the highest-risk credentials. These are the secrets developers and DevOps engineers are most likely to include in AI prompts when debugging or asking for configuration help. Hardcoded secrets in source code are particularly exposed, since code is the single largest category of sensitive data shared with AI tools (Harmonic Security, 2025).
Does banning AI tools prevent Shadow AI?
No. Harmonic Security's analysis of 22.4 million enterprise prompts found that employees at over 90% of organizations actively use AI tools, mostly through personal accounts that IT never approved. Blanket bans push usage to personal devices and accounts with even less visibility. Effective governance combines approved alternatives, clear acceptable-use policies, and technical controls at the access layer.
Alex Muntyan
Alex Muntyan
Alex Muntyan
Table of contents
- What is Shadow AI?
- Shadow IT vs. Shadow AI: Understanding the risk multiplier
- The financial impact: Why Shadow AI costs enterprises $670K per breach
- The hidden threat: Credential exposure and AI agents
- Real breaches tied to Shadow AI
- How to detect and prevent Shadow AI in the enterprise
- How Passwork secures the foundation against Shadow AI risks
- Conclusion
- FAQ: Shadow AI in the enterprise
Table of contents
- What is Shadow AI?
- Shadow IT vs. Shadow AI: Understanding the risk multiplier
- The financial impact: Why Shadow AI costs enterprises $670K per breach
- The hidden threat: Credential exposure and AI agents
- Real breaches tied to Shadow AI
- How to detect and prevent Shadow AI in the enterprise
- How Passwork secures the foundation against Shadow AI risks
- Conclusion
- FAQ: Shadow AI in the enterprise
Self-hosted password manager for business
Passwork provides an advantage of effective teamwork with corporate passwords in a totally safe environment. Double encryption and zero-knowledge architecture ensure your passwords never leave your infrastructure.
Learn more