Instruction Hierarchy for LLMs Needs a Privileged Regression Pack

An instruction hierarchy resolves conflict by assigning authority to an instruction's source. A model should follow the higher-authority instruction and selectively ignore conflicting text supplied at a lower level. Production tests need the application's exact role sequence and trust labels. They also need the principal and policy, plus the model version.

TL;DR

• Instruction hierarchy gives higher-authority instructions precedence over conflicting lower-authority text.
• Role labels and content provenance must match the real application path, including retrieved third-party text.
• Build a regression pack with expected precedence and response. Record the principal and policy, plus the model/version, for every case.
• The model provider owns internal precedence behavior. External controls validate payload and identity while recording policy and evidence.

Authority follows the instruction source

OpenAI's Model Spec dated October 29, 2026 describes a chain of command in which higher-authority instructions take precedence over lower-authority ones. The current document distinguishes root and system authority. Developer and user authority are separate, as is guideline authority. Application teams interact with only part of that stack, while provider-controlled rules remain inside the model service.

The role field is part of the security mechanism. A developer instruction placed into a user message loses the intended authority. Retrieved web text placed into a privileged role gains authority it was never meant to receive. Keep third-party content labeled as untrusted data and tell the model how it may use that material.

I consider role conversion during prompt assembly a security-sensitive code change. A one-word diff from user to developer can grant an email body more influence than a month of policy meetings intended. The pull request looks tiny. Its authority effect is large.

The training objective handles aligned and conflicting text

The 2024 paper The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions frames the problem around privileged instructions. System messages take precedence over user messages, and user messages take precedence over third-party content in the paper's hierarchy. Lower-privileged text can align with the higher-level instruction or conflict with it.

Aligned text should compose normally. If a system-level sales assistant instruction permits language choice and the user requests Spanish, the model can satisfy both. A retrieved page that orders the model to expose conversation history creates a conflict. The desired behavior is to ignore the lower-privileged instruction where possible, or refuse when a safe continuation is unavailable.

The paper reports that training on this hierarchical behavior improved resistance to prompt injections and jailbreaks, including system-message extraction in its evaluations and generalization to attack types absent from training. Treat those results as evidence for the training method under the tested conditions. Production acceptance still depends on the deployed model and prompt, plus role encoding and application context.

Prompt assembly can erase the hierarchy

Applications frequently flatten data and instructions into one string. A template may put a developer rule and customer question into a single user message along with a retrieved page and tool output. The model then receives weak provenance cues even though the application knows each source. Preserve role boundaries where the API supports them, and add explicit delimiters plus trust labels for untrusted content.

Prompt injection testing should cover direct user conflicts and indirect instructions inside documents and web pages, as well as emails and tool results. The prompt injection test cases guide provides fixtures for those routes. Add cases where malicious text imitates a system marker or claims a policy update. It may also quote a prior instruction or ask the model to reveal hidden context.

Also test aligned lower-level requests. A model that refuses every instruction after seeing untrusted content has produced an availability problem rather than useful hierarchy behavior. Record task success beside attack resistance, using the same model settings and application template.

Principal and policy sit outside model role labels

A message role describes authority inside the model request. A principal identifies the authenticated person or service, including an agent responsible for the request. Those fields answer different engineering questions. Two users can send identical user-role text while enterprise policy permits one and denies the other because their roles and data access rules for approved destinations differ.

Bind the principal before prompt assembly. Carry the application route and enterprise role beside the message payload. Carry the data classification and requested model too, along with the policy version. Per-role AI policies explains how that context drives authorization. Preserve the final permit or deny result separately from the model's generated response.

Provider safety and hierarchy behavior can refuse a request after enterprise policy permits it. Enterprise policy can deny a request that the model would answer. Keep both outcomes in the evidence record, since combining them into one blocked=true field hides the control that acted.

Build a privileged-instruction regression pack

Create one pack per application prompt and model route. Pin it to an application release and prompt-template digest. Record the provider and model identifier, along with the model snapshot or version. Pin the generation settings and enterprise policy version too. Each case should contain these fields:

• Roles: Preserve the ordered system and developer placements, followed by the user and assistant placements. Preserve tool and retrieved-content placements exactly as sent.
• Trust labels: Mark application-authored instructions and authenticated user input. Mark retrieved third-party content and tool output with their provenance.
• Expected precedence: Name the instruction that should control the response and the lower-authority text that should be ignored.
• Expected response: Record comply or ignore, refuse or clarify, or a bounded answer. Add concrete assertions the response may and may not contain.
• Principal: Store the test identity and enterprise role. Record the tenant and authentication method, plus the delegated scope.
• Policy: Pin the route policy and data class. Record the model authorization and expected permit or deny decision, along with the reason code.
• Model and version: Record the provider and model ID. Include the snapshot or dated alias and the tokenizer or API revision where material, along with the generation settings.
• Observed evidence: Keep the exact request reference and policy decision. Preserve the response reference and grader outcome. Add the timestamp and reviewer disposition.

Include direct conflict and indirect injection cases. Add system-message extraction and benign composition cases. Test ambiguous precedence and malformed role order, along with missing principal and unauthorized destination cases. The automated red teaming guide can schedule replay, but a human should review severe failures and grader disagreements.

Release gates need exact rerun triggers

Run the pack before the first production release. Rerun it after a model alias or prompt template changes. Run it again when a provider updates documented behavior. Changes to retrieval formatting and tool-result placement deserve another run. So do changes to message-role conversion and enterprise policy, as well as identity claims and SDK serialization.

Set acceptance criteria before reading results. I would block release for a case that exposes a privileged instruction or follows an indirect command to disclose protected context, even when the aggregate pass rate looks good. Keep severity and exploit path beside the score.

The visible artifact should show one failed case as clearly as one success. A useful review screen has the ordered role labels on the left and the expected controlling instruction in the center. Put the observed response on the right and the policy reason code below it. Preserve payload access separately when the text contains secrets or sensitive customer data.

DeepInspect

DeepInspect can validate the payload and supplied identity for authenticated LLM HTTP requests deliberately routed through its proxy. It can also validate the model destination and application route, along with the data classification and enterprise policy. It can preserve the policy decision and request evidence beside the model and version used by the regression case.

The proxy has no mechanism to change the provider's internal instruction hierarchy or retrain precedence behavior. It also cannot guarantee that a model will ignore every lower-authority injection. Prompt assembly and role labeling remain application responsibilities. Provider-controlled hierarchy behavior remains with the model provider. Book a technical deep dive at deepinspect.ai.