A prompt is a suggestion, not a control
Here is a pattern we see in failed agent pilots. The team writes a careful system prompt: "You may read records. You may never delete or modify them. You may not email customers." Then they are surprised when, three weeks in, the agent deletes a record because a user asked nicely and the model decided that was the helpful thing to do.
The prompt was never a control. It was a polite request. Models are trained to be helpful, and a sufficiently clever input will find the path where deleting the record is the helpful answer. If the only thing standing between an agent and a destructive action is a sentence in the prompt, you do not have a guardrail. You have a hope.
Put the boundary where it cannot be argued with
When we deploy an agent that takes actions, the permissions live in the tool layer, in code, not in the prompt.
The agent does not have a general "run any database query" tool with instructions to be careful. It has a `getCustomer(id)` tool and no `deleteCustomer` tool at all. If deleting is not allowed, the capability does not exist in the agent's hands. You cannot talk a function into existing.
For the actions that are allowed but sensitive, the tool itself enforces the rules:
- Scope every tool narrowly. Read tools and write tools are separate. A tool that can write is scoped to the exact table and the exact fields it is allowed to touch.
- Validate inside the tool. The argument checks, the row-level access, the rate limits live in the function. The model proposes; the code disposes.
- Log every call. Every tool invocation writes an audit line: who, what, when, what arguments. When your SOC 2 auditor asks "what can this thing do and how do you know," you hand them the tool definitions and the logs.
The prompt still matters for behavior and tone. It just is not load-bearing for safety.
Why this is the difference between a demo and production
A demo agent with prompt-only guardrails works fine in the demo, because the demo inputs are friendly. Production inputs are not friendly. They include the confused user, the adversarial user, and the model's own occasional bad day.
We learned this building our own agents. The interviewer agent behind gitGood grades real sessions in production; the tools it can call are tightly scoped and every call is logged, because "the model usually behaves" is not a posture you can ship.
This is also why per-seat AI tools and our deployments end up in different conversations. A SaaS chatbot gives you the vendor's guardrails. A deployment on your own infrastructure lets you put the guardrails in your own code, where your security team can read them.
If you are evaluating an agent for anything that touches real data or takes real actions, ask one question: where are the permissions enforced? If the answer is "in the prompt," keep evaluating. If you want them enforced in code, on your own cloud, let's talk.