Rules & guardrails
How are rules and guardrails different from a system prompt?
A system prompt sets who the agent is and how it behaves every turn. Rules and guardrails are enforced boundaries on what it can actually do. One steers; the other constrains.
Rules and guardrails are the standing limits around an agent: the policy it must follow and the permissions it is allowed, applied to every run regardless of what the user asks in the moment. An agent that can act on the world needs them, because the cost of a wrong action is higher than the cost of a wrong sentence.
It is easy to lump these together, but they do different jobs. A system prompt sets who the agent is and how it should behave, and it is in play on every turn. Rules and guardrails are enforced boundaries: which tools the agent may call, what it must validate first, and which actions a human has to sign off on. One steers; the other constrains.
The distinction matters because the two fail differently. A system prompt is still just more text the model reads and can, under pressure or confusion, deprioritize against a more insistent instruction buried in a tool result or a long conversation — this is the same channel prompt injection exploits. A rule enforced outside the model’s own text stream does not have that failure mode: it is a check that runs whether or not the model “agrees” with it. That is why the pages that follow — least privilege, decide vs act, and runtime guardrails — are all about things enforced in code and infrastructure, not phrased more firmly in a prompt.
Concretely, that enforcement usually sits outside the model call entirely: a policy check or a tool-call interceptor between the action the model proposes and the effect it would have, evaluating a fixed rule before anything runs. A system prompt has no equivalent layer to sit in — it is text the model reads and weighs against everything else in context, in the same pass, with no separate checkpoint standing between the words and the outcome.