System prompt leakage, OWASP LLM07, is the risk that the instructions steering a model contain sensitive details that attackers can extract and use. OWASP's key point: the prompt should not be treated as a secret or as a security control. The fix is to keep credentials out of prompts and enforce rules outside the model.
What does LLM07 actually say?
OWASP defines the risk this way: the system prompt may contain information that was never meant to be exposed, which attackers then use to mount further attacks. It stresses that the problem is not the prompt text itself but the sensitive things inside it and the controls that depend on it. In its words, the system prompt "should not be considered a secret, nor should it be used as a security control."
OWASP lists four common kinds of exposure: sensitive functionality such as architecture details or keys, internal rules such as limits, filtering criteria, and permission or role structures. Each gives an attacker a map.
Scenario one: credentials in the prompt
OWASP's first example is a prompt that contains credentials for a tool the model can use. If the prompt leaks, the attacker reuses those credentials somewhere else.
Picture a support assistant whose prompt includes a database connection string so it can "look up orders." The assistant never needs to show the string to anyone, so the developers felt safe. But a prompt is just text the model has seen, and models can be coaxed to repeat text. The connection string now lives in a place the team cannot audit.
What fixes it: nothing about wording. Move the credential to a service the model calls through a narrow tool. The tool holds the secret, checks who is asking, and returns only the order data that user may see. A leaked prompt then reveals a tool name, not a key.
Scenario two: rules that were only prompt text
OWASP's second example is a prompt that bans offensive content, external links and code execution. An attacker extracts the prompt, learns the rules, and then uses prompt injection to override them and achieve remote code execution.
The leak did not cause the harm alone. The harm came because the rule existed only as an instruction to the model. A model that is told "never run code" while connected to a code-running tool is relying on politeness.
What fixes it: remove the capability, or put a deterministic check in front of it. If the assistant must not execute code, do not connect an executor. If it may run limited code, run it in a sandbox with allow lists the model cannot edit.
What controls does OWASP recommend?
OWASP's prevention list has four parts:
- Keep sensitive data out of prompts: API keys, credentials, database names, roles and permission structures belong in systems the model cannot directly access.
- Do not rely on prompts for strict behavior control, because prompt injection can alter them.
- Add external guardrails: an independent system that inspects outputs, since trained-in behavior such as not revealing a prompt is not guaranteed.
- Enforce security controls outside the model: privilege separation and authorization checks should be deterministic and auditable. For tasks needing different access levels, use multiple agents, each with minimum privileges.
Does hiding the prompt still help?
A little. Hiding a prompt raises the cost of a casual probe. But treat it as a courtesy, not a defense. If learning your prompt would hurt you, the prompt holds too much.
OWASP also points to public collections of leaked prompts from commercial assistants in its references. We have not examined those collections, and we are not repeating their contents. The takeaway is that extraction of prompts has been done often enough for people to catalogue it.
How do you check your own app?
Review each prompt like a config file that will be published. Read it line by line and ask: what happens if a stranger reads this? Remove secrets, role tables and business thresholds. Then list every tool the model can call and ask what each one allows when the model is wrong or manipulated. This is a defensive review, and it needs no attack payloads.
What to do
- Search every system prompt for keys, tokens, hostnames, role names and numeric limits, and move them out.
- Put credentials behind tools that authorize the caller on every request.
- Replace "the model must not" rules with controls outside the model.
- Log tool calls so you can see misuse even if the prompt leaked.
- Add a prompt review to your release checklist.
Quick check
Is the system prompt a secret?
OWASP says it should not be considered one, and should not be used as a security control.
Where should an API key live instead?
In a system the model cannot directly read, such as a tool or service that authenticates and authorizes each request.
Sources
Last reviewed: 18 October 2026.
