An engineer is stuck on a bug in code that is part of their employer’s unreleased product. It is 9pm, the personal ChatGPT tab is already open, and pasting the whole function in feels like the fastest way to get an answer. In March 2023, within about three weeks of Samsung’s semiconductor division being permitted to use ChatGPT, the company identified three cases of exactly this: one employee pasted source code from a semiconductor database program to have errors found, a second submitted equipment-related code and requested “code optimization,” and a third uploaded a meeting recording to be turned into minutes. Samsung’s immediate response was an emergency cap of 1,024 bytes per prompt (The Economist Korea’s reporting, summarized in English by Mashable). By 1 May 2023 it had gone further, temporarily restricting generative AI tools on company-owned devices entirely (TechCrunch, “Samsung bans use of generative AI tools like ChatGPT after April internal data leak,” 2023).
Nothing in that reported incident required malicious intent. Submitting confidential material to a third-party service can violate policy or contract and can weaken the owner’s control even if the material is not published. The exact legal effect and notification duty depend on the facts and jurisdiction.
What actually counts as a “work secret”
Not everything work-related is a secret in the sense this article means. The category that needs the stop check is narrower and more specific:
- Source code from a proprietary, unreleased, or competitively sensitive system.
- Unreleased financial figures — quarterly results before public disclosure, internal forecasts, pricing strategy.
- Unannounced product or business plans — a feature roadmap, an acquisition target, a pending partnership.
- Security details — vulnerabilities, credentials, tokens, private URLs, architecture diagrams, or production configuration.
- Contracts and terms under NDA — client contracts, supplier agreements, anything a signature already promised to keep confidential.
- Documented trade secrets your employer has specifically labeled or handled as such (a formula, a process, a customer list built at real cost).
- Personal or regulated data about customers, employees, patients, students, or other people, even when it is not a trade secret.
A first draft of a routine internal memo, a public job description, or a generic process question is not in this category — the point is not to be afraid of AI; it is to recognize the narrower set of things that genuinely need a different path.
Why this is more than an IT courtesy
Most workplace AI guidance frames this as a policy-compliance issue, which is true but understates the stakes for genuine trade secrets specifically. Under U.S. law, information only qualifies for trade secret protection if its owner “has taken reasonable measures to keep such information secret” (18 U.S.C. § 1839(3)(A), enacted by the Economic Espionage Act and amended by the Defend Trade Secrets Act) — protection depends on an ongoing pattern of actually keeping the information controlled, not just on the information being valuable or unpublished. EU law sets a comparable bar: a trade secret must have “been subject to reasonable steps under the circumstances, by the person lawfully in control of the information, to keep it secret” (Directive (EU) 2016/943, Article 2(1)(c)).
Consumer services do have terms, but those terms may not be the employer-negotiated confidentiality, security, retention, location, and data-processing terms required for the material. Sending a genuine trade secret to an unapproved provider can work against the owner’s reasonable secrecy measures. Whether a particular incident is a legal disclosure or affects protection depends on the terms, controls, facts, and jurisdiction; employees should not make that determination from a product label.
Deleting the visible chat does not undo the transmission and may not satisfy incident-response or evidence-preservation duties. If an accidental paste occurs, stop, record the tool, account, time, and data category without copying the secret again, and report it promptly through the employer’s security or privacy process. Follow its instructions on deletion, credential rotation, provider contact, evidence, and notifications.
The misconception that causes the damage
The damage can start with judging risk only by whether the secret became public. Transmission to an unauthorized third-party service can matter even if the material is not later published. Product tier, tenant configuration, contracts, and provider controls differ; a brand or “enterprise” label alone does not establish approval. Your employer’s authorized policy owner is positioned to assess the exact path. Privacy and data hygiene at work covers how to check a tool’s actual data-handling terms once you know which tool you are using; this article covers the narrower rule of not pasting the secret while you are unsure.
A second misconception treats “everyone on my team does this” as evidence it is fine. The Samsung case involved multiple engineers making the same reasonable-sounding individual choice, independently, before anyone at the company caught it. Peer behavior is not verification.
A third misconception is assuming this rule only applies to engineers and source code. Financial figures, an early draft of an acquisition memo, and a spreadsheet of unreleased pricing tiers are just as exposed the moment they are pasted into a personal account, and the person handling them is often in finance, sales, or operations rather than engineering — the six-category check below applies the same way regardless of your role or department.
The six-category stop check
Before pasting anything into any AI tool that is not your employer’s specifically approved, enterprise-configured account, check whether it falls into any of these:
- Source code from an unreleased or proprietary system.
- Financial figures not yet publicly disclosed.
- An unannounced product, feature, or business plan.
- A security detail — a vulnerability, credential, or production architecture.
- Anything covered by a signed NDA or confidentiality clause.
- Anything your employer has classified as confidential, plus personal or regulated data covered by policy or law.
If any answer is yes, stop. Finding and reading your employer’s actual AI policy is the first step to finding out whether an approved tool exists for this kind of content at all — some companies have one, some do not yet, and guessing either way is the mistake this article exists to prevent.
What to do instead
- Use only the exact tool, tenant, account, and data class your employer approved. A work email address or enterprise marketing label is not enough by itself.
- If no approved tool exists for this kind of content, do not use AI on it yet. Ask your manager or IT/security whether an exception process exists, rather than deciding alone that the convenience is worth the risk.
- If policy permits an abstract pattern question, use synthetic or minimum-necessary data and re-check for re-identification, business logic, secrets, and personal data. De-identification is a risk assessment, not a find-and-replace exercise.
Audit your last AI conversation
Review recent work-related AI use without copying sensitive content into a new location. If something may have entered an unapproved tool, use the employer’s incident route promptly and do not independently delete or alter evidence unless instructed. Rotate exposed credentials through the approved emergency process. The work secrets paste-stop card gives you a version of the pre-paste check.
The ICO internal AI use policy, NCSC secure AI guidance, and ICO data-minimisation guidance support approved-system, incident, security, and minimum-necessary controls. They do not decide the legal effect of a specific disclosure.
