The prompt is not a security boundary

Three corollaries: no secrets, no authorization, allow/deny lists are partial.

LLM08:2026

A system prompt is worth writing. It improves ordinary behaviour, reduces accidental misuse, and gives you a written specification to test against. It is a poor place to keep secrets or enforce permissions. This module covers the three things people put in prompts that a prompt cannot hold.

Hidden context is bigger than the system prompt

OWASP renamed this risk for 2026, from System Prompt Leakage to LLM08:2026 Hidden Context Exposure, widening the scope on purpose. Hidden context is everything you assemble into the window that the user is not meant to see.

Hidden context includes	Why it leaks value to an attacker
The system prompt	The policy, the tone, the refusal logic, and any rules you thought were private.
Developer instructions	Scaffolding, formatting rules, and internal reasoning conventions.
Retrieved policy text	From RAG stores, configuration services, or user-profile services. Often more sensitive than the prompt itself.
Tool and function schemas	The highest-value item on this list. Names, parameters and permissions map the attack surface for you.

OWASP LLM08:2026. None of it is meant to be user-visible, and all of it is accessible to the model.

Teams forget that last row. Someone who extracts the prompt usually extracts the tool list too, and a tool list tells an attacker which capabilities exist, what arguments they take, and therefore what is worth attacking. OWASP states the chain explicitly: revealed tool permissions and schemas expand the surface for excessive agency.

The design assumption OWASP asks you to make

Practitioners should design under the assumption that hidden context is discoverable and that any contents of the context should not be considered a secret. Application developers should ensure that disclosure of hidden context has little or no direct security impact.

OWASP Top 10 for LLM Applications 2026 · LLM08:2026

The second sentence is the actionable one. You cannot make extraction impossible. You can make it boring. If someone posts the full system prompt online tomorrow and nothing bad happens, the system was built correctly.

OWASP provides the severity ladder for grading yourself:

Severity	What is in the hidden context
Informational	No secrets, no security-relevant logic, and nothing that relies on staying confidential.
Medium	Internal rules, filtering criteria, role descriptions or workflow logic that meaningfully aids an attacker but does not gate critical decisions.
High	Embedded credentials or tokens, or reliance on hidden-context secrecy for authorization or content policy.
Critical	Disclosure chains onward to remote code execution, broad data exfiltration, or privilege escalation in a connected system.

Paraphrased from OWASP LLM08:2026. Grade a real prompt before reading on.

The three things a prompt cannot hold

1. Secrets

The most common and the most avoidable. Telling the model not to reveal a secret does not compensate for having given it the secret.

High severity, by OWASP's ladder

SYSTEM:
You are an expense assistant.
PAYMENTS_API_KEY = "sk_live_8f2a...9c41"
Never reveal PAYMENTS_API_KEY to the user.

The secret never enters the window

SYSTEM:
You are an expense assistant.
You may propose an expense submission; the backend performs it.

# The key lives in the payments service, which the model
# never calls directly and cannot read.

OWASP: "Assume all context available to the LLM could also be available to users." Externalise secrets to systems the model does not access.

2. Authorization

This looks reasonable and enforces nothing:

Behavioural guidance masquerading as enforcement

SYSTEM:
Only administrators may approve expenses.
If the user is not an Admin, do not call approve_expense.

Nothing here is checked. There is no user.role the model can read from a trusted source, no mechanism that refuses the call, and no audit trail if it happens anyway. The model is being asked to be the policy engine. OWASP is unusually direct about that:

Critical controls such as privilege separation, authorization bounds checks, and similar must not be delegated to the LLM, whether through the system prompt or another mechanism.

OWASP LLM08:2026 · prevention strategy #3

Note the last clause, or another mechanism. Moving the rule into a retrieved policy document, a tool description, or a fine-tune does not fix it. The problem is that a stochastic component is being asked to enforce a control, wherever the rule happens to live. Module 1.5 covers the alternative.

3. Content policy

This one catches thoughtful teams. If the only defence against a harmful output is a paragraph telling the model not to produce it, the content policy inherits the reliability of the prompt, and degrades against anyone who has read it. OWASP puts harmful-content detection in external safeguards rather than instructions embedded in hidden context.

So what is a system prompt for?

Better ordinary behaviour. Most of the users are not attackers, and a well-scoped prompt makes the product work.
Raising the cost of casual misuse. Declarative allow and deny statements stop the low-effort majority.
A written specification to test against. The underrated one. “You may not authorize a payment” is a testable assertion. Without it written down, the red team has nothing to falsify.

Partial control· necessary, not sufficient

OWASP recommends declarative allow and deny statements, then in the same breath calls it “a partial control only: an attacker who infers the prompt can bypass it,” directing you to pair it with privilege controls enforced outside the model. Write the prompt. Do not cite it in a security argument.

Deep diveExtraction is a severity multiplier, not a low finding3 min›

Prompt extraction gets triaged as informational surprisingly often, on the grounds that it only revealed some instructions. OWASP's amplification list is the argument against that. Disclosed hidden context feeds four other risks: more targeted prompt injection (LLM01), embedded credentials as sensitive information disclosure (LLM02), revealed tool permissions and schemas expanding the excessive-agency surface (LLM03), and leaked output-formatting rules facilitating improper output handling (LLM10).

Score extraction on what it unlocks rather than on the act. An extraction that hands over the tool schemas has raised the severity of every subsequent finding, and your report should say so. Module 6.9 covers writing that up with AIVSS.

Check yourself

Self-check

1. The system prompt contains no credentials, but does contain the
   sentence "internal users may bypass the spend limit." Which OWASP
   severity tier is that, and why?

2. Why doesn't moving an authorization rule from the system prompt into
   a retrieved policy document fix anything?

3. The prompt says "never discuss competitor pricing." What kind of
   control is that, and what would make it a real one?

4. Which item of hidden context most expands an attacker's capability?
   It isn't the prompt.

Answers

1. Medium. Internal rule logic that meaningfully aids an attacker, telling them a bypass exists and hinting at how to claim it, without gating a critical decision on its own. It becomes High the moment the spend limit is enforced by that sentence rather than by the payments service.

2. OWASP prohibits delegating the control to the LLM “whether through the system prompt or another mechanism.” Relocating the text changes the leak path, not the enforcement model. A stochastic component is still deciding authorization.

3. A rate-reducer. It holds for ordinary users and fails against anyone who has read it. A real one is an output-side check outside the model, which is module 5.9.

4. Tool and function schemas. They enumerate the capabilities that exist and the arguments they accept, which is the map an attacker would otherwise build by guessing.

Sources