Shadow AI exposes sensitive code and data in public chatbots

At a glance

What this is: Shadow AI is the use of public chatbots and other unapproved AI tools to process sensitive company data, creating a data-leak risk that is harder to detect than classic shadow IT.

Why it matters: IAM teams need to govern both access to AI tools and the data that users can place into them, because identity context now determines whether sensitive information can leave the environment.

Context

Shadow AI is the use of public or unapproved generative AI tools to process business data, including code, customer records, and internal documents. The security problem is not only that employees bypass approval, but that the data itself can be exposed outside controlled systems.

For IAM and security teams, this shifts the control question from software inventory to identity-bound data governance. Traditional shadow IT controls focused on sanctioned applications and procurement, but AI use now creates a faster exfiltration path through browser plugins, personal accounts, and AI features embedded in approved tools.

Key questions

Q: What breaks when employees paste secrets into AI chat tools?

A: Secrets can leave the organisation through a normal work interaction rather than a known transfer channel. Once an API key, token, or connection string is entered into an AI tool, it may be logged, cached, indexed, or exposed through downstream integrations. That makes secret containment slower, harder to trace, and often impossible to fully reverse.

Q: Why is shadow AI harder to manage than ordinary shadow IT?

A: Shadow AI is harder because the tools can process sensitive content as part of normal use, which creates both data exposure and compliance risk. Traditional SaaS oversight often tracks application presence, but AI governance must also account for how data is entered, stored, and audited.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: Should organisations treat public chatbot use as an identity or data issue?

A: They should treat it as both, but the stronger control point is data governance tied to identity context. The question is not only who can open the tool, but which identities, on which devices, may submit which information. That approach aligns IAM, Zero Trust, and data-loss prevention around the same boundary.

Technical breakdown

Why public chatbots create a data-leak channel

Public large language models can retain, process, or reuse the information users submit, which means sensitive prompts may become part of a broader training or response environment. In practice, the risk is not just disclosure at upload time. It is also downstream resurfacing of code, customer data, or business logic in outputs that are outside the original organisation’s control. That makes the prompt itself a governed data transfer event, even when no file was formally uploaded.

Practical implication: Treat prompts to public LLMs as data movement events and classify what content is forbidden before users can submit it.

Why shadow AI is harder to find than shadow IT

Shadow AI often hides inside browser extensions, embedded assistant features, and personal accounts, rather than obvious standalone software installs. That means traditional discovery methods based on endpoint inventory or procurement records miss much of the activity. The operational challenge is that a sanctioned application may suddenly gain an AI feature that sends content to an external model, turning a previously approved workflow into an unmanaged disclosure path without a new install event.

Practical implication: Extend discovery beyond installed software to browser activity, identity context, and outbound AI endpoint usage.

How identity context changes AI governance

AI usage becomes a governance problem when access to an AI tool is not enough to explain the risk. User identity, device trust, and the sensitivity of the submitted data all determine whether a query is acceptable. This is where conventional IAM and Zero Trust thinking intersect with data governance: approval is not just about who can open the tool, but whether that identity should be allowed to send specific information to a public model at all.

Practical implication: Use identity-aware policy to couple AI access with device posture, user role, and data sensitivity controls.

Threat narrative

Attacker objective: The objective is to obtain proprietary or regulated information through unmanaged AI use and then exploit the organisation’s loss of control over that data.

1. Entry occurs when an employee uses a public chatbot, browser extension, or personal AI account to process company information outside approved channels.
2. Sensitive code, customer data, or internal content is then submitted into a model that the organisation does not govern.
3. The material may be retained, reused, or surfaced in later outputs, expanding the exposure beyond the original user session.
4. The impact is leakage of intellectual property, regulated data exposure, and compliance failure without the audit trail of a normal transfer event.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is a data-governance problem before it is a tool-governance problem. The article shows that the central risk is not merely the presence of an unapproved application, but the movement of sensitive content into systems the organisation does not control. That means identity, device trust, and data classification now have to work together, because access approval alone does not prevent disclosure. Practitioners should treat AI prompting as a governed data path, not an informal productivity habit.

Public LLM usage collapses the separation between application approval and data control. Traditional shadow IT assumptions were built around software installation, procurement, and network visibility. Shadow AI bypasses those assumptions because the dangerous act is the submission of code or records, often from a sanctioned browser or a personal account, and the organisation may never see a file transfer log. The implication is that governance must focus on what is allowed to leave the environment, not only on which tools are installed.

Identity-aware AI policy is becoming a baseline control, not an advanced option. When approved applications gain AI features, the risk boundary shifts inside existing workflows and users may not realise they have crossed it. That creates a governance gap across IAM, DLP, and SaaS control surfaces, especially where public models are reachable through browser plugins or federated personal accounts. The practitioner takeaway is to define who may use AI, from which device, and with which data classes before usage becomes routine.

Shadow AI exposes a visibility gap that conventional recertification cannot close. A user can be perfectly entitled to access a business application and still misuse embedded AI functionality to disclose sensitive information. That is a control failure at the point of data submission, not at the point of login. NHI Mgmt Group's position is that programme owners should stop treating AI as a separate feature set and start governing it as a privileged data egress path inside everyday identity flows.

Data exfiltration through AI is now a standard shadow-identity pattern. The rise of browser plugins, embedded assistants, and personal accounts means the path out of the organisation is often the identity context itself, not malware or a breached perimeter. This makes Shadow AI a useful bridge concept across human IAM, SaaS governance, and NHI-style control thinking. Practitioners should expect more incidents where the abuse is not the model, but the unmanaged identity channel feeding it.

What this signals

Shadow AI creates an identity-governance gap inside ordinary user workflows. The control problem is no longer limited to SaaS approval and software inventory. Security teams now have to decide which identities can reach public models, what data those identities may submit, and how to detect AI features that appear inside tools already in use.

Browser-based AI is turning data egress into an everyday access decision. When a sanctioned application adds a generative feature, the risk can change without a new procurement event or endpoint install. That means programme owners need continuous review of AI-enabled workflows, not one-time approval decisions.

Shadow AI and human IAM now intersect at the same policy boundary. If an authenticated user can paste regulated content into an external model, the organisation has technically permitted a data transfer even when it never intended to. The practical response is to align identity policy, SaaS discovery, and data classification so that tool access and content sharing are governed together.

For practitioners

• Define prohibited prompt content Publish rules that block proprietary code, customer records, and regulated data from being entered into public AI models, and tie those rules to user role and data classification.
• Extend discovery beyond installs Monitor browser extensions, embedded AI features, personal accounts, and outbound requests to unapproved AI endpoints so hidden usage is visible to security teams.
• Gate AI access by identity context Require device trust, authenticated user identity, and policy checks before approving access to sanctioned AI resources, especially where public tools are reachable through single sign-on.
• Review approved apps for new AI exposure Reassess SaaS applications that added generative AI features after initial approval, because an approved tool may now route content to a third-party model.
• Separate public and enterprise AI use Create a clear path for approved enterprise AI services and treat public models as untrusted destinations for sensitive information.

Key takeaways

• Shadow AI shifts the main concern from unapproved tools to sensitive information leaving the environment through public models and embedded AI features.
• The article shows why browser plugins, personal accounts, and feature creep inside approved apps make discovery and control much harder than classic shadow IT.
• Identity-aware policy, discovery beyond installed software, and data-classification rules are the control set that matters most for this risk.

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.
• Data Egress: Data egress is the movement of information out of a controlled environment to another system, service, or destination. In practice, it is where many identity and data risks converge, because the identity allowed to export the data can be different from the identity that originally stored it.
• Identity context: The entitlement, ownership, and purpose information that explains why an action occurred and whether it was expected. For security operations, identity context turns raw alerts into decisions by showing which human or non-human identity acted and what it was allowed to do.
• SaaS Discovery: SaaS discovery is the process of identifying all sanctioned and unsanctioned software-as-a-service applications in use across the organisation. It matters because cloud assurance increasingly depends on seeing where apps share data, what permissions they hold, and which identities can reach them.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.