Can we stop it happening?

You can make it harder and you cannot make it impossible, because restating text is what the system is for. Direct requests are refused by most products, and indirect routes through translation or summary persist, so the sound plan is to write instructions you would not mind seeing published rather than to rely on the refusal holding.

What should never go in there?

Anything you would not put on a public page. Credentials, internal system names, unannounced commercial rules and anything describing how different customers are treated all belong somewhere access-controlled, reached through a step that checks who is asking. Behaviour belongs in the instructions; secrets belong behind a permission check.

How would we even know it had happened?

Usually you would not, which is part of why the writing rule beats the technical control. There is no alert and nothing obviously changes; somebody simply has your wording. That silence is why the sensible posture is to assume the text is readable from the day it is written rather than to watch for a moment of exposure.

Glossary

Prompt leakage

Prompt leakage is a system repeating back the private instructions it was configured with, which matters far less for the wording exposed than for whatever was unwisely written into it.

In plain terms

It repeats back the private instructions it was set up with. Somebody asks the right question and out comes the wording somebody wrote assuming nobody would ever see it. The exposure of that text is usually a mild embarrassment. What turns it into a real problem is when the text contained something that should never have been there.

Why it matters

Because teams routinely write things into setup instructions that they would never publish, on the assumption that the instructions are private. They are not private in any enforceable sense, so the assumption is the vulnerability rather than any particular technique for extracting them. Treating that text as publishable from the outset removes the whole category of problem.

How it works

The instructions and the conversation reach the system as the same kind of material, which is the root of it. Configuration text is not held in a protected compartment; it is supplied alongside everything else to something built to reproduce, summarise and translate whatever it is given. Asking it to restate its instructions is a request it is unusually well suited to fulfilling.

Extraction rarely needs anything clever, and defences mostly raise the effort rather than removing the possibility. Direct requests are refused by most products now, and indirect routes such as asking for a translation, a summary or a restatement in another form frequently succeed, because those are ordinary capabilities being used ordinarily. Each patched route tends to be replaced by another.

The cost is almost never the wording itself. Competitors learning how a feature is phrased is a minor loss, and the genuine damage comes from what got embedded alongside it: a credential, an internal system name, an unannounced pricing rule, a description of which customers get different treatment. Those are the leaks that matter, and none of them needed to be there.

The remedy is a writing rule rather than a technical control. Instructions should contain behaviour and nothing that would be damaging in public, with anything sensitive held where it can be protected properly and reached through a step that checks permissions. Written that way, a leak becomes uninteresting rather than defended against.

Two kinds of thing found in setup instructions

The useful way to think about this is that a leak does not create the risk, it reveals a decision taken weeks earlier by somebody who did not think of the instructions as a document. That is an easy mistake to make, because the text does not feel like a published artefact: it lives in a settings panel, it is edited quickly, it is written in the second person to a machine. None of those cues say be careful, this is going out. So a rule about pricing gets pasted in to save a lookup, an internal hostname appears because it made a step work, and a credential arrives because it was the fastest way past a blocker on a Friday. Every one of those is discoverable by anybody patient enough. Teams that never have this problem are not the ones with the best refusals; they are the ones who decided early that the instruction text is public, and put everything else behind a check that asks who is calling.

Seen in the wild

An assistant offering saved configurations with their own instructions and files, shared across a team, where the wording is set once by whoever built it.
ChatGPT
A workspace where dedicated projects hold instructions and reference material for a client or workstream, so the setup text is reused across many conversations.
Claude
A platform where each agent is described in plain language with the rules it must follow set at build time rather than per request.
Lindy

Common misconceptions

People assume

A well-defended product keeps its instructions private.

In fact

It raises the effort, which is not the same commitment. Direct requests are refused almost everywhere now and indirect routes through translation, summary or restatement keep working, because those are the product doing its job. Plan for the text being readable rather than for the defence holding.

People assume

The damage is competitors seeing our wording.

In fact

That is the smallest part of it and usually survivable. The expensive leaks are the things written alongside the behaviour: a key, an internal endpoint, a rule about which customers are treated differently. Those were never safe there, and the exposure merely revealed a decision made much earlier.

Telling them apart

Prompt leakage vs Prompt injection

Prompt leakage

Getting the instructions out.

Prompt injection

Getting new instructions in.

One reads what you configured and the other overrides it, so the first costs you a secret and the second costs you control of what happens next.

Questions

Can we stop it happening?: You can make it harder and you cannot make it impossible, because restating text is what the system is for. Direct requests are refused by most products, and indirect routes through translation or summary persist, so the sound plan is to write instructions you would not mind seeing published rather than to rely on the refusal holding.
What should never go in there?: Anything you would not put on a public page. Credentials, internal system names, unannounced commercial rules and anything describing how different customers are treated all belong somewhere access-controlled, reached through a step that checks who is asking. Behaviour belongs in the instructions; secrets belong behind a permission check.
How would we even know it had happened?: Usually you would not, which is part of why the writing rule beats the technical control. There is no alert and nothing obviously changes; somebody simply has your wording. That silence is why the sensible posture is to assume the text is readable from the day it is written rather than to watch for a moment of exposure.