Why deterministic policies break down for AI agents

Imagine a regulator asks you to prove that your support agent did not access a Tier-2 customer's billing record on a specific date. You go looking for the answer and find it was never recorded as a decision. The system prompt said don't access billing for that tier. The tool manifest listed which functions the agent could call. Somewhere in between, the model decided, and there is no log entry for that decision because no decision point existed. Whether the agent did the right thing that day is not something you can prove. It's something you can only infer from what happened to happen.

That gap is the real subject of most "deterministic policies aren't enough for agents" arguments, and it's worth being precise about what's actually missing, because the instinctive fix, adding an AI judgment layer on top of the static rules, solves a different problem than the one that just showed up.

Why the prompt was never the policy

Writing access rules into a system prompt feels like policy. You state the rule, the model reads it, the model complies, in most cases. The failure mode is that a prompt is interpreted, not enforced. A confusing input, a tool description that quietly implies more capability than intended, or a goal that conflicts with the stated rule, and the model's judgment produces a violation that looks, in the transcript, exactly like a correct response. OWASP's 2026 top ten for agentic applications names this pattern directly: the risk isn't only what an agent can reach, it's how much freedom it has to act on that reach without anything checking it on the way through.

Static manifests don't hold up much better on their own. A rule like "this agent can call refund_order" survives right up until it needs a condition: refund_order, but only if the order belongs to the requester's tenant, is under 30 days old, and stays under a dollar cap. Once conditions start multiplying across tenants and roles, teams either scatter checks across every tool wrapper or give up and lean back on the prompt, and either way you've lost the one thing a rule was supposed to give you: a decision that happened outside the model, that you can point to later.

The ownership check that isn't actually a judgment problem

Here's a case worth sitting with, because it's the example almost everyone reaches for when explaining why static rules aren't enough: an agent should only be allowed to delete a document if it's owned by the person it's acting for. That looks, at first pass, like it needs judgment. You can't write "allow delete" as a flat rule, because whether the action is allowed depends on a fact about the specific document, not on the agent's role.

It's tempting to conclude from that shape of problem that you need something softer than a rule, an AI layer that looks the situation over and decides. But look at what's actually missing: not judgment, a fact. Who owns this specific document is a lookup, not a call. The access-control field converging on this treats exactly this case as a relationship-based access control problem, not a role-based one: model ownership as a relationship in a graph, "user X member_of tenant Y," "document Z belongs_to tenant Y," and the deterministic engine can answer the ownership question the same way it answers everything else, by querying data instead of guessing at intent. The rule stays a rule. What changed is that the rule can now see relationships, not just roles.

Most of what gets diagnosed as "we need AI judgment here" is this same misdiagnosis: a case that looks unrulable because the current rule engine only knows about static roles, when the actual gap is that nobody fed it the relationship data it needed to answer a question it was already capable of answering deterministically.

What's actually left over

Once you've pushed relationship data, delegation chains, and runtime conditions into the deterministic layer, and further into that, once you've separated who delegated the task from who's currently acting on it (a distinction the IETF's draft standard for agent transaction tokens formalizes directly, because prompt-injected agents misusing their own legitimate permissions on someone else's behalf is exactly the failure that separation is meant to catch), the set of cases that genuinely can't be resolved by a rule gets much smaller than most governance write-ups assume.

What's left is real, though. Intent that technically satisfies a rule but contradicts the reason the task was started. Combinations no one wrote a rule for because no one anticipated that specific pairing. Thresholds that are numeric on paper but triggered by something ambiguous in natural language, a refund cap is a clean dollar figure, but the request that triggers it arrived as a sentence, and someone still has to decide what that sentence actually asked for. That last one came up, unresolved, in a public discussion among people actively building agent authorization systems: nobody had a settled answer for where the line sits when the trigger for a hard rule is itself a judgment call. That's an honest admission worth taking seriously, because it means this genuinely is where the deterministic approach runs out, not just where it's inconvenient to keep extending it.

The one rule for letting anything softer near the gate

For that remainder, the emerging shape of the answer isn't "let the model decide" and it isn't "pretend the remainder doesn't exist." It's narrower than both. A model can flag, score, or propose. It cannot be what opens the gate, because the same property that makes a model useful, that it reasons over ambiguous input, is the same property that makes it manipulable by the same kind of ambiguous input an attacker controls. A second model checking a first model's decision doesn't close that gap, it just adds a second thing an attacker can talk to.

Two disciplines make this workable in practice, and neither is optional.

Capability scope only ever narrows when it's delegated, never widens. When a task-scoped token gets passed from one agent to a sub-agent it spawns, the sub-agent's permissions have to be a subset of the parent's, enforced at the token-issuing server, not in application code that a future refactor might quietly break. This is the same principle showing up in a completely different context than security researchers usually reach for it in, agent delegation chains instead of Unix file permissions, but it's the same principle: whatever narrows trust downstream has to be structural, not a convention someone remembers to follow.

"The model refused" and "the policy refused" have to stay two different sentences in your logs, always. Both look identical in a transcript: the user asked for something, the answer was no. But a model's refusal reflects what its training thinks is risky in this instance, which a different prompt or a different model version might answer differently. A policy's refusal reflects a rule that was evaluated and denied, the exact evidence a regulator, an auditor, or your own postmortem actually wants. If your logging can't tell these two kinds of no apart, you can't answer "did our governance actually work" with anything stronger than "the model usually behaves," and that's not an answer, it's a hope with a transcript attached.

None of this makes the judgment problem go away. It just shrinks it down to the size it actually is, which turns out to be a lot smaller, and a lot more specific, than "deterministic policies aren't enough" usually implies.

Sources

• Don't use an LLM to decide what your AI agent is allowed to do, Brian Hall, DEV Community
• RBAC vs ReBAC for AI Agents: Best Authorization Model for Secure Agentic Systems, Or Weis, Permit.io
• Policy-as-Code for Agents: OPA, Rego, and the Decision Point Your Tool Loop Doesn't Have, Tian Pan
• OAuth Transaction Tokens for Agents (IETF draft)
• OWASP Top 10 for Agentic Applications 2026