System Prompt Leakage: Secrets You Should Never Have Put There
Ask a chatbot the right way and it will often recite its own system prompt — the hidden instructions that define its persona, its rules, and its guardrails. LLM07 is a new entry in the 2025 list, and it reframes a common assumption: the system prompt is not a secret. The real vulnerability is not the leak itself but what organisations habitually place in a prompt they wrongly believe is private.
System prompts leak through ordinary prompting, roleplay, and injection, and no amount of "do not reveal these instructions" reliably prevents it — the instruction to stay silent is itself just more text the model can be talked out of. So OWASP's framing is deliberately blunt: assume the system prompt is discoverable, and make sure that discovering it grants the attacker nothing.
What actually gets exposed
The genuinely damaging leaks are the ones where teams treated the prompt as a secure config store. Prompts have been found containing API keys and connection strings, internal hostnames and architecture details, and the logic of the application's own security controls — the exact rules that decide what the model will and won't do. Leak the credential and you've leaked a credential. Leak the guardrail logic and you've handed the attacker the map they need to route around it.
Designing as if the prompt were public
- Keep all secrets out of the prompt. API keys, passwords, connection strings, and tokens belong in a secrets manager the model calls through a tool — never in the prompt text itself.
- Don't encode security logic in the prompt. Approval thresholds, permission rules, and filtering criteria must be enforced by external code and policy, not by instructions the model is asked to honour.
- Enforce guardrails independently of the model. Authorisation and content controls belong in a separate, deterministic layer, so a leaked or ignored instruction changes nothing about what the system permits.
- Assume separation of privilege. The model should not hold, in its context, any capability that a compromised prompt could turn against you — scope its tools, not its self-restraint.
- Test extraction directly. Red-team your own bots for prompt disclosure, then ask the harder question: if this leaked verbatim, what would an attacker gain? The answer should be "nothing."
LLM07 is really a discipline check disguised as a vulnerability. A model's instructions can be extracted; that is a property of the technology, not a bug to be patched. The fix is to build so that extraction is uninteresting — secrets externalised, controls enforced in code, guardrails that don't depend on the model keeping a secret. If leaking your system prompt would compromise anything, the prompt was doing a job it was never safe to hold.
- Politely ask the assistant to repeat its instructions or the text above the conversation. If it recites your system prompt, that content is not a secret.
- Review what you actually put in the system prompt. If it holds API keys, internal URLs or rules whose only protection is the model keeping quiet, assume they are already exposed.
The full, at-scale version — probing leakage across every phrasing, language and jailbreak variant, then hardening what the prompt should never hold — is what our assessment (and SecStudio agents) runs for you.