Shadow AI is turning productivity tools into unmanaged data pipes

At a glance

What this is: Shadow AI is the use of unapproved or ungoverned AI tools, features, or agents at work, and the article shows that it is already creating hidden data exposure, access, and compliance risk.

Why it matters: It matters because IAM, NHI, and governance teams now have to control not just who can access systems, but which AI tools, agents, and embedded features can see, process, or act on sensitive data.

By the numbers:

• 59% of U.S. employees admitted to using unapproved AI tools at work and often share sensitive corporate data as part of that use.
• 78% of employees use AI tools that are not formally approved by their employer.
• 71% of UK workers have used unapproved consumer AI tools at work, with more than half doing so weekly.
• 60% of organizations can’t reliably detect shadow AI usage.

👉 Read Knostic's full analysis of shadow AI scenarios and enterprise controls

Context

Shadow AI is not just an adoption problem. It is a governance failure in which employees, developers, and business teams use AI tools before security, legal, and compliance functions have approved the data flows or the identity boundaries around them. That creates a blind spot for sensitive information, especially where browser access, SaaS copilots, extensions, and autonomous agents sit outside normal review.

The identity angle is direct: unapproved AI tools often operate with user credentials, stored tokens, or delegated access, which makes them behave like non-human identities without the lifecycle controls that IAM and PAM teams expect. In that sense, shadow AI is a policy enforcement problem first, and a machine identity problem second.

The pattern described in the article is typical, not exceptional. What makes it risky is how ordinary the behaviour looks to users while the governance impact accumulates behind the scenes.

Key questions

Q: How should security teams control shadow AI in the enterprise?

A: Start by classifying approved AI use cases by data sensitivity, then enforce access through identity-aware controls rather than user education alone. Pair policy with discovery of SaaS AI features, browser extensions, and autonomous agents, and make prompts, retrievals, and outputs visible to security operations so unapproved usage can be contained quickly.

Q: Why does shadow AI create a non-human identity risk?

A: Because many AI tools and agents operate with stored credentials, delegated permissions, or embedded service access, they behave like non-human identities even when users create them casually. If those identities are not inventoried, governed, and offboarded, the organisation loses visibility into who or what can access data and systems.

Q: What do organisations get wrong about approving AI tools?

A: They often approve the headline application while ignoring the embedded feature, extension, or data path that actually processes information. That creates a false sense of control, because the tool may still collect sensitive content outside normal oversight. Approval has to cover the specific processing path, not just the brand name.

Q: Who is accountable when an unapproved AI agent exposes sensitive data?

A: Accountability sits with the business owner that enabled the workflow, the control owner that failed to detect it, and the governance function that did not define acceptable data use. For regulated data, privacy, security, and compliance teams all need an auditable approval and review process.

Technical breakdown

Why shadow AI becomes a data governance blind spot

Shadow AI creates a control gap because the organisation does not own the approval path, the data flow, or the retention boundary. A public chatbot, SaaS feature, or browser extension may process prompts and files outside corporate monitoring, while still being used for legitimate work. That means the enterprise may never know which data was exposed, copied, or summarised. The problem is not simply unsanctioned use, but the loss of traceability across identity, data, and tool invocation. Practical implication: security teams need visibility at the interaction layer, not just at the network or endpoint layer.

Practical implication: instrument AI usage so prompts, retrievals, and data access are auditable before the data leaves approved controls.

Identity-aware access control for AI tools and agents

The article’s strongest governance point is that AI access should be treated as a persona and context problem, not a generic application permission problem. Persona-based access control groups users by job function, while attribute-based access control can add data sensitivity, location, and task context to decide what an AI tool may see or do. That matters when agents or copilots can act on behalf of users with stored credentials or delegated access. If the identity of the human is known but the identity of the AI interaction is not, least privilege breaks down. Practical implication: bind AI access decisions to user role, data class, and approved use case.

Practical implication: apply persona and attribute rules to AI features, extensions, and agents before granting access to sensitive repositories or workflows.

How embedded AI features inside SaaS change the attack surface

A hidden risk in the article is that AI does not need to arrive as a standalone tool. It can be embedded inside trusted SaaS products, activated by a user toggle, or exposed through an extension that the employee did not view as a security decision. Once enabled, those features can scan documents, summarise content, and route context to cloud-hosted inference engines. For IAM and security governance, that means the approval boundary shifts from application access to feature-level authorisation and data-use policy. Practical implication: inventory AI-enabled SaaS features and treat them as separate risk decisions, not as harmless product options.

Practical implication: review AI features in SaaS applications as distinct data-processing paths with their own access, logging, and approval requirements.

Threat narrative

Attacker objective: The objective is not always immediate theft. In shadow AI scenarios, the effect is to move sensitive enterprise data and actions into an unmanaged AI workflow that the organisation cannot fully observe or govern.

1. Entry begins when an employee, developer, or team adopts an unapproved chatbot, extension, SaaS AI feature, or autonomous agent to speed up work.
2. Credentialed access or delegated permissions allow the tool to see internal documents, repositories, mail, tickets, or records that were never meant for external AI processing.
3. Impact occurs when sensitive data is copied, summarised, leaked, or acted on outside enterprise governance, creating compliance exposure and loss of control over regulated information.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is becoming an identity governance problem, not just an AI policy problem. The article shows that unapproved tools and embedded features are already sitting inside ordinary workstreams, often with user credentials or delegated access attached. That means the real failure is not only tool adoption, but the absence of lifecycle control over who or what is allowed to act with those permissions. For IAM and PAM teams, AI usage must now be reviewed as an access-governance event, not a convenience choice.

Machine identity discipline needs to extend to AI assistants and autonomous agents. When an agent reads files, sends messages, or queries internal systems, it is functionally operating as a non-human identity even if the organisation never modelled it that way. The control gap is unmanaged delegation, where action happens without a verifiable identity lifecycle, audit trail, or offboarding path. That is exactly where NHI governance becomes material to AI governance.

Shadow AI creates knowledge-boundary leakage, which is a named concept security teams should start using. The issue is not only data loss, but the collapse of expected knowledge boundaries when prompts, summarisation, and retrieval cross from approved context into unapproved processing. That concept helps teams distinguish ordinary SaaS use from AI-driven oversharing risk. Practitioners should treat knowledge-boundary leakage as a governance failure that spans IAM, data security, and compliance.

Security programmes that rely on user disclosure will miss most of the problem. The article’s examples all show the same pattern: employees tend to use AI because it is easy, helpful, or embedded in their normal workflow. That means policy documents alone will not contain the risk. Organisations need control points in identity, data, and SaaS administration that can detect and constrain AI use where it actually occurs.

The market is moving toward AI governance that must be enforced through access control, not just policy language. As AI features become routine inside enterprise software, the distinction between application governance and AI governance will keep shrinking. Teams that continue to treat AI as a user-behaviour issue will underinvest in controls that map approval, data class, and delegated action. Practitioners should expect AI governance to converge with IAM, NHI, and data control design.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Explore Ultimate Guide to NHIs for lifecycle, visibility, rotation, and offboarding controls that help govern agent and secret sprawl.

What this signals

Knowledge-boundary leakage: as AI becomes embedded in everyday SaaS and browser workflows, the important control question shifts from whether people are using AI to whether the organisation can enforce what data those systems are allowed to see. That is where identity governance and data governance start to converge, particularly for copilots and agents that act with delegated access.

The operational signal for practitioners is that shadow AI will increasingly show up as an access problem in disguise. Teams that already manage service accounts, tokens, and delegated workflows should extend those disciplines to AI features and agents, using standards such as the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 where agent behaviour touches enterprise data.

The next programme decision is to treat AI approvals as a living control plane, not a one-time policy exercise. That means continuous discovery, explicit ownership, and revocation paths for tools and agents that outlive the original business need. Without that discipline, shadow AI becomes part of the normal operating environment rather than an exception.

For practitioners

• Define approved AI use cases by data class Create explicit rules for what data employees may share with chatbots, copilots, extensions, and agents. Separate public, internal, confidential, and regulated data so policy can be enforced consistently across tools and business units.
• Inventory embedded AI features in SaaS platforms Treat summarisation, search, drafting, and predictive features as separate AI controls, not harmless interface options. Record where each feature is enabled, what data it can scan, and which teams own approval.
• Bind AI access to persona and context Use persona-based and attribute-based controls so AI tools only receive the access needed for a specific role and task. Limit access to repositories, tickets, and records that match approved context and sensitivity.
• Monitor prompts and retrievals in real time Capture prompts, retrieved context, outputs, and AI actions so security teams can investigate oversharing and policy violations. Integrate that telemetry with SIEM workflows and identity logs for investigation.
• Create an offboarding path for AI agents and extensions Track who created each agent or extension, which credentials it can use, and how quickly it can be revoked when no longer needed. Unmanaged AI tools should have the same lifecycle discipline as other non-human identities.

Key takeaways

• Shadow AI is a governance failure that combines unapproved tools, hidden data flows, and identity misuse.
• The evidence is already broad, with employee surveys and incident examples showing that unmonitored AI use is common and often exposes sensitive data.
• The practical response is to control AI through identity, data classification, embedded feature inventory, and real-time monitoring rather than policy alone.

Key terms

• Shadow AI: Shadow AI is any AI tool, feature, model, or agent used without formal IT, security, legal, or compliance oversight. It creates governance risk because data processing, retention, and action-taking happen outside the organisation's approved control paths.
• Persona-Based Access Control: Persona-based access control groups users by job function and expected responsibilities rather than by broad application entitlement. In AI governance, it helps limit which copilots, agents, or embedded features can access sensitive data for a given role.
• Attribute-Based Access Control: Attribute-based access control uses policy conditions such as data sensitivity, time, location, or task context to decide access. For AI systems, it supports dynamic restrictions that can narrow what data a tool may process in a specific situation.
• Knowledge-boundary leakage: Knowledge-boundary leakage is the collapse of expected information boundaries when AI systems retrieve, summarise, or transmit content beyond the context a user intended. It is especially relevant when embedded AI features or agents can see more data than the requester should expose.

What's in the full article

Knostic's full article covers the operational detail this post intentionally leaves for the source:

• A side-by-side breakdown of the shadow AI scenarios and how each one surfaces in real enterprise workflows.
• Practical examples of identity-aware access controls for AI tools, agents, and embedded SaaS features.
• The article's remediation guidance for visibility, monitoring, and user enablement across common shadow AI patterns.
• The source's own examples of how unapproved AI usage affects compliance, data leakage, and operational risk.

👉 Knostic's full article covers the incident examples, governance steps, and prevention patterns in more operational 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 helps practitioners connect identity controls to the AI workflows and delegated access paths that now shape enterprise risk.