L6Core4 min read

What never goes in a prompt

Customer data, credentials, unreleased material, anything under an NDA. The rules are simple, the pressure to bend them is constant, and testers touch more sensitive data than almost anyone. Learn this before the tooling, not after.

A prompt leaves your machine. That is the whole of it.

Whatever you paste travels to a provider, may be retained under their terms, may be logged by an intermediary, and is out of your control the moment you press enter. None of that is sinister. It is simply what sending data somewhere means.

Testers are unusually exposed here, because the job involves handling production exports, real customer records, logs full of identifiers, and credentials for environments. More sensitive material passes through a tester's hands in a week than through most roles in a month.

So the list below is short, absolute, and worth knowing before you need it.

The five categories

Customer or employee personal data. Names, emails, addresses, payment details, health or HR information. Includes a production export you were given for testing.
Credentials and secrets. API keys, tokens, passwords, connection strings, certificates. Including the ones in a config file you pasted "for context".
Unreleased commercial material. Pricing not yet public, contract terms, acquisition plans, roadmaps under embargo.
Anything covered by an agreement you have not read. Client data under an NDA, regulated records, third-party material with licence terms.
Code you are not licensed to share. Vendor source under a restrictive licence, or a client's repository on a contract that forbids it.

Why it matters for you specifically

Because you are the person with the production export on their laptop.

For example, an afternoon of non-functional testing involves an anonymised customer file, a set of environment credentials, and a stack trace containing three real email addresses. Every one of those is useful context for a model, and every one of them is a category above.

There is also a professional angle. Being the person who asks "can this go in a prompt?" before pasting is cheap, and it is remembered. Being the person who caused the incident is remembered too.

What to paste instead

The schema, not the rows. Column names and types get you the same answer as real data.
Fake values that keep the shape. Keep the length, format and edge cases. 4242 4242 4242 4242 rather than a real card, [email protected] rather than a customer.
A redacted log. Strip emails, tokens, identifiers and IP addresses first. A short masking script is worth writing once, and it makes failure triage safe to do with a model.
The error, not the environment. The exception and the relevant frames, not the whole config.
A description of the data, where structure is the question. "A table of 40,000 orders with a nullable discount code column" is usually enough.
Your own words about the business rule. Rather than the contract clause that states it.

If you would not attach it to a public support ticket, it does not belong in a prompt. That test takes two seconds and it is right almost every time.

The three things to check once

Your provider's retention terms. How long inputs are kept and who can see them. Business and enterprise plans usually differ from consumer ones on exactly this point.

Whether your plan trains on inputs. Many do not by default for paid tiers. Know which you are on rather than assuming.

Your own company policy. Some organisations have an approved tool and a banned list. Testers frequently have not been told, because nobody thought about the production export. It belongs in the test strategy beside the data rules.

A worked check

For example, here is the same request prepared badly and then safely.

prompt-hygiene.txt

THE TASK  "help me work out why this checkout request failed"

UNSAFE VERSION (what people actually paste)
  POST /api/checkout
  Authorization: Bearer sk_live_51H8xQ2eZvKYlo2C...      <-- live key
  {
    "customer": { "email": "[email protected]",   <-- real person
                  "address": "14 Mill Lane, Bristol" },  <-- real address
    "card": { "number": "4539 8712 3344 9011" },         <-- real card
    "gift_card": "GIFT-7QK4-2210"
  }
  response 500, stack trace attached (contains 3 more customer emails)

  four categories breached in one paste, and the key is the serious one.

SAFE VERSION (same answer, two minutes to prepare)
  POST /api/checkout
  Authorization: Bearer <redacted>
  {
    "customer": { "email": "[email protected]",
                  "address": "1 Test Street, Testville" },
    "card": { "number": "4242 4242 4242 4242" },
    "gift_card": "GIFT-TEST-0001"
  }
  response 500. relevant frames only:
    at applyGiftCard (src/checkout/gift-card.ts:64)
    at processCheckout (src/checkout/index.ts:112)
  note: fails only when the order total ends .49 or .99

WHAT THE MODEL NEEDED  the shape, the frames and the pattern.
WHAT IT DID NOT NEED   any of the real values.

IF THE KEY WAS ALREADY PASTED
  rotate it now, tell whoever owns it, and write down what happened.
  a rotated key is an inconvenience. an unrotated one is an incident.

The last block matters more than the rest. If a key has already gone into a prompt, rotation is the fix, and the mistake is only serious if it stays unreported.

How to show you know it

A masking script. Twenty lines that strip emails, tokens and identifiers from a log before you share it. Small, reusable, and it makes safe behaviour the easy path.
The two-second test. Saying "I would not put this in a public ticket, so I redacted it" in front of colleagues sets a norm.
A rotated key. Handling your own mistake openly is a stronger signal than never making one.
A question in a team meeting. "Which tool are we approved to use, and does it retain our inputs?" Nobody expects the tester to ask, and everybody benefits.

Questions

Our data is anonymised. Is that fine?

Check how it was anonymised. Removing a name while keeping an email, a postcode and an order history often leaves people identifiable. Anonymised is a claim, not a property.

What about pasting our own source code?

Usually acceptable for code your company owns, subject to policy. Not acceptable for vendor code under a restrictive licence or a client repository under contract. When unsure, paste the shape rather than the file.

Does using an approved enterprise tool remove the problem?

It reduces it, and the categories still apply. Retention, logging and access inside your own organisation are all still real, and customer data does not become fine to spread because the tool is approved.

Is a screenshot safer than text?

No, and it is often worse, because people check text and rarely check what else is on screen. Crop before sharing, and treat an image as the untrusted content it is when it goes the other way too.