In April 2023, engineers at Samsung's Device Solutions division in Hwaseong, South Korea pasted confidential material into ChatGPT three separate times in roughly 20 days: internal semiconductor equipment source code, a proprietary chip-defect-identification program, and a transcript of a confidential internal meeting. None of it was malicious — employees were troubleshooting code and summarizing notes with a tool that felt no different from a search engine. But once that text left the corporate network, Samsung had no way to retrieve it, and no visibility into how OpenAI's infrastructure might store, log, or use it. By May 2023, Samsung banned ChatGPT and other external generative AI tools on company devices and networks and began building an internal model instead. The incident became the canonical case study for a new risk category: employees don't need to be compromised or malicious to cause a serious data-loss event — they just need a browser tab and a paste command. This post covers the concrete controls — network, endpoint, and model-layer — that stop this pattern without banning AI tools outright, since outright bans tend to just push usage underground.
Why did the Samsung ChatGPT leaks matter more than a typical insider-risk incident?
The Samsung leaks mattered because they showed how fast a single policy gap compounds under normal, well-intentioned engineering behavior. Samsung had just lifted restrictions on generative AI use for employees, and within about 20 days, engineers pasted confidential equipment source code (twice, from separate teams) and a recording transcript into ChatGPT to get debugging help and meeting notes. Each incident individually looks like ordinary developer behavior — copying a stack trace or a code block into a chat tool is a habit millions of engineers had already formed with Stack Overflow. What made it a landmark case is that the data left the company's control the moment it was submitted: OpenAI's consumer ChatGPT tier at the time could retain conversation data for model improvement absent an opt-out, and Samsung had no contractual guarantee, no outbound inspection, and no way to claw the text back. The response — an outright ban plus an internal-model investment — is the blunt version of the fix; most organizations since have converged on more targeted controls instead.
What does OWASP say about sensitive information disclosure in LLM applications?
OWASP's Top 10 for LLM Applications, in its 2025 edition, ranks LLM02:2025 "Sensitive Information Disclosure" as the second-most critical risk category for LLM applications — up from sixth place in the prior list. OWASP frames the risk broadly: sensitive data can leak not just through a model's visible chat response, but through logs, cached conversations, embeddings stored in vector databases, and even training or fine-tuning data if an organization feeds proprietary material into a model that retains it. The mitigations OWASP names are specific and actionable: avoid placing secrets or credentials directly into prompts, apply access control and data classification before information ever reaches the model (not after), sanitize both inputs and outputs, and redact PII and proprietary data from prompts and responses rather than relying on a model to "forget" it. The framework's move from 6th to 2nd place reflects how much LLM adoption accelerated between the two OWASP editions, and how much of that adoption happened through consumer-grade tools with no enterprise data controls attached.
Which technical controls actually stop code and data from reaching public AI tools?
Three layers of control catch what policy alone misses. First, network and browser egress controls: a proxy or secure web gateway that recognizes traffic to consumer AI endpoints (chat.openai.com, public Claude/Gemini web UIs) and either blocks it outright on managed devices or routes it through an inspection point. Second, CASB and DLP inspection of outbound prompts — the same class of tooling long used to stop source code or customer PII leaving via email or cloud storage, retuned to recognize secrets, credentials, and proprietary code patterns inside a chat textbox before the "send" request leaves the browser. Third, enterprise tiers of the AI tools themselves: ChatGPT Enterprise, Microsoft Copilot, and equivalent business-tier offerings now carry contractual no-training-on-inputs terms, meaning prompt content isn't used to improve the underlying model or retained the way a free consumer account's history might be. None of these three layers is sufficient alone — network controls miss traffic on unmanaged devices, DLP pattern-matching misses novel secret formats, and enterprise contracts don't stop an employee from pasting into the wrong (personal) account. Layered together, they cover most of the real-world leak paths.
Did regulators treat consumer generative AI data handling as a compliance problem?
Yes — Italy's data protection authority, the Garante, temporarily banned ChatGPT in March 2023, ordering OpenAI to suspend processing of Italian users' data over concerns including the legal basis for collecting training data, the absence of age verification, and the accuracy and provenance of personal data surfaced in model outputs. OpenAI restored service in Italy about a month later after adding age checks, a form for EU users to object to their data being used for training, and clearer disclosures. The episode mattered beyond Italy because it established, with a real regulator's enforcement action rather than a hypothetical, that "we typed it into a chat window" does not exempt an organization's data from the same data-protection scrutiny applied to any other processing activity — a principle that has continued to inform how EU AI Act guidance and enterprise procurement teams evaluate generative AI vendors since.
How should a security team monitor and enforce policy on internal AI usage, not just public tools?
Public consumer tools are the highest-profile leak path, but internally-built LLM applications and copilots carry the same sensitive-information-disclosure risk OWASP describes in LLM02 — the difference is that a security team actually controls the infrastructure and can inspect traffic inline rather than relying on browser-level blocking. Safeguard's AI Gateway applies this pattern directly: it sits as a runtime layer between an application and its model provider, evaluating every prompt, response, and tool call against guardrails that flag PII and secret egress for redaction and injection or jailbreak attempts for blocking. Monitor mode — recording a guardrail event on every interaction without altering traffic — is available today and is the right first step for any team that wants a baseline of what proprietary data or credentials are already flowing through internal AI features before turning on enforcement; inline redact/block enforcement is rolling out behind a gated per-tenant flag. Critically, the gateway is fail-open by design and never persists raw prompt or response text, so adding this visibility doesn't introduce a second copy of the sensitive data it's trying to protect.
How Safeguard helps
Public-tool leaks like Samsung's need policy, browser controls, and enterprise contract terms — Safeguard's role is the layer most organizations don't build themselves: visibility into what your own internal AI applications and copilots are actually sending and receiving. The AI Gateway inspects prompt and response traffic for secret and PII egress in monitor mode today, giving security teams the same kind of baseline DLP telemetry for internal LLM features that CASB tools long provided for email and cloud storage, without requiring inline enforcement on day one. As that data feeds into Safeguard's broader AI-BOM inventory of LLM apps and endpoints, teams get a single place to answer the question Samsung's leadership had to answer the hard way after the fact: which AI surfaces exist across the company, and what sensitive data has actually moved through them.