How to prevent corporate secrets from reaching public AI services

There is no single filter that catches every password or code fragment. Effective protection has three parts: an approved company AI tool, clear employee rules, and technical controls for specific channels. Data Loss Prevention (DLP) systems can inspect and block some actions on managed devices. But they cannot guarantee that they will recognize every secret, and they do not control an employee’s personal phone.

The endpoint controls described here require a supported device, browser, and policy configuration. Other protection layers, such as access control for a corporate application, may also limit unmanaged devices, but they are separate mechanisms.

After reading, you can identify the data classes to protect, understand which channels technical controls actually cover, run a pilot without stopping the team, and respond if a secret has already left the company. We use Microsoft Purview as a DLP example based on documentation reviewed for the research dated 11 October 2026. Check other systems against their own documentation.

A typical leak path

Start with a training example. It is fictional and shows how a leak can happen, not a real incident.

A developer hits an error in a payment-service integration. To troubleshoot quickly, they copy part of a configuration file into a public chatbot and ask, “why is this request failing?” A working API key is included with the code. The answer helps and the problem is fixed in five minutes. But the key now sits in a service with which the company has no agreement, under terms determined by the developer’s personal account.

Nobody intended harm. That is why these leaks are hard to notice: they look like ordinary work. There are four common channels.

Text paste. Code, part of an email, or a table of personal data is copied into a chat field. No separate file upload is needed.

File upload. A contract, CRM export, or customer presentation is uploaded in full so the model can “read everything.”

Browser extension. An extension with AI features may access the content of pages an employee views. The employee may not even realize that data is being sent elsewhere.

Personal account and device. Even if the company has a corporate AI tool, an employee may open a familiar personal account. Corporate data-processing terms do not apply to that account. Controls on a work laptop do not automatically cover a personal phone.

Which data to protect

A rule like “don’t paste anything confidential” does not work because people define confidentiality differently. Divide data into classes and write a specific action for each. The table below is a proposed internal-policy template, not a universal legal prohibition.

Access secrets get their own category for a reason. They cannot be “partly de-identified”; after a leak, they must be revoked and replaced. The best defense is architectural: storing keys in a secret manager reduces the chance that someone copies them with a configuration file. But a value can still end up in a log, environment variable, or command output, so a secret manager does not replace control of those channels. Our article on GDPR and HIPAA discusses which personal data may be sent to AI and on what basis.

What DLP can actually do

A DLP policy defines five things: which device it applies to, which app or browser, which action it controls, how it recognizes sensitive content, and how it responds. Consider Microsoft Purview’s control for pasting sensitive content into a browser.

Device. Endpoint policies operate on managed devices enrolled by the company in DLP. A personal laptop or phone that is not enrolled is invisible to the policy.

Browser. Microsoft’s scenario page lists Edge, Chrome, and Firefox for Windows/macOS, and Safari for macOS; notes about Chrome/Firefox extensions apply to Windows. This short list does not prove identical behavior across platforms. Check the support matrix for your OS and test pasting in every browser. The absence of a Windows extension on a Mac alone does not prove that the macOS scenario is unsupported.

Action type. Browser paste is only one controlled action. The DLP policy reference also lists browser file uploads, clipboard copying, printing, copying to removable media and network shares, Bluetooth transfers, and remote desktop. Each action is configured separately. Paste control does not mean control of all text in every application.

Content detection. The browser-paste rule triggers when the content contains selected sensitive-information types. It checks at the time of paste and does not rely on the label of the file the text came from. For Paste to Browser, the reference specifies that sensitive information types (SITs), not sensitivity labels, are supported; text shorter than 30 characters is not evaluated; and only the first 4 MB of text is classified. In practice, the system detects content for which a matching sensitive-information type exists. It may miss internal code without recognizable patterns or a password that does not resemble a known format. Do not promise that it recognizes every code fragment or password.

Where and how to respond. Browser paste requires sensitive-service domain groups: lists of sites to which the rule applies. You can create multiple groups and choose a response for each: audit, block with an override, or block completely. The documentation also warns that there may be a short delay between a paste attempt and classification, during which the user sees a notification.

Before writing an internal setup guide, check your configuration: employee operating systems, browsers, licensing, and required extensions. Testing Edge on Windows does not prove that the same setting works in Safari on Mac. Test each supported configuration; a separate policy is not necessarily required.

Control-boundary table

This training table shows three distinct channels and the actual limits of technical protection.

The last row matters most. If an employee can open a contract on a personal phone, laptop DLP cannot stop them from passing the text along. Protection shifts from intercepting an action to controlling who can access the original and from which device.

How to keep the team working

A hard block with no alternative predictably leads to workarounds: someone opens a personal account on a phone, someone else photographs the screen. Technical controls work better when there is a legitimate way to do the same work.

Approved tool. Give employees a corporate AI service with business data-processing terms. OpenAI, for example, says it does not train models on customer business data by default and that consumer account terms do not carry over to corporate products. An approved tool makes the route clear: employees know where they may go and where they may not. Our article on enterprise AI training terms explains what to check in the contract and settings.

Domain groups with different responses. Purview documentation describes two approaches: audit by default with block exceptions for risky sites, or block by default with audit exceptions for trusted sites. A domain alone may not distinguish corporate and personal accounts on the same service. Pair domain permission with work-account control or another verified way of separating them.

Justified exceptions. Some teams need access to services blocked for others. Grant exceptions to a group for a defined period and assign an owner instead of creating a permanent “for our people” allowance.

Training. Show examples of what employees may and may not paste. Explaining why a key must not be pasted even into a corporate chat works better than a rule without a reason.

Support channel. If policy blocks a legitimate action, employees need to know where to ask and how long a decision takes. Without that channel, they see a block as an obstacle rather than protection.

Pilot and false positives

Turning on blocking for the entire company on day one is risky. A classifier may react to test data, documentation examples, or internal identifiers that resemble document numbers. Run a pilot in three steps.

Step 1: Audit without blocking. Enable the policy in audit mode for a limited device group. See which events it records, on which sites, and for which data types.

Step 2: Test examples. Prepare synthetic data: fake keys in formats your company uses, fictional personal data, and code fragments with no real secrets. On managed devices, test each supported browser and record what triggers and what does not. Never use real secrets for testing.

Step 3: Enable targeted blocks. Block data types and site groups where the audit showed a real risk and an acceptable false-positive rate. Leave other cases in audit mode or allow an override that requires the employee to confirm the action and provide a reason.

After the pilot, record what the policy does not catch. That list is as important as what it detects because it shows where organizational controls are needed.

Assess logs separately. A policy that collects evidence may store the content an employee tried to paste. Collect only events needed for protection, restrict log access to a small group, and document monitoring rules for employees before the policy launches.

What to do after a leak

If a secret has reached a third-party service, deleting the chat does not restore its confidentiality. Revoking access comes first; in parallel, use available data-deletion mechanisms and the agreed provider-support channel.

Restrict access. If the leak involved a particular account, device, or integration, temporarily restrict it until you know what else may have left the company.

Revoke compromised secrets. Treat a leaked key, password, or token as compromised. Revoke it and issue a new one regardless of whether the service retains chat history. Check logs for systems the key could access for suspicious activity between the leak and revocation.

Preserve facts. Record what was sent, when, through which channel, and who learned about it. Preserve DLP events and access logs. These facts help assess impact and, where personal data is involved, help a lawyer decide what obligations follow.

Fix the process. Find out why the secret was present in copyable text. Can it move into a secret manager? Did the employee have an approved tool for the task? Is a DLP rule needed for that key format? The review should remove the path that caused the leak, not search for someone to blame.

What to do next:

1. List data classes and write an AI-service rule for each.
2. Move access secrets from configuration files into a secret manager where this has not been done.
3. Provide an approved corporate AI tool and explain what employees may send to it.
4. Check the devices, browsers, licenses, and extensions on which DLP will operate.
5. Run an audit-mode pilot on test data and record what the policy catches and misses.
6. Approve a post-leak process: who restricts access, revokes secrets, gathers facts, and owns process fixes.

Frequently asked questions