Assume anyone can eventually read your system prompt. OWASP says the system prompt is not a secret and should not be used as a security control. So keep credentials, database details, permission structures and exploitable business rules out of it, and enforce them in code.
The checklist
Remove or relocate each of these:
- API keys, tokens and passwords. OWASP's example scenario is a leaked prompt that contained tool credentials, which an attacker then used elsewhere.
- Database names and connection details. They describe your architecture to an attacker.
- Role and permission structures. A prompt that lists roles helps someone attempt privilege escalation.
- Internal decision rules with numbers. OWASP gives transaction and loan limits as an example of logic attackers can use to get around controls.
- Filtering criteria. A list of what the model will refuse tells an attacker what to rephrase.
- Anything you would not put on a public web page.
Where each item belongs instead
- Credentials: move it to A secrets manager, used by application code
- Permission rules: move it to Authorisation checks outside the model
- Business limits: move it to Deterministic validation in the service
- Refusal lists: move it to Output inspection outside the LLM
OWASP's guidance is to enforce access control and privilege separation deterministically outside the model, and to use external guardrails to inspect outputs rather than instructing the model not to reveal its prompt. For tasks that need different access levels, it suggests separate agents, each with the least privileges needed.
What is fine to keep
Tone, scope, role description, formatting rules and refusal behaviour in general terms are reasonable. If a leak would be embarrassing but not exploitable, the prompt is doing its job.
How to test
Ask your own application to repeat its instructions, using several phrasings and a few languages. Then read the result as an attacker would. Any line that hands them a key, a limit or a bypass should be moved. Do the test regularly, because prompts grow over time and secrets creep in during debugging.
Search your prompt repository for strings that look like keys. If you find one, rotate it as well as removing it.
Safeguard's compliance and evidence automation can record that this review happened, which helps when a customer questionnaire asks how prompts are governed.
Common mistakes. The usual path to a secret in a prompt is convenience. Someone pastes a test key to get a demo working, and it ships. Another is encoding business logic as prose because it is faster than writing a validation rule. Both feel harmless until the prompt is extracted. Add a review step to prompt changes that asks one question: would this line hurt us if a stranger read it?
Quick check
If the prompt leaks, is that a vulnerability?
The leak itself is expected eventually. The vulnerability is what the prompt exposes, such as secrets or weak privilege separation.
Sources
Last reviewed: 19 October 2026.
