OWASP's advice on system prompt leakage (LLM07:2025) is to assume the prompt can be read and design so that it does not matter. The page states that the system prompt should not be considered a secret, nor used as a security control. Move secrets out and enforce rules outside the model.
What is the real risk?
OWASP is clear that the prompt text itself is rarely the danger. The risk is what the prompt reveals about weaknesses elsewhere: sensitive information disclosure, guardrail bypass and improper separation of privileges. Its examples of what leaks:
- Functionality: system architecture, API keys, database credentials or user tokens
- Internal rules: decision logic, limits and thresholds an attacker could use to get around controls
- Filtering criteria: what the model is told to screen out, which shows what to dodge
- Permissions and roles: role structures that help with privilege escalation
If an attacker reads a prompt and finds nothing that helps, the leak is an embarrassment. If they find a database name and an admin token, it is an incident.
What should engineering leads check?
Work through this list per application. Each line is a question to answer yes or no.
Content of the prompt
- Has someone read every system prompt in production, line by line, looking for credentials, hostnames, connection strings and internal URLs?
- Do prompts avoid listing user roles and permission levels?
- Do prompts avoid stating numeric limits that act as controls, such as maximum refund amounts?
Where rules actually live
- Are access checks done by code outside the model, deterministically, on every request?
- If the model is told "never do X," is there also a check that blocks X when the model gets it wrong?
- Do agents with different access levels run as separate agents, each with least privilege?
Output controls
- Is there an independent check on model output, since training a model not to reveal its prompt does not guarantee it will comply?
- Do you log refusals and suspicious outputs so you can see attempts?
Operations
- Do prompts live in version control with review, so a secret cannot slip in unnoticed?
- Does your secret scanning cover prompt files and configuration for LLM applications?
- Does your incident runbook say what to rotate if a prompt leaks?
How do you test it defensively?
Run a review with your own team. Ask a colleague to try to get the model to describe its instructions, then ask a different question: if they succeed, what do they learn that is useful? Record the answer. If the answer is "nothing sensitive," the design is working. If not, remove that content from the prompt and add the missing control in code.
Do this after every prompt change, as part of review. You do not need exotic tooling, only a repeatable list of questions and a place to record results.
Where do tools help?
Secrets scanning can catch an API key pasted into a prompt file before it ships. Safeguard's secrets scanning works on repositories and in the IDE, and the CLI runs locally. A scanner will not know that a role list in a prompt is sensitive, so the human review above still matters.
What to do
- Inventory every system prompt and its owner.
- Remove credentials, hostnames and role tables from prompts.
- Move every limit and permission check into code outside the model.
- Add independent output checks for sensitive categories.
- Put prompts in version control with review and secrets scanning.
- Repeat the "what would an attacker learn" review after each prompt change.
Quick check
Is it safe to keep an API key in the system prompt if I tell the model not to reveal it?
No. OWASP says to keep credentials out of system prompts and store them in systems the model cannot directly access.
Does LLM07 mean the prompt must be hidden?
No. It means you should not depend on it being hidden. Design so that reading the prompt gives an attacker nothing useful.
Sources
Last reviewed: 18 October 2026.
