Modern LLM APIs structure input into distinct roles. Each role represents a different source of instructions with different levels of trust and different purposes.
System prompt — instructions from the developer that define the model's behavior, identity, and constraints for the entire session
User prompt — input from the end user; the message the user types in their turn of the conversation
Assistant turn (developer-seeded) — pre-written model responses inserted into conversation history by the developer to establish context, examples, or state before the real conversation begins
The system prompt is the developer's layer. It is written once and shapes every interaction in the session. It is the authoritative source of the model's purpose, rules, and constraints.
The system prompt is set by the developer who controls and is responsible for the application. The model treats it as the authoritative definition of its purpose. Unlike user input, the system prompt is not exposed to or modifiable by end users — by design.
The user prompt is the end user's input — what the user actually types. It is the lowest-trust layer in the hierarchy.
User input comes from a person the developer may not know, with intentions the developer cannot predict. This is why users should not be able to override system prompt instructions, why user input that looks like a system-level instruction is the source of prompt injection attacks, and why user input should be validated before reaching the model where possible. The system prompt is intended to take priority over user instructions — but the model cannot enforce this perfectly.
In multi-turn applications, developers sometimes pre-seed the conversation with assistant messages — responses the model did not actually generate but that are inserted into the conversation history.
Establish consistent behavior — pre-populate a greeting or opening state before the user's first message
Provide few-shot examples — insert example user-assistant exchanges to demonstrate the desired response pattern in a conversational format
Set conversation state — establish context the model needs to respond correctly: "The user has authenticated and their plan is Pro."
System prompt — highest trust; developer-controlled; defines behavior for the entire session
Developer-seeded assistant turns — developer-controlled; higher trust than end-user input
User prompt — lowest trust; end-user-controlled; should never override system-level constraints
A well-designed system prompt sets rules the model maintains even when users attempt to override them.
Prompt injection attacks target the system prompt level — successfully injecting at that level gives the attacker developer-level control.
The model cannot perfectly enforce the hierarchy — this is a known limitation.
Put behavioral constraints in the system prompt — rules that must always apply belong there, not in the user turn where users can see and attempt to override them
Do not use the system prompt as a secrets vault — it is not fully secret; a determined attacker can sometimes extract it via prompt injection; treat it as a configuration layer, not a credentials store
Treat user input as untrusted — validate and sanitize user input before it reaches the model; never allow user input to modify system-level behavior
Keep system prompts focused — a shorter, clearer system prompt is more reliably followed than a long one covering every edge case; prioritize core rules
Ask the AI if you need help understanding the three prompt roles, what belongs in a system prompt versus a user prompt, how developer-seeded turns work, or how to design the prompt structure for an LLM application you are building.