System Prompt vs User Prompt vs Context: Who Controls the AI?
Every AI response is assembled from up to seven layers, written by different parties with different trust levels. Here's what each one actually controls.
"I asked the AI a question and it answered" describes what a user experiences. It doesn't describe what actually happened. By the time a model generates a single word of response, up to seven distinct layers have already been assembled into its context, written by different parties, at different times, with different levels of authority, and the model itself has no built-in way to tell them apart once they're all sitting in the same window.
The one sentence to remember
Every layer in this pipeline is written by someone, or something, with a different level of trust, and the model only respects that difference if the system feeding it the prompt actually preserves it.
The Full Architecture
What Each Layer Actually Controls
System Instructions
Written by the AI platform itself, OpenAI, Anthropic, Google, not by you and not by whoever built the application you're using. This layer sets foundational behavior and absolute limits, the things true across every single use of that model, regardless of application. It's the highest-trust layer, and for most people using AI day to day, it's invisible.
Developer Instructions
Written by whoever builds the specific application, prompt, or assistant you're interacting with. This is the layer the anatomy of a good prompt is actually about, role, context, task, constraints, output format, and it's also the layer a ChatGPT "system prompt" or custom instruction occupies in practice, despite the naming. A genuinely useful distinction: what most people casually call "the system prompt" when writing custom instructions is architecturally a Developer Instruction, one level down from the platform's own System Instructions, not the top of the stack.
User Request
What the actual person typed, right now, in this turn. A real instruction, and the one the whole system is ultimately built to serve, but scoped by everything above it: a user can ask for something the application's own developer instructions don't permit, and a well-built system respects that boundary rather than letting the most recent instruction always win.
Retrieved Context
Documents, search results, or database records pulled in to help answer the request, the mechanism covered in full in RAG From Scratch. This layer is meant to control what facts the model has available, nothing more. It's information to read, not instruction to follow, and it's written by whoever authored the source document, someone with no relationship to the person asking the question at all.
Tool Results
Whatever an API call, function, or MCP tool the model itself decided to invoke actually returned. This layer feels the most "trustworthy" by default, it came back from a real system call, not from a random webpage, and that's exactly what makes it easy to under-scrutinize. A tool result can carry attacker-influenced content just as easily as a retrieved document can, a fetched webpage, a returned email, a file's contents, and it deserves the same skepticism.
Model
The actual inference step, where every layer above has already been flattened into one sequence of tokens. This is the architectural crux of the whole topic: nothing inside a transformer tags a token with "this one came from the Developer Instructions, weight it more." Whatever authority each layer is supposed to carry has to already be encoded in how the prompt was assembled, because by this stage, it no longer exists as separate channels.
Response
What actually comes back. In a single-turn interaction, that's the end of the pipeline. In a multi-turn conversation or an agentic loop, this response becomes part of the context for the next step, which means a response already influenced by something untrusted can carry that influence forward into a turn that trusted it as the model's own prior reasoning.
Who Controls What: The Actual Answer
| Layer | Written by | Should it be treated as an instruction? |
|---|---|---|
| System Instructions | The AI platform | Yes, always, the highest trust in the stack |
| Developer Instructions | Whoever built this application | Yes, this is what your prompt is actually built from |
| User Request | The person using it right now | Yes, but scoped to what the application permits |
| Retrieved Context | Whatever source the app queried | No, information only |
| Tool Results | Whatever system the model just called | No, information only, even though it feels system-generated |
| Model | The inference step | Not applicable, this is where every distinction above collapses |
| Response | The model's own output | Becomes untrusted input again the moment it's fed into a future turn |
Why Mixing These Creates Real Security Problems
The architectural root cause
A model has no structural mechanism for verifying which layer a given piece of text actually came from once it's inside the context window. Two sentences with identical phrasing, one from your carefully written Developer Instructions and one buried inside a retrieved document, compete for the model's compliance on equal footing unless the system assembling the prompt explicitly preserved the distinction.
This is precisely the failure mode covered in depth in Prompt Injection: When the Input Starts Controlling the AI: Retrieved Context and Tool Results are exactly the two layers most likely to contain something an attacker actually wrote, and they're also the two layers a naive prompt is most likely to concatenate directly alongside its own trusted instructions with no boundary at all. Prompt Injection and Agent Hijacking covers what happens when that same gap exists in a system where Tool Results feed back into further tool calls with real permissions, the architectural version of this problem, at the highest stakes.
The practical fix starts at the API level
Most model APIs already provide real structural separation, a system role, a user role, a tool role, distinct from each other in the request itself, not just distinct in your head. Using those actual role fields, rather than concatenating everything into one flattened string, is the first and cheapest architectural boundary available, before any of the prompt-level techniques (delimiters, explicit labeling) covered in the injection post are needed on top.
The Bottom Line
"Who controls the AI" has an actual, layered answer, not a single one. The platform controls the floor. The developer controls the task. The user controls the request, within what the developer allowed. Everything else, retrieved documents, tool results, is supposed to inform the answer, never direct it. The moment a system stops preserving that distinction when it assembles a prompt, it's not that the model becomes untrustworthy, it's that every layer becomes equally trusted, which in practice means the least trustworthy one now has exactly as much say as the most trustworthy one.
The question worth asking about any AI system you build or use
Can you point to the actual mechanism, an API role, an explicit delimiter, a structural boundary, that keeps Retrieved Context and Tool Results from being treated as instructions? If the honest answer is "the model probably knows the difference," that's not an answer, it's the exact gap this whole architecture is built to close.
Which layer in this stack have you seen collapse into another by accident, a retrieved document that got treated like an instruction, a tool result that changed the model's behavior in a way nobody expected? Drop a comment with what happened and where the boundary was missing.
Written by
Chetan Yamger
Cloud Engineer · AI Automation Architect · Modern Workplace Consultant
Cloud Engineer, AI Automation Architect, and Modern Workplace Consultant based in Amsterdam, Netherlands. Specializing in scalable, secure enterprise solutions with Microsoft Azure, Intune, PowerShell, and AI-driven automation using ChatGPT, Gemini, and modern LLM technologies.
Stay in the loop.
New articles, straight to you.
Deep-dive technical articles on Intune, PowerShell, and AI — no noise, no spam.
Discussion
Share your thoughts — your email stays private
Leave a comment