A leaked system prompt is not an embarrassment, it is a map — tool names, argument shapes, role names and refusal conditions, which together mark the edges worth probing. Why it cannot be kept secret, and how to make the leak boring instead.
It cannot be kept, and that is not a defect
A system prompt is text in the same stream as everything else the model reads.
There is no field marking it privileged, no separate channel, no mechanism that could refuse to reproduce it. Every instruction to keep it secret is more text, competing with other text, and winning most of the time rather than always.
Most of the time is a property you can measure. It is not a property you can build on.
What the map is worth
Not the wording. The structure.
Tool names and argument shapes. The difference between guessing that a system can send email and knowing the function is called with a recipient, a subject and a body.
Role names. What privileges exist, which implies which are worth acquiring.
Refusal conditions. The most useful item on the list, because a stated boundary tells you precisely where to push. Never discuss pricing tells an attacker there is pricing logic and roughly where it sits.
The ordering. Which instruction the author put first is a reasonable proxy for which they were most worried about.
A prompt is written to be unambiguous to a model. That same quality makes it unambiguous to whoever reads it next.
The credential in the prompt
Worth its own section because it keeps happening.
A key placed in a prompt is a key placed in a document that anybody conversing with the system may eventually read. Not might — may, given enough attempts, because the mechanism keeping it is probabilistic.
It is also the failure with the largest blast radius on this list, and the one that takes the least effort to avoid. A prompt should not contain anything that a screenshot of it would compromise.
Obfuscation buys time, not safety
Encoding it, splitting it, wrapping it in warnings, instructing the model to deny having one — each raises the effort required and none changes the category.
These measures are priced correctly against a curious user and incorrectly against somebody who intends to get it. The distinction matters because the second group is the one you were defending against.
A defence that works against people who were not really trying is a defence with no threat model behind it.
Make the leak boring
The position that actually holds: assume the prompt is public, and arrange things so that being right about that costs nothing.
Keep authority in the permissions. What the system may do should be enforced by what it is allowed to call, not by a sentence asking it not to. A leaked prompt then discloses intent, and intent is not authority.
Keep secrets in a secret store, injected at the point of use, never in the context.
Let the refusal conditions be public. If a rule cannot survive being known, it was not a rule — it was an obstacle, and obstacles are for people who are not looking.
Write it as though it will be read. This has a side effect worth having: prompts written for an audience tend to be clearer, and clearer prompts behave better.
Close
The question is not whether your system prompt will leak.
It is what somebody learns when it does, and whether that list is short enough to shrug at.