Join our Newsletter — 33% off our NHI Course
Home› Guides› Sensitive Data Pasted Into AI: Step by Step…
Guide Incident Response & Forensics

Sensitive Data Pasted Into AI: Step by Step Response When Staff Leak Data

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 8 November 2026 15 min read
On this page

An employee has pasted customer records, source code or a confidential document into an AI chatbot, and you need to decide within hours whether this is a policy slip or a reportable breach. This playbook covers the response once the paste has happened: how these incidents surface, the triage questions that decide severity, what to contain first, how to ask the AI provider to delete the data, the evidence to keep and the tests that decide whether regulators, customers or individuals must be told. It is written for incident responders, privacy and data protection officers, security operations leads and legal counsel. Prevention is covered separately in the Generative AI Data Loss Prevention Guide; this page assumes prevention has failed or was never in place.

Key takeaways

  • The account tier decides almost everything. A paste into an enterprise AI service under a data processing agreement is a very different incident from a paste into a personal, free account that may use conversations for training.
  • Secrets come first. If the pasted content held passwords, API keys, tokens or connection strings, rotate them before anything else, because deletion by the provider cannot be verified and takes days.
  • Deletion is a request, not a guarantee. Providers document retention windows of up to 30 days for deleted or temporary content and may keep data longer where the law requires, so treat the data as disclosed and plan on that basis.
  • Run the notification tests in writing. GDPR Article 33 gives 72 hours from awareness where feasible, HIPAA presumes a breach unless a four-factor assessment shows low probability of compromise, and contracts often add their own clocks.
  • Treat the employee as a witness, not a suspect. Most of these incidents are well-meant attempts to get work done; a blame-led response drives the next one underground and loses you the facts you need.

How the incident shows up

Detection rarely comes from one place. Responders should expect the first signal from any of the sources below, and should check the others once one fires, because the same person often pastes more than once.

SignalTypical sourceWhat it tells you
DLP or browser extension alert on a promptEndpoint DLP, secure web gateway, enterprise browser, AI usage control toolThe destination, the user, the matched rule (for example a card number or a secret pattern) and often whether the paste was blocked or only logged
AI service audit recordEnterprise AI admin console, compliance API, Microsoft Purview audit (record types such as CopilotInteraction and AIAppInteraction)That an interaction happened, which app, and resources accessed; Microsoft documents that the audit record carries message IDs and flags rather than prompt text, so content may need a separate retrieval route
Self-reportThe employee, a colleague or a managerUsually the fastest and most complete account, if your culture rewards reporting
Proxy or CASB discoveryWeb proxy logs showing uploads to an unsanctioned AI domainVolume and timing of uploads, but rarely the content
Secret scanning or credential abuseAn alert on a leaked key, or unexpected use of a credential that was only ever in codeA key that appeared in an AI conversation and was later abused; treat as active compromise
External reportA customer, journalist or the AI provider itselfThe worst case: the disclosure is already public or has been seen by a third party

Samsung's 2023 case shows the pattern: within weeks of allowing ChatGPT in one division, engineers pasted equipment measurement source code, defect analysis code and a meeting transcript into the public service, and the company responded first with a 1,024 byte prompt cap and then with a temporary restriction. See the Samsung ChatGPT Source Code Leak 2023 analysis.

Triage questions

Answer these in the first hour. Record each answer with its source (log, screenshot, interview) and the time you learned it, because the notification clock is measured from awareness.

  1. Which service and which account tier? Enterprise or business plan under your contract, an API key owned by your organisation, a personal paid account or a free consumer account. Ask the user to show the account, not describe it.
  2. What exactly was pasted or uploaded? Get the conversation itself where possible. Classify it: personal data (and whether special category or health data), payment card data, credentials and secrets, source code, client confidential material, material under NDA, export-controlled or classified material.
  3. How much, and how many people? Count records and data subjects. Ten rows of a spreadsheet and a full customer extract lead to different outcomes.
  4. Is the conversation still there? Has the user deleted it, shared it by link, or used a temporary or incognito mode? A shared link may expose the content to anyone who has it.
  5. What are the provider's training and retention settings for that account? For consumer ChatGPT, for example, OpenAI documents a "Improve the model for everyone" setting under Data Controls and states that Temporary Chats are deleted from its systems within 30 days. For the OpenAI API, it documents abuse monitoring logs retained for up to 30 days unless longer retention is required by law, and no training on API data by default.
  6. Were connectors, plugins or agents involved? If the assistant had access to mail, drives or code repositories, the exposure may be wider than the paste itself. See the AI Agent Incident Response Playbook if an agent acted on the data.
  7. Is this one event or a habit? Check the user's recent AI traffic and colleagues in the same team for the same pattern.

Use the answers to set a severity. A practical scheme:

SeverityTypical factsResponse
LowInternal non-sensitive content, enterprise tier under contract, no training useLog, coach the user, close within the team
MediumConfidential business data or limited personal data, enterprise tier, or small volume on a consumer tier with training disabledFull playbook, privacy officer review, deletion request, documented breach assessment
HighPersonal data at volume, special category or health data, client data under NDA, or any consumer tier with training enabledIncident declared, legal and DPO engaged, notification analysis against the clocks below
CriticalLive secrets, evidence of third party access, public share link, regulated data (PHI, card data) or abuse already detectedRotate immediately, major incident process, executive and regulator communications prepared

Containment priorities

Work in this order. Each step reduces a different exposure, and the earlier steps are the ones you can actually verify.

  1. Revoke and rotate secrets: any password, API key, OAuth client secret, token, private key or database connection string that appeared in the content. Rotate rather than wait for deletion, and check the credential's recent use for abuse. See the Secrets Rotation Runbook Template.
  2. Kill share links: if the conversation was shared, delete the shared link in the service first, then the conversation.
  3. Preserve, then delete: capture the conversation (export, screenshots with URL and timestamp) for the evidence file, then have the user delete it in the product. Do not delete before you have preserved, or you lose the record of what was disclosed.
  4. Stop the next paste: switch the matched DLP rule from audit to block for that destination, or block the unsanctioned AI domain for the user group while you investigate, and point users to the approved tool.
  5. Disable training on the account: for consumer accounts, have the user turn off model training in data controls. This affects future conversations; it does not undo past training use.
  6. Check connected access: revoke OAuth grants the assistant holds to corporate mail, drives or repositories if they were used or are no longer needed. See the OAuth Token Theft Incident Playbook for grant review steps.

Eradication

Eradication here means removing the data from every place you can reach and getting a documented answer from the provider for the places you cannot.

  • Provider deletion request: for an enterprise or API account, raise a request through your account team or the support route in your contract, cite the data processing agreement, give the workspace or organisation ID, user and conversation identifiers and the time window, and ask for written confirmation of deletion, the date it takes effect, and whether any copy is held in abuse monitoring logs, backups or under a legal preservation obligation. For a personal account, the user must submit the request through the provider's privacy request route because your organisation is not the account holder; support them through it and keep a copy.
  • Training question: ask directly whether the conversation was eligible for training and whether it has been used. Expect that content already used for training cannot be removed from a trained model; record the answer and factor it into the risk assessment rather than assuming it away.
  • Local copies: remove the data from downloaded responses, browser history exports, clipboard managers and any document the user built from the AI output.
  • Enterprise retention: if your enterprise AI service keeps conversations under a retention policy or compliance archive, decide with legal whether to keep the record (for evidence) or purge it (to reduce exposure). Do not purge if a legal hold applies. See the AI Data Retention and Deletion Guide for where AI data is copied.
  • Code exposure: if proprietary code was pasted, review it for embedded secrets, internal hostnames and vulnerability detail, and treat any vulnerability it reveals as disclosed.

Recovery

  • Return the user to work with a safe tool: give access to the approved enterprise AI service so the task that caused the paste can still be done.
  • Confirm rotated credentials work: verify dependent services after rotation, and watch for failed authentication from old keys, which may indicate someone tried the leaked value.
  • Close the policy gap that allowed it: if the destination was unsanctioned, decide whether to block it, approve an enterprise tier, or leave it allowed with DLP inspection. Record the decision. See the Shadow AI Policy Template.
  • Brief the team: share an anonymised account of what happened with the user's team, focused on what to paste and where, not on the individual.
  • Monitor: keep enhanced monitoring on the data type and destination for 30 to 90 days.

Evidence to preserve

EvidenceWhy it mattersWhere it lives
The conversation content and any shared linkDefines what was disclosed and the data subjects affectedThe AI service (export or screenshots), enterprise compliance archive
DLP, proxy and browser telemetryTimestamps, destination, volume, block or allow decisionDLP console, secure web gateway, enterprise browser logs
AI platform audit recordsProves the interaction, app identity and resources accessedAdmin console, compliance API, Purview audit for Microsoft services
Account tier and settings at the timeTraining and retention status drives the risk assessmentScreenshots of the account plan and data controls, contract and DPA
Interview notesPurpose, prior use, other pastes, who else knewIncident record
Provider correspondenceDeletion confirmation and training answerTicket history, email
Rotation recordsShows secrets were invalidated and whenSecrets manager audit log, change tickets
Decision logRecords the notification decision and its reasoningIncident record, signed off by DPO or legal

Keep action records with integrity protection so they stand up later; NIST CSF 2.0 RS.AN-06 calls for investigation actions to be recorded with their integrity and provenance preserved.

Notification triggers

Whether you must notify depends on the data, the jurisdiction and the account. Work through each test and write down the answer, including when the answer is "no".

RegimeTriggerClockNotes for AI pastes
EU GDPR and UK GDPR, supervisory authorityA personal data breach unless it is unlikely to result in a risk to individuals (Art. 33)Without undue delay and, where feasible, within 72 hours of becoming aware (Recital 85, Art. 33(1))Disclosure to a provider with no processor contract, or to a consumer service that may train on the data, is the strongest case for a breach. Disclosure inside an enterprise service under a DPA may still be a breach of policy or purpose; assess, do not assume
GDPR, data subjectsBreach likely to result in a high risk to individuals (Art. 34)Without undue delayHealth, financial and identity data, or data that enables fraud, raise the risk
GDPR, record keepingEvery personal data breach, notified or not (Art. 33(5))At the timeYour written triage and decision log is this record
US HIPAAImpermissible disclosure of PHI is presumed a breach unless a risk assessment shows a low probability of compromiseIndividuals without unreasonable delay and no later than 60 days after discovery; HHS and media where 500 or more are affectedThe four factors: type of PHI, who received it, whether it was actually viewed or acquired, and how far the risk was mitigated. A paste to an AI vendor with no business associate agreement is a hard case to argue as low probability
Contracts and NDAsClient, partner or customer data disclosed outside permitted processorsAs set in the contract, often 24 to 72 hoursCheck data processing agreements and NDAs for subprocessor and disclosure clauses
Sector and national rulesUS state breach laws, financial regulators, card brand rules for payment dataVariesMany US state laws are triggered by specific data elements; see the Breach Notification Laws by Country Guide

If your organisation is a processor for a client and the pasted data was the client's, Article 33(2) requires you to notify the controller without undue delay, and the controller runs the authority test. The Data Breach Notification Checklist covers the mechanics of each filing.

Lessons from incidents

  • Bans follow surprises: Samsung moved from allowing ChatGPT to restricting generative AI on company devices within weeks of the pastes becoming known. A playbook and an approved tool give you options other than a blanket ban.
  • Source code carries secrets: pasted code often includes keys and connection strings. Leaked-secret incidents show that keys left valid after exposure get used; see the Leaked Secret Breaches guide.
  • Deletion promises have limits: provider retention windows, abuse monitoring copies and legal preservation mean you should never tell a regulator or client that data is "gone" on the provider's word alone. Say what the provider confirmed, and when.
  • Silence makes it worse: organisations that learn of pastes from an external report lose control of the timeline. Make self-reporting quick and free of blame.

Common failure patterns

  • Deleting first: the user deletes the conversation in panic, and the organisation can no longer prove what was or was not disclosed.
  • Waiting on the provider before rotating: teams wait days for a deletion answer while a pasted key remains valid.
  • Treating all AI tools as one: responders do not check the account tier, so they either over-notify for an enterprise paste or under-assess a consumer paste with training enabled.
  • No written breach assessment: the team decides informally that notification is not needed and has no Article 33(5) record when the regulator asks.
  • Missing the processor duty: a services firm treats a client's data as its own and does not tell the client, breaching its contract and Article 33(2).
  • Punishing the reporter: disciplinary action for a self-reported, well-meant paste ensures the next one is hidden.

Framework mapping

FrameworkReferenceHow it applies
NIST SP 800-53 Rev. 5IR-9 Information Spillage Response, IR-9(2) Training, IR-9(3) Post-spill OperationsThe closest control to this incident: identify the spilled information, alert personnel, isolate, eradicate and keep people working afterwards
NIST SP 800-53 Rev. 5IR-4 Incident Handling, IR-6 Incident Reporting, IR-8 Incident Response PlanHandling, reporting and a documented plan that includes this scenario
NIST CSF 2.0RS.MA-03, RS.AN-03, RS.AN-06, RS.CO-02, RS.MA-01Categorise and prioritise, analyse what happened, preserve records, notify stakeholders, coordinate with third parties such as the provider
NIST CSF 2.0GV.SC-07The AI provider is a supplier whose risk must be understood and responded to
NIST SP 800-61 Rev. 3CSF 2.0 Community Profile for incident responsePlaces this playbook inside the wider incident response programme
OWASP Top 10 for LLM Applications 2025LLM02:2025 Sensitive Information DisclosureThe application-side view of the same risk
GDPRArt. 4(12), 33, 34Definition of a personal data breach and the notification duties

Practitioner checklist

  • Add an "AI paste" scenario to the incident response plan with named owners in security, privacy and legal.
  • Keep a register of approved AI services with their account tier, training setting, retention and the deletion contact for each.
  • Pre-write the provider deletion request with the fields providers need: organisation ID, user, conversation IDs, time window and the questions on training and backups.
  • Make the first action for any paste containing credentials an immediate rotation, without waiting for triage to finish.
  • Teach users to report and to preserve before deleting, and publish a simple reporting route.
  • Write a breach assessment for every case, including the ones you do not notify, and get DPO or legal sign-off.
  • Check processor and NDA obligations whenever the pasted data belongs to a client.
  • Run a tabletop exercise on this scenario at least once a year and track time to rotation and time to decision.
  • Measure: number of AI paste incidents, share self-reported, median hours to secret rotation, median hours from awareness to notification decision, and repeat incidents per team.

Standards and references

Related NHI Mgmt Group resources: Generative AI Data Loss Prevention Guide · AI Data Retention and Deletion Guide · Data Security Incident Scoping Playbook · AI and GDPR Guide · Shadow AI Discovery Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org