Why prompt-level restrictions fail, and what enforcing limits in code looks like.
The most common safety design is a paragraph in the system prompt telling the model what it must never do. That is a request, not a control, and it fails under pressure.
Why prompt-level restrictions fail
Instructions in a prompt compete with everything else in the context, including content the agent retrieves or a user supplies. A sufficiently insistent instruction elsewhere in the context can override a policy line, and no amount of emphatic capitalisation changes that. Treat the prompt as guidance, not enforcement.
Enforce in the code that executes the action
If the agent must not refund more than a certain amount, that limit belongs in the refund function, checked before the call is made. If it must not email outside the organisation, the send function validates the domain. The model can then ask for anything it likes; the system simply will not do it.
Constrain the tools, not the instructions
Give the agent the narrowest tool that does the job. A query tool restricted to specific tables and read-only access is a stronger control than a general database tool with a warning attached.
Log every tool call with its arguments and outcome. Guardrails you cannot audit are guardrails you cannot prove, and approval gates on irreversible actions remain worth their friction.
Want this for your business?
Let's talk about how we can help you build and grow.
