Notifications
Clear all
Topic starter
02/08/2026 9:41 am
TL;DR: System prompt leakage exposes credentials, architecture details, and business rules when developers place sensitive information inside LLM instructions, creating disclosure and privilege risks that prompt injection can exploit, according to StackHawk. The security failure is architectural: prompts are not a safe control plane, so hidden assumptions about secrecy and authorization collapse under adversarial testing.
NHIMG editorial — based on content published by StackHawk: Understanding and Protecting Against LLM07, System Prompt Leakage
Questions worth separating out
Q: What breaks when teams treat system prompts as a secure place for secrets?
A: They turn a behavioural layer into a hidden repository for credentials, roles, and business logic.
Q: Why do system prompts complicate identity and access control decisions?
A: Because prompts can reveal or imitate the logic that defines who can do what, including override conditions and role boundaries.
Q: How do security teams know if prompt leakage controls are actually working?
A: They should test whether the model can be induced to reveal instructions, credentials, or internal rules, and whether those items are present in prompts at all.
Practitioner guidance
- Separate secrets from prompts Remove API keys, tokens, connection strings, and override codes from system prompts and store them in external secrets management with server-side retrieval only.
- Enforce authorisation outside the model Route role checks, transaction approvals, and content moderation decisions through application logic or IAM policy, not model instructions that can be elicited or leaked.
- Test prompts for disclosure paths Add adversarial tests that ask the model to repeat instructions, reveal configuration, or restate hidden rules, then block any prompt text that contains sensitive material.
What's in the full article
StackHawk's full blog post covers the operational detail this post intentionally leaves for the source:
- Concrete examples of system prompt leakage scenarios across customer service, banking, moderation, and healthcare workflows
- The article's step-by-step mitigation guidance for separating secrets, business logic, and model instructions
- Testing considerations for LLM injection findings and prompt disclosure checks inside application security pipelines
- StackHawk's discussion of how its LLM security testing maps to OWASP LLM risks
👉 Read StackHawk's analysis of LLM07 system prompt leakage and AI secrets exposure →
System prompt leakage in LLM apps: are your controls keeping up?
Explore further
02/08/2026 12:35 pm
System prompt leakage is really a trust-boundary failure. The mistake is not only placing sensitive content in a prompt. The deeper failure is assuming the model can safely store and protect information that should live in secrets management, policy engines, or application code. Once the prompt becomes a substitute control plane, disclosure risk becomes an access risk, and practitioners should treat that boundary as broken.
A question worth separating out:
Q: How can organisations reduce risk when deploying AI assistants with sensitive data access?
A: Organisations should narrow the data the assistant can see, validate the data it returns, and log every blocked or corrected response. For higher-risk use cases, the assistant should also follow a constrained conversation path so it cannot drift into unsafe states or disclosure patterns.
👉 Read our full editorial: System prompt leakage exposes the hidden trust gap in LLM apps
