Employee AI Security Risks: A Practical Threat Model for Sensitive Data

Employee AI risk depends on more than the chatbot an employee opens. It comes from the combination of identity, account, device, application, data, and action. The same request may be routine in an approved enterprise workspace on a managed laptop and high risk in a personal account, desktop client, IDE extension, or agent connected to company systems.

Harmonic Security analyzed 22,458,240 enterprise GenAI prompts and file uploads during 2025 and detected 579,113 instances of sensitive-data exposure. Code and proprietary source code, business and legal content, and strategic financial data accounted for 85.3% of those instances. These exposures often begin with ordinary work: a developer asks a coding assistant to debug a function, a lawyer summarizes a contract, or a finance team models a forecast.

Security teams need a threat model that follows the work across accounts, devices, and interfaces. This article maps the main exposure paths and the controls needed to keep sensitive data inside policy without blocking useful AI work.

What is an employee AI threat model?

An employee AI threat model is a framework for assessing risk across the user, account, device, application, data, and action involved in an AI interaction. The application name alone cannot show whether an activity is acceptable. ChatGPT in an approved enterprise workspace may have different data controls from ChatGPT in a personal account, while the same employee may also reach AI through a desktop client, IDE extension, browser plugin, or connected agent.

The purpose of the model is practical: give security teams enough context to distinguish routine work from activity that needs a warning, a block, or further review.

What are the six parts of employee AI risk?

• Identity: Who is using the tool, what role do they have, and which systems or data can they access? A developer with production access and a contractor working with public material create different levels of exposure.
• Account: Is the employee using an approved enterprise workspace, a free account, or a personal account? Retention, training, administrative controls, and audit options can change according to the account used.
• Device and interface: Is the activity happening on a managed laptop, an unmanaged device, a browser, a desktop client, an IDE extension, or an agent interface? Each route creates different visibility and enforcement gaps.
• Application: Which service receives the data? Security teams need to understand the provider's retention rules, training settings, permissions, integrations, data residency, and available administrative controls.
• Data: What information is involved? Source code, credentials, legal documents, financial forecasts, customer records, and health information require different handling from public or low-sensitivity material.
• Action: Is the employee typing text, uploading a file, connecting a repository, sharing credentials, or allowing an agent to act in another system? The potential impact increases when an AI tool can take action instead of simply returning an answer.

Risk rises when these factors compound

A single signal rarely provides enough information to make a good security decision. Public material summarized in an approved enterprise workspace on a managed device may be routine. Proprietary source code uploaded through a personal account in an IDE extension is a high-risk event. A privileged user giving an agent access to credentials or a production system demands tighter controls because both the data exposure and the possible action carry consequences.

This is why a static list of approved applications is incomplete. An approved tool can still be used through the wrong account, receive restricted data, or gain access to a connected system that falls outside the original review.

Where does employee AI data exposure happen?

Employee AI data exposure usually begins in an ordinary workflow. Someone pastes text into a chatbot, uploads a document for analysis, connects an assistant to a codebase, or installs a plugin that promises to save time. The risk changes depending on where that interaction occurs and which controls apply.

Personal and free accounts: Enterprise AI plans often include stronger administrative and data-handling controls. OpenAI, for example, states that it does not use business workspace inputs and outputs to train its models by default. Those protections do not tell a security team whether an employee has switched to a personal account. Harmonic research found that almost 64% of observed ChatGPT users were using the free version, which makes account context central to policy enforcement.

Unreviewed applications and integrations: Smaller AI services, aggregators, plugins, and extensions may retain more data or provide fewer enterprise controls. In 2025, a threat actor advertised data allegedly taken from OmniGPT, including more than 34 million lines of chat records. The incident was reported as an alleged breach, but it illustrates a clear diligence problem: employees can route company information through an intermediary that the security team has never assessed.

Data residency and legal jurisdiction: Security teams also need to know where a hosted service processes and stores information. DeepSeek's current privacy policy says that it directly collects, processes, and stores personal data in the People's Republic of China and retains different categories of data for periods tied to its stated purposes and legal obligations. That does not make every use of the service a breach, but it can affect privacy, contractual, regulatory, and data-residency decisions. Teams should evaluate the provider's current policy before employees submit confidential or regulated information.

Everyday employee mistakes: In 2023, Samsung restricted employee access to generative AI tools after staff uploaded sensitive source code to ChatGPT. The incident matters because the employee was trying to complete normal engineering work, not remove data from the company. The reported Samsung case shows why training alone cannot carry the full burden of control.

Connected agents and tools: AI systems increasingly work through desktop clients, coding environments, APIs, and agent interfaces. A connected assistant may read files, call an API, update a repository, or take another permitted action. Security teams therefore need to evaluate both the information sent to the AI and the authority granted to it.

How should security teams control employee AI risk?

Effective controls should follow the same context used in the threat model. A written policy remains useful, but employees also need guidance and enforcement at the moment they interact with AI.

1. Discover AI use across interfaces. Build an inventory that covers browsers, desktop applications, IDEs, extensions, APIs, and agent interfaces. Domain-level monitoring alone will miss activity that happens outside a traditional web session.
2. Distinguish managed and personal accounts. An application may be approved only when an employee uses the company workspace. Security controls should recognize which account is active instead of treating every session as equivalent.
3. Classify the data and the intended action. Define how source code, credentials, personal data, financial material, legal documents, health information, and other sensitive categories may be used. Account for uploads, pasted text, connected repositories, and agent actions.
4. Apply policy using the full context. Combine identity, account, device, application, data, and action before deciding whether to allow, warn, block, or request approval. This gives employees room to use approved AI while restricting specific high-risk behavior.
5. Intervene at the point of use and record the result. A warning can correct an accidental mistake before data leaves the device. Blocks should focus on clear policy violations, while logs and exception records help security teams refine the policy over time.

Frequently asked questions

What is the most common way employees expose sensitive data through AI?
Exposure often starts when an employee pastes text, uploads a file, or connects an AI assistant to company data while completing a legitimate task. The risk grows when the employee uses a personal account, an unreviewed application, or an interface the security team cannot see.

Are enterprise AI accounts safe for confidential data?
Enterprise accounts usually provide stronger data controls, but approval still depends on configuration, the data involved, and any connected applications or agents. Security teams should verify the provider's terms and apply company policy to the specific data and action.

Should companies ban employees from using generative AI?
A blanket ban can push useful work into personal accounts or unmanaged devices where visibility is worse. A safer approach combines approved tools, clear data rules, account awareness, and controls that act when an employee attempts a risky action.

Employee AI risk cannot be judged from a list of approved tools. Security teams need enough context to understand who is using AI, through which account and interface, what data is involved, and what the tool can do with it. That context makes it possible to control risky activity without blocking legitimate work.

‍