Enforced, or Requested?
Ask the team that runs an AI agent what the agent isn't allowed to do, and you'll usually get a confident list. Don't send payments over a set amount. Don't touch production. Ask before deleting anything. Never share customer data outside the bank.
Then ask a second question about each item: is it enforced, or is it requested?
The two sound similar. They are not the same kind of control.
Two kinds of constraint
A requested constraint lives where the model reads it: a system prompt, an instruction file, a tool description, or a second model asked to judge the first. It works when the model understands it, applies it correctly, and doesn’t talk itself out of it. Most of the time, that is exactly what happens.
An enforced constraint lives where the action happens. The system that actually moves the money, changes the record, or sends the message checks the action against the rule before it runs, and refuses if the rule isn't met. The model can be wrong, confused, or persuaded, and the action still doesn't happen.
The difference shows up in the rare case, not the common one. A requested constraint that holds 99 times out of 100 looks perfect in a demo and in most weeks of production. The hundredth case is the one an examiner or an incident review will ask about.
What "most of the time" looks like in numbers
A recent research paper on agent-based zero-trust enforcement (Agentic-ZTA, arXiv 2610.05782) gives a clean illustration. Its authors compared AI agents making access decisions against a simple rule-based evaluator on 160 test requests. The agents reached 95% accuracy; of the 80 requests that should have been denied, they allowed 3. The rule-based evaluator was correct on all 160 and decided in under a millisecond. The authors are clear that their framework's benefit is deciding without administrator-written rules, not higher accuracy, and that's a fair trade for some uses. We wrote about the study in When the Baseline Wins.
Ninety-five percent is a strong result for a model. As a control on what an agent can do, it means a few actions that should have been blocked slipped through.
The five-question test
For each constraint on your list, ask:
Where does it live? In text the model reads, or in the system that carries out the action?
If the model ignores it, what stops the action? If the honest answer is "nothing," it's requested.
If the information the rule needs is missing, what happens? The action should be denied or sent to a person, not allowed because nothing said no.
Who can change it, and is the change recorded? An enforced rule that anyone can quietly edit is only partly enforced.
Afterward, can you show which rule applied and whose authority it rested on? If not, the control may have worked, but you can't prove it did.
A constraint that passes all five is a control. One that fails the first two is guidance, which is useful, but it shouldn't be counted as a control.
A worked example
Take one rule: wire transfers above $25,000 need a second approver.
Requested version. The agent's instructions say: "For wires above $25,000, request approval before sending." The agent usually does. But the payment system will release any wire the agent submits, so the rule holds only as long as the agent remembers it, reads the amount correctly, and isn't told by a cleverly worded document that this case is an exception.
Enforced version. The payment system will not release a wire above $25,000 without an approval from someone with the authority to give it, and the approval is tied to the exact transfer that was approved. The agent can still ask, draft and queue. It can't send.
Bankers will recognize the second version immediately. It is dual control and segregation of duties, the same principles that keep a teller's limit in the core system rather than in the teller's memory. AI agents need the same treatment, for the same reason.
Requested constraints still matter
None of this makes instructions useless. Good instructions reduce how often an agent attempts something it shouldn't, keep its behavior predictable and make its work easier to review. They are a sensible layer in a defense in depth.
The problem is narrower: counting a requested constraint as a control. When a risk register lists "agent instructed not to exceed limits" as the mitigation, the register is describing a hope.
What this test doesn't tell you
It doesn't make a bad rule good. Enforcing the wrong limit enforces the wrong limit. Authoring errors need their own review; we described four of them in What the Compiler Cannot Catch, in our Technical Notes.
Enforcement outside the model has its own failure modes. If the agent holds the credentials to call the payment system directly, it can go around the check. Enforcement only works when the system that executes the action, not the agent, holds the keys.
It doesn't mean models can't be trusted with anything. Plenty of agent work, such as drafting, summarizing and searching, needs no hard enforcement at all. The test is for actions with consequences.
A question to take back
Pick your agent's three most consequential constraints and run them through the five questions. How many are enforced, and how many are requests to a model?
Triarcus Systems builds pre-execution governance for AI: every proposed action is checked against written rules and the authority they grant before it runs. No action without authority.