Insider Risk from AI Tools: Leakage, Shadow AI, Monitoring

Most AI-related insider incidents are not caused by malicious staff: they come from well-meaning employees pasting customer data, source code or deal documents into AI tools, connecting unsanctioned AI apps to corporate accounts, or giving AI agents their own permissions to act on their behalf. These actions sit squarely inside the classic definition of insider risk, because they use authorised access, yet traditional insider threat programmes were built around departing employees and deliberate theft. This guide looks at AI tools through an insider risk lens: the behaviours that create exposure, how AI agents change what a single user's access can do, which controls work, and how far you can lawfully monitor staff use of AI under employment and data protection law. It is written for insider risk, security, privacy and HR leaders. Discovery of shadow AI, DLP engineering and insider threat programme design are covered in their own NHI Mgmt Group guides, linked where relevant.

Key takeaways

AI tools are an insider risk channel, mostly unintentional. CISA's insider threat model splits unintentional threats into negligence and accidents; pasting sensitive data into a public chatbot is usually one of the two, and the response should match.
Anything typed into a public AI tool leaves your control. The NCSC notes that queries are visible to the provider and stored, and advises against including sensitive information in queries to public LLMs.
Agents turn one user's access into automated action. An AI agent running with a user's permissions can read, send and change data at machine speed, so excessive permissions become an insider problem even when the user means no harm.
Offer a sanctioned route before you block. Bans without an approved alternative push use onto personal devices, where you see nothing; an approved enterprise tool with data protection terms plus targeted DLP reduces risk more.
Monitoring must be lawful and proportionate. Capturing staff prompts is monitoring of workers: the UK ICO expects a lawful basis, transparency, a DPIA for high-risk monitoring and the least intrusive method that works.

Why AI tools change insider risk

CISA defines an insider as anyone who has or had authorised access to or knowledge of an organisation's resources, and insider threat as the risk that they use that access, intentionally or unintentionally, to do harm. AI tools add four new paths for that harm.

Behaviour	Insider type (CISA model)	What leaves or changes	Example
Pasting or uploading data into a public AI tool	Unintentional: accidental or negligent	Customer data, source code, credentials, financial and legal documents sent to a third-party provider	Samsung banned generative AI tools on company devices in May 2023 after staff entered sensitive data, reportedly including source code and semiconductor equipment measurement data, into ChatGPT
Using unsanctioned AI apps and browser extensions (shadow AI)	Usually negligent	Data and OAuth access granted to an unvetted vendor	An employee-connected AI productivity app whose stolen token later exposed customer data at Vercel
Delegating work to AI agents with the user's permissions	Unintentional, but can be exploited by outsiders	Emails sent, files shared, records changed or deleted without per-action human review	Prompt injection that makes an assistant leak data it can reach
Deliberate exfiltration through AI tools	Intentional (malicious insider)	Data summarised or reformatted to evade content rules, then sent to a personal AI account	A leaver uploading a customer list to a personal chatbot account to "summarise" it

In MITRE ATT&CK terms, sending data to an external AI service resembles T1567 Exfiltration Over Web Service, and AI assistants that search internal content act like T1213 Data from Information Repositories at scale. MITRE ATLAS lists AML.T0057 LLM Data Leakage, and the OWASP Top 10 for LLM Applications 2025 covers the same ground as LLM02:2025 Sensitive Information Disclosure. The live Top 10 Shadow AI Risks lists the broader risk set.

Data leakage through prompts and uploads

The NCSC's analysis of public LLMs sets out the core issue: the query is visible to the organisation providing the model, it is stored and will likely be used to develop the service, and stored queries can be hacked, leaked or made public. Combining queries made under the same login can also reveal more than any single question. The data types that matter most:

Personal data: customer and employee records pasted for summarising or drafting. Under UK GDPR and EU GDPR this is a disclosure to a third party, which may need a processor contract and can be a reportable breach if it goes to an unvetted service.
Source code and secrets: code pasted for debugging often contains API keys, connection strings and tokens. Treat any secret pasted into a public AI tool as exposed and rotate it. See the AI Coding Agents Security Guide.
Confidential business information: board papers, deal documents, pricing and legal advice. Inside information and legal privilege can be put at risk by uploading them to a third party.
Regulated data: payment card data, health data and export-controlled technical data have their own rules on where they may be processed.

What makes the difference is the contract and configuration behind the tool, not the brand. Classify AI tools by data terms before deciding policy.

Tool category	Typical data terms	Visibility for the organisation	Suggested policy
Consumer AI tool, personal account	Consumer terms; prompts may be retained and used to improve the service unless the user opts out	None beyond network and endpoint telemetry	Block or warn for sensitive data; allow public information only
Consumer tool, organisation account on a free or low tier	Varies by provider and tier; check training and retention settings	Limited admin controls	Treat as unsanctioned until reviewed
Enterprise AI service under contract	Data processing agreement, no training on customer data by default with many providers, defined retention, SSO	Admin console, audit logs, often export of prompts	Approved route for internal and confidential data within classification rules
AI built into an existing SaaS platform (copilots)	Covered by the platform's terms; respects existing permissions	Platform audit logs	Approved, but fix oversharing first, because the assistant surfaces everything the user can already reach
Self-hosted or private model	Data stays in your environment	Full logging under your control	Approved for higher classifications if hardened and access controlled

For the copilot case, see the Enterprise AI Copilot Security Guide; the EchoLeak prompt injection against Microsoft 365 Copilot showed how an assistant with broad access to a user's data can be made to leak it.

Shadow AI as an insider behaviour

Shadow AI is any AI tool, extension, agent or integration in use without approval. From an insider risk perspective the question is not just "what is out there" but "why are people using it, and what access did they grant". Discovery methods (SaaS logs, OAuth grants, browser extension inventories, network traffic) are covered in the Shadow AI Discovery Guide. The insider risk additions are:

OAuth grants are standing access: when an employee connects an AI app to their mailbox, drive or code repository, the app holds a token with that employee's reach, often long after the employee stopped using it. The Vercel and Context.ai breach showed how a forgotten AI app's stolen token became a route to customer data.
Demand signals: heavy use of one unsanctioned tool usually means a business need the approved estate does not meet. Treat it as procurement input, not only as a violation.
Personal devices: strict blocking on managed devices moves use to phones and home laptops. Pair controls with an approved alternative and clear rules on copying work data to personal devices.
Policy clarity: staff cannot follow rules they have not been given. Publish an AI acceptable use policy that lists approved tools and data classes; see the AI Acceptable Use Policy Template and the Shadow AI Policy Template.

AI agents acting with user permissions

Agents change the scale of insider risk. When an agent runs "as the user", every permission the user holds becomes something the agent can exercise, often without a human approving each step. OWASP's LLM06:2025 Excessive Agency describes the three root causes: excessive functionality (tools the agent does not need), excessive permissions (access broader than the task) and excessive autonomy (high-impact actions without human approval).

Scope delegations: give agents task-scoped permissions, not the user's full access. OWASP recommends minimising extensions and their permissions, executing extensions in the user's context with only the access needed, and requiring user approval for high-impact actions.
Separate identity: where the platform allows, give agents their own identity or a distinct delegated token so their actions are distinguishable from the user's in logs. See the Agentic AI Identity Guide.
Human approval for irreversible actions: external email, file sharing outside the organisation, payments, deletions and permission changes.
Attribution in investigations: an insider risk alert on a user may actually be their agent misbehaving or being manipulated by injected content. Investigation playbooks need a step to check agent activity before treating the user as the actor.
Revocation at offboarding: agents, scheduled automations and AI app tokens the user created must be revoked when they leave. See the Joiner-Mover-Leaver Guide.

Controls: from policy to DLP for AI

Layer controls so that the safe path is the easy path and the risky path is visible.

Control	What it does	Risk it addresses	Limits
Approved enterprise AI tools with SSO	Gives staff a sanctioned route with contractual data protection and audit logs	Pasting into consumer tools	Needs budget and procurement speed
AI acceptable use policy and training	Sets which data may go into which tool; builds AI literacy	Negligent and accidental use	Does not stop determined misuse
Endpoint and browser DLP for AI sites	Warns or blocks paste and upload of classified or pattern-matched data to AI sites	Leakage of known sensitive data types	Unmanaged devices and reworded data evade it
Network or SSE inspection of AI traffic	Detects and logs prompts and uploads at the network layer, category-based allow and block	Shadow AI use, uploads	TLS inspection and privacy constraints; certificate pinning in some apps
OAuth app governance	Restricts which AI apps users can consent to; reviews and revokes grants	Standing access by AI apps	Needs admin consent workflow that is fast enough to use
Agent permission scoping and approval gates	Limits what agents can do with user access	Excessive agency	Platform support varies
Insider risk analytics with AI indicators	Correlates risky AI use with other signals such as resignation, mass downloads	Deliberate exfiltration	Highest privacy impact; needs DPIA and governance

As one example of how platforms implement this, Microsoft documents Endpoint DLP policies in Purview that can warn or block users pasting sensitive information into third-party generative AI sites such as ChatGPT and Google Gemini, network data security through SASE or SSE integrations, and an Insider Risk Management policy template called "Risky AI usage". Comparable controls exist in other browser, SSE and DLP products. The engineering detail is covered in the Generative AI Data Loss Prevention Guide; the wider programme in the Data Loss Prevention (DLP) Guide.

Choosing an approach: warn-and-educate suits organisations where most data is internal rather than regulated and the goal is behaviour change; block suits regulated data classes (payment card numbers, health records, secrets) where any disclosure is a breach. Small organisations get most value from an approved tool, a one-page policy and identity provider controls on OAuth consent. Large organisations add DLP, SSE and analytics, and need the governance that comes with them.

Monitoring within employment and privacy law

Recording what employees type into AI tools is monitoring of workers. The rules differ by country, so involve legal, privacy and HR (and, where they exist, works councils or trade unions) before switching it on. The UK ICO's guidance on monitoring workers gives a clear baseline; the ICO notes the guidance is under review following the Data (Use and Access) Act, so check the current version.

Lawful basis: identify one before monitoring. The ICO says consent is usually unsuitable because of the power imbalance; legitimate interests needs a documented test of purpose, necessity and balance against workers' rights.
DPIA: required before high-risk monitoring. The ICO cites keystroke monitoring as an example, and capturing full prompt text is comparable in intrusiveness. If high risk cannot be reduced, the ICO must be consulted before monitoring starts.
Proportionality: use the least intrusive method that achieves the purpose; the ICO says monitoring "just in case" is not acceptable. Metadata and policy-match events are less intrusive than storing every prompt.
Transparency: tell workers clearly what is monitored, why and how the data is used. Unexpected monitoring is likely to be unfair.
Covert monitoring: only in very exceptional circumstances such as suspected criminal activity or gross misconduct, with senior authorisation, a DPIA and a time limit.
Special category data: prompts can reveal health, beliefs or union membership; a separate processing condition is needed if monitoring captures them.
Subject access: workers can request their monitoring data, so design retrieval and retention with that in mind.
Other jurisdictions: in Germany, works councils have co-determination rights over technical systems capable of monitoring employee behaviour or performance; in the EU the AI Act's Article 4 AI literacy obligation for deployers has applied since 2 February 2025, which supports training as a control. Check local law in every country where you monitor.

The Employee Monitoring and Privacy Guide and the AI Usage Monitoring Guide go deeper on monitoring design.

Implementation roadmap

Baseline (month 1): agree ownership between insider risk, security, privacy and HR. Inventory approved and observed AI tools and OAuth grants. Classify tools by data terms.
Provide the safe route (months 1 to 2): stand up at least one approved AI tool under contract with SSO, publish the acceptable use policy and add AI scenarios to awareness training.
Govern monitoring (month 2): complete the DPIA and legitimate interests assessment, update the worker privacy notice and consult works councils where required.
Audit mode (months 2 to 3): deploy DLP and SSE rules for AI sites in audit only. Measure volume, false positives and top data types without blocking.
Warn, then block (months 3 to 4): switch to warn with a justification prompt for most data; block regulated data classes and secrets. Pilot with one business unit first.
Agents (months 3 to 6): restrict user consent to AI apps, introduce scoped delegations and approval gates for agents, and add agent checks to investigation playbooks.
Rollback: keep every block rule switchable to warn or audit per group, so a rule that disrupts a critical process can be relaxed within minutes while it is tuned.

Detection and measurement

What to log, within the limits the DPIA sets: AI site access by category, DLP policy matches on paste and upload, new OAuth consents to AI apps, agent actions on sensitive data, and spikes in AI use by users already flagged for other insider indicators. Metrics:

Share of AI traffic going to approved tools vs unsanctioned tools.
DLP matches on AI sites per 1,000 users, and the share overridden with a justification.
Number of active OAuth grants to unapproved AI apps, and median days to revoke after discovery.
Percentage of staff completing AI-specific awareness training.
Percentage of deployed agents with scoped permissions and approval gates for high-impact actions.
Secrets detected in AI prompts and time to rotation.

Framework mapping

Area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	Other
AI acceptable use and rules of behaviour	GV.PO-01	PL-4 Rules of Behavior; PS-6 Access Agreements	A.5.10 Acceptable use of information	NIST AI 600-1 GV-1.4-002
Approved AI tool inventory	ID.AM-02	CM-10 Software Usage Restrictions; AC-20 Use of External Systems	A.5.23 Information security for use of cloud services	NIST AI 600-1 GV-6.1-007
Awareness and AI literacy	PR.AT-01	AT-2 and AT-2(2) Insider Threat	A.6.3 Awareness, education and training	EU AI Act Art. 4
DLP for AI	PR.DS-02	AC-4 Information Flow Enforcement; SC-7(10) Prevent Exfiltration	A.8.12 Data leakage prevention	CIS Controls v8.1 Safeguard 3.13
Agent permissions	PR.AA-05	AC-6 Least Privilege	A.8.2 Privileged access rights	OWASP LLM06:2025
Monitoring and insider programme	DE.CM-03; GV.RR-04	PM-12 Insider Threat Program; AU-6; PT-5 Privacy Notice	A.8.16 Monitoring activities	ATT&CK T1567

Common failure patterns

Blanket bans with no alternative: staff move to personal phones and accounts, visibility drops to zero and the data still leaves.
Prompt capture without a DPIA: security switches on full prompt logging, a works council or regulator objects, and the whole programme is paused.
Treating every match as misconduct: disciplining accidental pastes kills reporting; most cases need coaching and a better tool, with HR action reserved for deliberate or repeated breaches.
Forgotten AI app tokens: trials end but OAuth grants stay, as in the Vercel and Context.ai case.
Agents with the user's full access: a convenience agent gets mailbox, drive and admin rights, and one injected instruction turns it into an exfiltration tool.
Copilot rollout before fixing oversharing: the assistant surfaces sensitive files that were technically accessible to everyone but never found.

Practitioner checklist

Assign joint ownership of AI insider risk across insider risk, security, privacy and HR.
Classify AI tools by data terms and publish an approved list with the data classes allowed in each.
Provide at least one approved enterprise AI tool with SSO before tightening blocks.
Complete a DPIA and update the worker privacy notice before monitoring AI use; avoid storing full prompts unless justified.
Deploy DLP for AI sites in audit, then warn, then block for regulated data and secrets.
Restrict user consent to AI apps and review existing OAuth grants quarterly.
Scope agent permissions to the task and require human approval for irreversible actions.
Add AI scenarios to insider threat awareness training and to tabletop exercises.
Revoke agents, automations and AI app tokens at offboarding.
Rotate any secret found in an AI prompt immediately.

Insider Risk from AI Tools Guide: Data Leakage, Shadow AI and Monitoring Limits