A recent write-up from Jazz Security walks through real AI data leak examples, from Samsung engineers pasting code into ChatGPT to the EchoLeak and Salesloft Drift incidents. For each case, it covers who found the problem, its current status, and the control that could have seen or limited the exposure. The cases are different in technical detail, but they share a theme: the leaks did not start with exotic attacks. They started with routine behavior and trusted connections.

This post draws on that summary and the editorial angle behind it. The source material available to us is brief, so we stick to the broad patterns it describes rather than adding technical specifics we cannot verify.

What happened in the Samsung, EchoLeak and Salesloft Drift leaks

The three cases cover three different ways AI-related data exposure happens.

Samsung. Engineers pasted code into ChatGPT. No hacker was needed. Employees used a public chatbot as a work tool, and sensitive material left the company's control the moment it was submitted.

EchoLeak. This incident is grouped with the others as an example of an AI feature exposing data through the way it processes content and connects to other information. It shows that the risk is not limited to what a person types. The AI system's own access to data matters too.

Salesloft Drift. This case involved connected OAuth integrations. OAuth lets one app access data in another without sharing a password. That is convenient, but when a connected service is compromised, the access tokens it holds can become a path into every account it was linked to.

The Jazz Security piece also records who discovered each case and where it stands today. For readers, the more useful takeaway is the pairing of each case with a control: something that could have given visibility into the activity or limited how far the data traveled.

AI data leak examples: how everyday AI use exposed data

What stands out across these AI data leak examples is how ordinary the starting points were.

Pasting text into a chatbot feels like using a search box or a notes app. It does not feel like sending data to a third party. That gap between perception and reality is where the Samsung-style leak happens. Once information is submitted, you generally have limited insight into where it is stored or who can access it under the service's terms.

Connected apps work the same way. Granting an integration access takes a couple of clicks, and the permission often sits untouched for months or years. If the vendor behind that integration is breached, the exposure reaches data you may have forgotten you shared.

AI assistants add a third layer. When a tool can read your email, documents or messages to be helpful, anything it can read is potentially in play if the tool behaves in an unintended way. The EchoLeak example illustrates why access scope matters as much as the quality of the AI itself.

What the affected people and organizations lost

The specifics differ by case, and we will not guess at figures that the source summary does not give. In general terms, the exposure falls into a few categories:

  • Proprietary information. Source code and internal material entered into a public chatbot can no longer be treated as private.
  • Business and customer data. Connected-app compromises can expose records stored in the linked platforms, which affects the customers and contacts of the organizations involved, not just the organizations themselves.
  • Control and visibility. In many incidents the lasting damage is not only the data itself but the loss of any clear picture of where it went.

This pattern also appears outside enterprise settings. The Suno data breach, which exposed the personal information of more than 55 million users and was never disclosed to them, shows how an AI service holding user data can become a point of exposure even when users did nothing unusual.

What This Means For You

You do not need to work at a large company for these lessons to apply. Individuals paste personal documents, medical questions, contracts and work drafts into chatbots every day. Many also connect AI tools and other apps to email, calendars and cloud storage.

The practical point is that your exposure depends on two things you control: what you hand to an AI service, and what access you leave switched on. Neither requires technical expertise to manage. Broader context on how AI is changing the threat picture is covered in our look at AI ransomware and flawed test models that leak data.

Habits that limit your own AI exposure

  • Treat a chatbot prompt like an email to a stranger. If you would not send it outside your organization or household, do not paste it in.
  • Remove identifying details first. Replace names, account numbers, credentials and client information with placeholders before asking for help.
  • Check your work policy. If your employer provides an approved AI tool, use it instead of a personal account. If there is no policy, ask for one.
  • Review connected apps regularly. Open the security or permissions page of your email, cloud storage and workplace accounts, and remove integrations you no longer use.
  • Prefer narrow permissions. When an app asks for broad access, check whether a more limited option exists.
  • Review chat history and data settings. Look at what your AI services retain and whether you can opt out of training use or delete past conversations.
  • Use unique passwords and multi-factor authentication. These do not stop every leak, but they limit what an exposed account can lead to.

Takeaways

The AI data leak examples from Samsung, EchoLeak and Salesloft Drift point to the same conclusion: the biggest exposures often come from convenience, not sophisticated attacks. Start by auditing what you paste into chatbots, then go through your connected apps and revoke what you do not need. For another example of AI-service data exposure, read about the Suno breach, and for wider context on AI-related risk, see our AI ransomware coverage. A few minutes of review now is far easier than trying to find out later where your data went.