System Prompt
A system prompt is the instruction an application gives a model before any real conversation starts — setting its role, its tone, and the rules it should follow for the whole session. It's written by whoever built the application, not typed by the person using it, and it stays in place across every message in that session.
A customer-support assistant might have a system prompt like: "You are a support agent for Acme's billing product. Answer only questions about billing, invoices, and payment methods. If asked about anything else, say it's outside what you can help with. Keep answers under three sentences unless the user asks for more detail." Everything after that — whatever the user actually types — gets read alongside this standing instruction, every single time.
What actually goes in one
A role or persona ("you are a support agent for..."), the tone to use, real constraints on what the model should and shouldn't do, the output format the application expects, and sometimes guidance on when to use a given tool. It's the one place an application sets standing behavior once instead of repeating the same instructions inside every single user message.
It's a strong instruction, not a security boundary
A system prompt gets more weight than a user message, but it isn't enforced the way a permission or a password is. The prompt injection page's own finding applies directly here: role markers are labels, not walls, and there's no parser downstream that makes the model honor them absolutely. Persuasive enough text in a later message, or in content the model reads along the way, can still outweigh it. Don't rely on a system prompt alone to enforce a rule that actually matters — a real safety boundary needs to sit in the application's own code (what tools are available, what actions need approval), not only in wording.
A longer, more emphatic system prompt isn't automatically more obeyed
Writing "YOU MUST ALWAYS" or repeating a rule five times doesn't add enforcement — it's still one piece of text competing with whatever else the model reads, the same limitation prompt engineering runs into generally. A specific, clear instruction usually works better than a long, emphatic one. "Never discuss competitor pricing" is clearer than a paragraph restating the same point three ways.
Say what to do, not only what to avoid
A system prompt that only lists what the model shouldn't do leaves it no acceptable alternative when a case comes up that the rules didn't cover. "Don't answer questions about refund exceptions" is weaker than "Don't answer questions about refund exceptions — say a specialist will follow up instead." Naming the acceptable fallback is the same fix the hallucination page recommends for the model generally: give it a real, sanctioned thing to say instead of just a rule to avoid breaking.
In this guide
FAQ
Is a system prompt the same as fine-tuning the model's behavior?
No. A system prompt is an instruction supplied at request time — it can be changed instantly and costs nothing to update. Fine-tuning changes the model's underlying weights — the numbers inside it that determine how it responds — through additional training beforehand. If a behavior can be achieved with a clear system prompt, it's almost always the cheaper and faster option to try first.
If something matters enough to put in the system prompt, should it always go there instead of the user message?
Standing rules that apply to every message in a session belong in the system prompt — role, tone, constraints that don't change. Anything specific to the current request belongs in the user message instead. Mixing the two the wrong way either forces a standing rule to be repeated every time, or buries a one-off instruction somewhere the model has learned to treat as fixed background.