Securafy AI Lab

The Never-Paste List: What Should Never Go Into a General AI Tool

Written by Rodney Hall | Aug 19, 2026, 12:00:00 PM

"We told everyone not to paste client data into ChatGPT. So why did it still happen?" I hear some version of that question more than almost any other AI question, usually a week or two after someone in finance or HR pasted something they should not have. The honest answer is that the policy was never the problem. The absence of anywhere else to put the work was.

The direct answer: a never-paste list should cover regulated data (PHI, cardholder data, CUI), credentials and secrets, unreleased financials, customer PII, NDA-covered contracts, source code with embedded keys, HR and investigation records, and incident details. A list alone does not stop the behavior. It only works when every prohibited category has a sanctioned place to go and a reminder that fires at the moment of pasting, not in a policy document nobody reopens.

Why Doesn't a "Never Paste This" Policy Actually Stop the Pasting?

Most AI acceptable use policies are built the same way: a list of forbidden data types, a signature line, and an assumption that awareness equals compliance. That assumption fails for a specific operational reason. The employee about to paste a contract clause into a general AI tool has a real task and a deadline attached to it. Telling them "no" without telling them "do this instead" does not remove the task. It just removes the visible channel.

This is the contrarian point worth sitting with: prohibition without a faster, obviously-better sanctioned alternative does not eliminate the risk, it relocates it. What changes is that the next paste happens from a personal phone, on a personal account, off the corporate network, where IT has no visibility and no logging. A never-paste list that stops at "don't" trains people to route around the one place you can actually see the behavior — a worse outcome than the one the policy was written to prevent, a pattern we cover in more depth in our piece on why AI without governance is risk, and what to do instead.

I have watched this pattern play out repeatedly: a well-intentioned policy rollout, a temporary dip in usage, then usage creeping back through unmanaged channels within a month. The fix is not a stricter list. It is pairing every "never paste this here" with a "paste it here instead" that is genuinely faster than opening a personal tab, the core argument behind our guide to building an AI acceptable use policy people actually follow.

What Should Never Go Into a General-Purpose AI Tool?

Eight categories account for the overwhelming majority of exposure risk in SMB environments, and every operations leader should be able to recite them without checking a document:

  • Regulated data classes — protected health information (PHI), cardholder data governed by PCI DSS, and controlled unclassified information (CUI) under federal contract requirements.
  • Credentials and secrets — passwords, API keys, tokens, and connection strings, even "temporarily" for debugging.
  • Unreleased financials — earnings figures, forecasts, or board materials before public disclosure.
  • Customer personally identifiable information — full names paired with SSNs, account numbers, or other identifiers.
  • Contracts under NDA — vendor agreements, partnership terms, or M&A documents with confidentiality obligations.
  • Source code with embedded secrets — proprietary logic or hardcoded credentials, keys, or internal hostnames.
  • HR and investigation records — disciplinary files, harassment complaints, and termination documentation.
  • Incident details — breach specifics, vulnerability findings, or active investigation notes.

Each category carries a distinct consequence: a compliance violation, a contractual breach, a competitive loss, or a legal exposure a general AI vendor's terms of service were never designed to absorb. The list itself is not new information to most leaders. What is usually missing is the operational half.

What Actually Happened When Samsung Engineers Pasted Code Into ChatGPT?

In 2023, engineers in Samsung's semiconductor division pasted proprietary source code and internal meeting notes into ChatGPT while trying to do their jobs faster — debug code, optimize a test sequence, generate meeting minutes. None were acting maliciously. Forbes reported that the discovery led Samsung to ban ChatGPT and other generative AI chatbots company-wide, citing concern that data submitted to these platforms is stored on external servers the company cannot access or delete.

The lesson is not "engineers are careless." Samsung had just lifted an internal restriction on ChatGPT use days earlier, handing employees a capable tool without a sanctioned, monitored place to do exactly the kind of work they immediately needed. That gap — between "here is a powerful tool" and "here is where you're allowed to use it for sensitive work" — is where the leak happened, and it is the same gap that shows up in SMB environments that skip straight to a tool rollout without an operational path attached.

Is a Consumer AI Account Really Different From an Enterprise Tenant?

Yes, and the difference is contractual, not just cosmetic — this is the distinction most internal policies get wrong. On a free or personal-tier account, OpenAI's own documentation states that conversations may be used to improve its models unless the user opts out in settings. On ChatGPT Business, ChatGPT Enterprise, and the API, OpenAI's enterprise privacy page confirms that customer prompts and business data are not used for training by default, and the customer retains ownership and control over inputs and outputs, including retention settings and SSO-based access control. Microsoft draws the same line: under its enterprise data protection documentation for Microsoft 365 Copilot, commercial prompts and responses are covered by its Data Protection Addendum, are not used to train foundation models, inherit the customer's existing identity permissions and sensitivity labels, and support audit logging — protections that do not exist on a personal Microsoft account.

What actually changes between the two tiers is not the underlying model. It is the contract wrapped around it: a data processing agreement creating legal accountability, a no-training commitment that keeps your data from resurfacing in someone else's output, tenant isolation that keeps your content out of a shared pool, and audit logging that proves, after the fact, who submitted what. A consumer account has none of this. "We use ChatGPT" is not a security control — "we use ChatGPT Enterprise, provisioned through IT, with logging enabled" is.

DimensionConsumer / free tierEnterprise tenant
Model training on your inputOn by default unless the user opts outOff by default under contract
Governing agreementStandard consumer terms of serviceData processing addendum / business terms
Data isolationNone — shared consumer infrastructureTenant-isolated environment
Access controlIndividual login, no admin oversightSSO, admin console, permission inheritance
Audit visibilityNone available to the employerLogging and compliance reporting available

This is why the never-paste list cannot be evaluated apart from which account the employee is using. A prohibited data type in a consumer tab is a serious incident; the same task, routed through a properly provisioned enterprise tenant, is often exactly what the tool should be used for.

How Do You Make a Never-Paste List Actually Work?

The operational fix has three parts, and skipping any one is why most policies underperform. First, name the sanctioned tool in the same sentence as the prohibition — not "don't paste contracts into ChatGPT" alone, but "use the enterprise-licensed tenant instead, where the DPA and audit logging apply." Second, put the reminder at the point of action, not in a handbook — a banner, browser prompt, or DLP rule that fires when someone opens a paste box beats a page in an onboarding packet nobody rereads. Third, review what actually got submitted. Enterprise tenants log activity; that log is the only reliable way to know whether the list is working or just feels like it.

This lines up with how NIST's AI Risk Management Framework frames the problem: governance has to be paired with ongoing measurement and management, not a one-time policy document. It is also consistent with how HHS describes the HIPAA Security Rule's expectation of administrative, physical, and technical safeguards working together — a written PHI policy means little without technical controls enforcing it at the point of use.

What Happens After the List Is Broken Anyway?

Assume, realistically, that someone will paste something they shouldn't, even with a good list and a sanctioned alternative. The operational question becomes how fast you find out and what you can prove. Enterprise tenants with retention controls let you locate and, depending on configuration, delete the submission. Consumer accounts generally do not — once submitted, you are relying on the vendor's terms of service with no organizational visibility into what happened next. That gap is the entire argument for provisioning the sanctioned tool before you need it, not after an incident forces the conversation. Our guide on where SMBs should start with AI security controls walks through that sequencing, and our piece on safeguarding sensitive data in Microsoft Copilot gets specific about the settings that make the enterprise/consumer distinction real in that product.

The categories on the list rarely change. What changes is whether an organization has done the unglamorous work of giving people somewhere better to go, and whether that path shows up at the exact moment someone is about to click paste.

How Does Securafy Help SMBs Build a List That Holds Up?

When we work with a client on this, we do not start by writing a longer prohibition list — most already have one, and it is usually fine as far as it goes. We start by mapping which teams are already using AI tools informally, what they are pasting, and which of those tasks have no sanctioned home yet. Often the fastest fix is not a new tool at all; it is provisioning the enterprise tier of something they already pay for, turning on the admin controls sitting unused, and adding a lightweight DLP rule that catches the obvious categories — SSNs, card numbers, key-shaped strings — before submission rather than after.

We also help clients build the habit layer around the technical control: a short, role-specific walkthrough of what goes where, delivered close to the moment people need it, rather than buried in an annual training module. That combination — sanctioned path plus paste-time reminder plus a working audit trail — is what turns a never-paste list from a document into an actual control. Our broader look at securing Copilot and AI agents before they become shadow IT covers how we sequence that rollout, and the reasoning behind treating AI adoption as a governance problem rather than a tooling problem is the same logic applied company-wide.

None of this requires slowing teams down. It requires making the safe path the fast path — the same principle behind password managers replacing sticky notes and ticketing systems replacing hallway requests. The AI version is simply newer.

Where To Go From Here

A never-paste list only holds up when it is taught alongside the sanctioned alternative and reinforced at the moment someone reaches for the paste command — not filed away as a policy document.

If your team is moving faster with AI than your guardrails are, start with structured training rather than another tool. Securafy AI University gives your people role-based AI training with security built into the material, not bolted on afterward.

If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk your current AI usage, exposure, and the fastest path to safe adoption.