Shadow AI is exposing enterprise data and credentials at scale

At a glance

What this is: This analysis shows that Shadow AI is widespread in enterprise environments and that conventional security tooling is missing much of the associated activity, especially in browser-based and developer workflows.

Why it matters: It matters because unmanaged AI use creates new identity, data, and credential exposure paths that sit outside normal IAM, DLP, and audit processes, leaving practitioners to govern behaviour they cannot reliably see.

By the numbers:

• 78% of AI users bring their own tools to the workplace.
• Nearly 60% of users rely on unmanaged AI apps.
• XM Cyber research found that more than 80% of the researched organisations showed signs of Shadow AI activity.

👉 Read XM Cyber's analysis of Shadow AI exposure, visibility gaps, and credential leakage

Context

Shadow AI is the use of AI tools inside an organisation without approval or oversight from IT or security teams. The security problem is not just unsanctioned software, but unsanctioned data handling, credential exposure, and invisible workflows that bypass normal governance. For identity security teams, the important question is how unmanaged AI changes access, secrets, and audit boundaries across human, NHI, and workload activity.

The article positions Shadow AI as the AI-era analogue of Shadow IT, but with faster adoption and weaker observability. That comparison is useful, but incomplete: browser-based AI apps, MCP servers, and AI-assisted development workflows create direct identity and secrets-management concerns that traditional security controls were not designed to track. XM Cyber’s starting position is consistent with what many enterprise teams are now seeing in practice, but at a much higher speed and scale.

Key questions

Q: What breaks when employees use shadow AI for work tasks?

A: Shadow AI breaks identity visibility and lifecycle control. Employees can create or use AI accounts, connect them to work data, and move sensitive information outside approved governance. That leaves security teams unable to reliably inventory the identity, review its access, or revoke delegated permissions when the business need ends.

Q: Why do shadow AI tools create more risk than sanctioned SaaS apps?

A: Shadow AI bypasses procurement, security review, and entitlement design, so it often enters with broad access and no clear accountability. Even when the tool is well intended, the absence of an owner and review cadence means the organisation cannot reliably enforce data handling, access control, or revocation.

Q: How do security teams know if shadow AI is actually under control?

A: Security teams know shadow AI is under control when they can inventory every agent, model workflow, and tool connection, then map each one to an owner and access scope. If they cannot explain who owns it, what it can access, and when it was last reviewed, it is not controlled.

Q: Who is accountable when shadow AI uses corporate credentials to process sensitive data?

A: Accountability sits with the identity owners, the platform owners, and the governance function that approved the underlying access. If a service account or OAuth app can reach regulated data and an AI feature uses that path, the organisation is responsible for the resulting exposure and audit trail.

Technical breakdown

Why browser-based Shadow AI evades traditional monitoring

Browser-based AI services often run over encrypted web traffic that looks ordinary to network tools. That means DLP, CASB, and secure web gateways may see little or nothing useful unless they have endpoint context or browser-level telemetry. The problem is not just encryption, but the fact that unmanaged devices and personal accounts can generate legitimate-looking sessions outside corporate control. In practice, shadow use becomes a governance problem before it becomes a malware problem.

Practical implication: extend monitoring to endpoint and browser telemetry rather than relying on network inspection alone.

MCP servers and credential leakage in developer workflows

Model Context Protocol servers connect AI systems to tools and data sources, which makes them powerful but also sensitive. If API keys, tokens, or other secrets are stored in configuration files and then synced to shared repositories or exposed in development environments, attackers can reuse those credentials for exfiltration or lateral movement. This is an identity problem as much as a development problem, because the exposed secret often becomes the durable identity of the workload or agent. Weak secret hygiene in AI-enabled pipelines creates standing access where teams assume temporary access.

Practical implication: treat MCP configurations and AI-assisted development paths as secret-bearing assets that require rotation, scanning, and access restriction.

Why compliance controls do not automatically contain shadow AI

Compliance frameworks can set policy, but they do not stop users from pasting data into unmanaged tools or from bypassing restrictions when the business value feels immediate. The article’s point is that policy enforcement without practical visibility becomes paper compliance. This is especially relevant where personal data, customer records, or regulated information enters external AI services, because the governance failure is often an unlogged decision by an employee rather than a formal system change.

Practical implication: align policy, monitoring, and user guidance so that acceptable-use rules are backed by detectable controls.

Threat narrative

Attacker objective: The attacker aims to harvest credentials or sensitive data from unmanaged AI workflows and use that access to move laterally or exfiltrate information.

1. Entry occurs when users adopt browser-based AI services or AI-enabled applications without IT approval, often through personal accounts or unmanaged devices.
2. Credential access follows when developer workflows store API keys and tokens in MCP configuration files that can be exposed in repositories or synced locations.
3. Escalation and impact happen when those exposed secrets or pasted data are reused for exfiltration, lateral movement, or unauthorised disclosure of sensitive information.

NHI Mgmt Group analysis

Shadow AI is an identity-governance problem before it is an AI governance problem. The core failure is not simply that employees use unsanctioned tools, but that those tools sit outside access review, lifecycle control, and auditability. Once data, prompts, or secrets move through unmanaged accounts and browser sessions, governance teams lose the ability to answer who used what, with which identity, and under which policy. That makes Shadow AI a control-boundary issue across human identity, NHI exposure, and workload credentials, not just an acceptable-use issue.

Shadow AI creates a new form of visibility debt. Traditional controls were designed around known applications and known identities, but AI use often appears in encrypted sessions, shared endpoints, and informal workflows. The named concept here is shadow AI visibility debt, meaning the gap between how fast AI is adopted and how slowly security teams can discover it. That gap matters because control design, not awareness campaigns, determines whether the organisation can actually contain the risk.

Secrets embedded in AI workflows turn convenience into persistence. When API keys, tokens, and MCP configuration files are treated as incidental development artefacts, they become durable credentials with too much reach. This is the same governance mistake identity teams have seen in other NHI patterns: the secret becomes the identity, and the identity outlives the task it was meant to support. Practitioners should treat any AI workflow that stores credentials as a privileged workload requiring explicit lifecycle ownership.

Compliance language alone will not close the Shadow AI gap. The article shows regulated sectors still allowing unmanaged AI use, which is a reminder that policy does not equal control. Frameworks such as the NIST AI Risk Management Framework and OWASP NHI matter here because they force teams to connect governance intent to measurable technical enforcement. The practical conclusion is simple: if AI use cannot be discovered, classified, and bounded, it is outside governance regardless of policy text.

Exposure management is becoming the right operating model for shadow AI. The article points toward continuous discovery rather than periodic audits, and that is the right direction for fast-moving AI adoption. The challenge is to connect discovery to access control, secrets hygiene, and data handling rules so the response is operational, not just observational. For security leaders, the takeaway is to manage shadow AI as part of enterprise exposure, not as a standalone AI programme.

What this signals

Shadow AI will increasingly behave like an identity inventory problem disguised as an application problem. Security teams that cannot see which users, devices, and workflows are interacting with external AI services will struggle to enforce policy at scale, especially where secrets and regulated data are involved. The practical shift is toward continuous discovery, access context, and data-aware controls, not annual policy review.

Visibility debt: the organisation’s lag in discovering unmanaged AI use will become a measurable control gap. That gap will matter most where browser-based tools, MCP-connected workflows, and developer environments intersect with privileged data. Teams should expect exposure management, DLP, and identity governance to converge more tightly around AI usage.

Where AI tools are already in routine use, the next governance question is not whether to allow them but how to bound them. That points directly to identity-aware controls, secret scanning, and lifecycle ownership for any AI workflow that can store or transmit credentials. For practitioners, the risk becomes operational the moment it escapes discovery.

For practitioners

• Implement continuous discovery for shadow AI usage Instrument endpoints, browsers, and proxy logs to identify unmanaged AI services, personal accounts, and AI-enabled applications in use across the organisation. Prioritise flows that carry sensitive data or originate from high-risk functions such as development, HR, and finance.
• Scan MCP configurations for embedded secrets Treat MCP server configuration files as secret-bearing artefacts and add them to routine scanning, rotation, and repository protection workflows. Any exposed API key or token in these files should be revoked and replaced before the AI workflow is allowed back into production use.
• Bind AI use policy to enforceable controls Map acceptable-use rules to concrete controls such as identity-aware access policies, DLP enforcement, and device trust requirements. If employees can bypass the rule without generating an alert, the policy is not operationally effective.
• Classify AI tools by data sensitivity and identity impact Separate low-risk experimentation from workflows that handle customer data, source code, regulated records, or credentials. Require explicit ownership for any AI system that can store prompts, connect to internal systems, or access enterprise secrets.

Key takeaways

• Shadow AI is widespread, and the governance gap is primarily one of visibility and control rather than awareness.
• Unmanaged AI tools create identity and secrets exposure paths that conventional monitoring often misses.
• Security teams should treat AI usage as an enterprise exposure problem, with discovery, classification, and enforcement tied together.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Unmanaged AI agent: An unmanaged AI agent is a deployed system that operates without being tracked in identity governance, secrets management, or privileged access controls. That means security teams cannot reliably see its owner, permissions, dependencies, or lifecycle state, making revocation and accountability difficult when risk changes.
• Visibility Debt: Visibility debt is the accumulated gap between what an organisation thinks it can see and what it can actually govern. In identity and data security, it grows when cloud resources, non-human identities, and data locations outpace discovery, making remediation slower and less accurate.

What's in the full article

XM Cyber's full blog covers the operational detail this post intentionally leaves for the source:

• The article’s telemetry methods for identifying Shadow AI across browsers, endpoints, and managed versus unmanaged devices.
• The way MCP server configurations can expose API keys, tokens, and other credentials in development workflows.
• The vendor’s proposed expansion of continuous exposure management into AI services such as managed cloud AI platforms and MCP-connected devices.
• The compliance and measurement signals XM Cyber says practitioners should track as AI adoption increases.

👉 XM Cyber's full post covers the telemetry findings, AI workflow risks, and exposure-management approach in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to real operational risk across modern enterprise programmes.