OWASP LLM07 is system prompt leakage. OWASP's position is that a system prompt should never be treated as a secret or as a security control, so credentials and permission logic must not live in it. For compliance, that turns the risk into secrets management, access control and testing evidence, not a prompt-wording problem.
This post reads the OWASP entry, then maps it to the NIST AI Risk Management Framework. The mapping is our interpretation. OWASP's page links only to MITRE ATLAS technique AML.T0051.000, so there is no official OWASP crosswalk to cite.
What does OWASP actually say?
The LLM07:2025 page makes four points worth quoting in your own risk register:
- The system prompt should not be considered a secret, nor used as a security control.
- Sensitive data such as credentials and connection strings should not be in the prompt.
- Disclosure of the prompt text is not the real risk. The risk is the underlying issue: sensitive information, guardrail bypass, or authorization delegated to the model.
- Strict controls such as privilege separation and authorization checks must be enforced outside the LLM, in a deterministic and auditable way.
OWASP lists four common risk patterns: exposed sensitive functionality, exposed internal rules, revealed filtering criteria, and disclosed permissions and roles. In its example scenarios, a prompt containing tool credentials leaks, or a prompt that forbids certain behavior is extracted and then bypassed with a prompt injection.
How does this map to NIST AI RMF?
The AI RMF 1.0 is voluntary and organizes practices under Govern, Map, Measure and Manage. These are the subcategories we think an assessor would reach for, quoted from the framework:
- MEASURE 2.7: "AI system security and resilience, as identified in the MAP function, are evaluated and documented." Your prompt leakage tests and results belong here.
- GOVERN 1.6: mechanisms to inventory AI systems. You cannot review prompts for systems nobody listed.
- MAP 4.1: approaches to map risks of components, including third-party software, are documented. A prompt that references a vendor tool credential ties to this.
- GOVERN 6.1: policies address AI risks from third-party entities. Relevant if a hosted model provider sees your prompt.
- MANAGE 3.1: third-party risks are monitored and risk controls documented.
NIST's page also notes the AI RMF 1.0 is being revised, so recheck the numbering when a new version lands. This post does not map to ISO/IEC 42001 or SOC 2 criteria because we did not review those texts for this article. Ask your auditor how they want it framed.
What evidence should you keep?
- A prompt inventory. Each system prompt, where it is stored, who can edit it, and which application uses it.
- A secrets scan result for the prompt repositories. If a key appears in a prompt file, that is a finding regardless of whether the model ever repeats it.
- A statement of where authorization is enforced. The answer should name a service or code path, never "the prompt tells the model not to."
- Leakage test records. Date, tester, method in general terms, and result. Keep payload details out of broadly shared reports.
- Output guardrails. OWASP recommends an independent system that inspects output rather than relying on the prompt's own instructions.
- Change history. Prompt edits are code changes. Use review and version control.
How do you check for secrets in prompt files?
Prompts live in repositories, config files and environment settings, so ordinary secrets scanning covers a lot of ground. With the Safeguard CLI, the detect command looks for secrets and misconfigurations in a directory:
safeguard detect --detect secrets --format sarif --output detect.sarif
The CLI docs say values are redacted in the output by default and that the SARIF file can be uploaded to a code-scanning tab. Any secrets scanner with history scanning does the same job. Remember to scan Git history too, since a removed key remains in old commits until rotated.
Where does this approach fall short?
Removing secrets from prompts does not stop a model from revealing the behavior rules it was given. OWASP says as much: attackers using an application can usually infer many guardrails from behavior. So the question to ask is whether those rules matter. If a leaked rule lets someone get around a control, the control was in the wrong place.
What to do
- Inventory every system prompt and its owner.
- Scan prompt files and history for credentials, and rotate anything found.
- Move authorization and limits into code that does not depend on model output.
- Add an independent output check for sensitive strings and policy violations.
- Record leakage tests under your MEASURE 2.7 evidence.
- Review prompt changes like code changes.
Quick check
Is a leaked system prompt a vulnerability by itself?
OWASP says disclosure of the prompt is not the main risk. The risk is what the prompt contains or what controls depend on it, such as credentials or authorization logic.
Which NIST AI RMF subcategory covers prompt leakage testing?
MEASURE 2.7, on evaluating and documenting security and resilience, is the closest fit. That is our reading, not an official crosswalk.
Sources
- OWASP LLM07:2025 System Prompt Leakage
- NIST AI Risk Management Framework
- NIST AI RMF 1.0 (AI 100-1)
- Safeguard CLI usage
Last reviewed: 18 October 2026.
