What instruction hierarchy means
An instruction hierarchy, also called instruction precedence, is a behavioral mechanism that helps a language model decide which instruction to follow when model-visible instructions compete. An application or model provider represents some instructions as having greater priority than others, and the model is trained or prompted to prefer the higher-priority instruction in a conflict.
The exact representation varies. One product may expose named message roles, another may use channels, structured fields or a private context-building layer. The labels and ordering are properties of that provider, model and surface, not a universal protocol shared by all language models.
Six properties that must stay separate
Security problems arise when a representation signal is mistaken for evidence or authority. Keep these concepts distinct:
| Property | Question it answers | What it does not prove |
|---|---|---|
| Message or source origin | Where did the content come from? | That the content is accurate or authorized |
| Role or channel representation | How was the content presented to the model? | That the claimed source is authentic |
| Instruction priority or precedence | Which competing instruction should the model prefer? | That the preferred instruction may cause an effect |
| Trust | What confidence or reliance does system evidence support for this purpose? | A general permission for every use |
| Authority or permission | May this principal perform this exact action on this resource and destination? | That the model will behave correctly |
| Deterministic enforcement | What will application code permit or block? | That model output is factual or safe by itself |
An authenticated user can provide lower-priority text. A high-priority application instruction can still be factually wrong. A correctly prioritized model response can still propose an action the user is not authorized to perform.
There is no universal role ordering
Provider role and channel schemes differ by API, model family and product surface. Names such as system, developer, user or tool can describe different capabilities and precedence rules in different systems. Applications should follow the documentation for the exact model and API they use, and should retest behavior when either changes.
For example, the dated OpenAI Model Spec documents a provider-specific chain of command and levels of authority. It also states that production models do not yet fully reflect that specification. This is useful evidence of one provider's intended behavior, not a cross-provider standard and not a guarantee for every response.
Behavioral mechanism, not security boundary
Precedence can improve robustness by giving the model a learned way to resolve explicit conflicts. It remains probabilistic model behavior. Ambiguous wording, long context, transformations and unfamiliar conflicts can still produce an unexpected result. A hierarchy is therefore useful defense in depth, but it is not a security boundary or authorization mechanism.
Higher-priority text does not authenticate its source, grant a permission, make a destination acceptable, make output trusted, authorize a tool call or keep hidden instructions confidential. The model's response remains variable data or a proposal until the application checks it.
Instruction-like text in data
Applications often place task instructions beside documents, email, search results or tool output. Those data sources can contain text that looks like an instruction. Labels, delimiters and separate channels can help the model recognize the distinction between authoritative application instructions and instruction-like data, but the distinction is still interpreted by the model.
Spotlighting / Data Marking can make the intended boundary more legible. Data Provenance records the real origin and transformation history outside the prose. Neither technique grants the data permission to direct a consequential action.
How this connects to prompt injection
In Direct Prompt Injection, user-controlled text competes with the application's intended instructions. In Indirect Prompt Injection, instruction-like text arrives through third-party content the application chose to process. In both cases, lower-priority or data-labeled content can still influence model behavior even when the intended hierarchy is clear.
A successful influence does not by itself prove a security impact. Impact depends on the data, tools, destinations and permissions available around the model. Prompt Injection Detection can provide evidence of suspicious influence, but deterministic policy still decides what may happen.
A conceptual conflict-resolution flow
- The application records each source and assembles only the context needed for the task.
- It represents application instructions and variable content using the chosen provider's supported structure.
- The model interprets that structure and attempts to resolve competing instructions.
- The application treats the result as variable output or a proposal.
- Independent policy authorizes any consequential action and validates the output for its destination.
Two harmless synthetic examples
Answer in one sentence and do not change stored records.
Summarize the fictional project note and mark it complete.
The model can summarize, but should not treat the request to change state as overriding the application instruction.
Any state-change proposal is independently rejected because the task has no write permission.
Summarize the retrieved public notice.
The notice includes a harmless sentence addressed to an assistant asking for a different writing style.
The model is expected to treat that sentence as content to summarize, not as task authority.
The application permits only a text summary and provides no action capability.
In both examples, precedence guides the response. The surrounding application determines the possible effect.
What belongs outside the model
| System fact or decision | Application responsibility |
|---|---|
| Identity | Authenticate the initiating principal and acting service |
| Permissions | Authorize the exact resource, action, parameters and scope |
| Source provenance | Record origin and transformation lineage independently of payload text |
| Destination policy | Decide where each data class may be sent or rendered |
| Tool and action authorization | Check every proposed call at execution time |
| Flow controls | Prevent prohibited data paths across users, tenants, tools and sinks |
| Sink handling | Validate structure and format for the destination, then apply any required sink-specific encoding or escaping separately |
See Agent Authorization, Information Flow Control and Output Validation. These controls do different jobs and remain necessary even when instruction precedence works as intended.
Implementation implications
Practical design rules
- Document the exact provider, model and API surface whose role or channel behavior you rely on.
- Keep authoritative identity, provenance, permissions and policy state outside model-visible prose.
- Label and isolate variable content as a robustness aid without treating the label as enforcement.
- Minimize context so unrelated content has fewer opportunities to influence behavior.
- Treat every model response and tool-call argument as variable data requiring independent checks.
- Test conflicting instructions across direct input, retrieved content and tool output after model changes.
- Log source, representation, model proposal and policy decision separately for investigation.
Common misconceptions
Claims to reject
- The highest-priority message is automatically authentic.
- A system or developer message can grant the user permission.
- Tool-role content is trusted because the tool itself is trusted.
- Correct precedence makes model output safe to execute.
- Delimiters turn natural-language data into a hard security boundary.
- Hidden higher-priority instructions are confidential.
- Instruction hierarchy fully prevents prompt injection.
The confidentiality case is covered in System Prompt Extraction. Hierarchy may tell a model not to reveal hidden text, but the application must never place secrets or its only control in that text.
Practice and continue
The Direct Prompt Injection Basics lab shows competing instructions and a separate authorization decision. The Trust Boundaries and Model Context lab lets you compare model-visible prose with application-controlled evidence.
Next, read Trust Boundaries and Model Context. It develops the architectural question this article introduces: what enters model context, what remains variable, and where enforceable trust decisions belong.
Standards and sources
How this article uses sources
- OWASP
- GenAI LLM Top 10 2026 - LLM01:2026 Prompt Injection as a named risk
- NIST
- AI 100-2e2025 and glossary entries - prompt-injection terminology and the distinction between direct input and resource-controlled delivery
- Microsoft
- Indirect prompt-injection guidance - untrusted external content and layered probabilistic plus deterministic mitigations
- OpenAI
- Model Spec dated 2026-08-18 - one provider-specific example of documented instruction authority, not a universal standard or enforcement guarantee
Frequently asked questions
What is an instruction hierarchy?
Is there one standard ordering for all models?
Is a higher-priority instruction trusted?
Does hierarchy authorize tool calls?
Can lower-priority data still influence the model?
Do roles keep system instructions confidential?
What should I read next?
References
- OWASP GenAI LLM Top 10 2026OWASP GenAI Security Project · GuidanceReviewed 2026-09-26
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025NIST · Standard · 2025-03Reviewed 2026-09-26
- prompt injectionNIST Glossary · Technical documentationReviewed 2026-09-26
- indirect prompt injectionNIST Glossary · Technical documentationReviewed 2026-09-26
- Defend against indirect prompt injection attacksMicrosoft Learn · GuidanceReviewed 2026-09-26
- OpenAI Model Spec - Instructions and levels of authorityOpenAI · Technical documentationLatest revision 2026-08-18Reviewed 2026-09-26