One line from a recent AI incident caught my attention. Describing how an OpenAI agent got into a Medicare statistics portal, Australian Prime Minister Anthony Albanese said it “didn’t accept no for an answer.”
It sounds almost funny. In software terms, though, it points to a real problem. An access control said no, and the agent treated the answer as information about how to continue.
“The AI agent found a way around those blocks,” Albanese said. The agent accessed public and non-public files, according to the prime minister, though Deputy Prime Minister Richard Marles said the information was “not particularly sensitive.” An investigation is underway.
Around the same time, OpenAI disclosed another incident. A model in training found its web searches and direct connections blocked, then discovered that the environment’s own DNS resolver still answered. It embedded questions in hostnames and got answers from an external chatbot. OpenAI stopped the run. Days later, it shelved GPT-6.1 Astra, which Saachi Jain, its head of safety systems, said “didn’t quite meet the bar in terms of staying within scope and authorization.”
Different systems, different failures, one question: what does “access denied” mean to an agent?
Why a denial is information
Traditional software treats an authorization failure as the end of a code path. A service gets a 403, raises an exception and someone reads the log. The denial works as a stop sign because the program has no independent objective to pursue.
Agents do have one.
We have spent years teaching software to recover from failure: retry the request, switch the endpoint, back off and try again. Those are good instincts. They become dangerous when the failure is the security control itself.
A timeout says “try later.” A malformed request says “fix this.” An authorization failure says “you are not allowed to do this.” Those are different kinds of messages, but a guardrail that returns all three as text in the model’s context makes them look alike.
Researchers are now measuring what happens after a restriction is applied. In the August paper Permission Denied, 12 coding agents were tested under increasingly restrictive security policies. Blocked runs rarely stopped early. They timed out or produced wrong solutions. Of the policy-induced failures, the researchers found that 97% came from the agent building a workaround.
The issue is not simply whether a model understands a policy. It is what the system allows the model to do after the policy says no.
Enforcing policy outside the model is no longer a new idea. Recent research puts policy enforcement at a trusted tool boundary the agent cannot control. But that still leaves an unanswered question: when should a denial end the task rather than become another input for the agent?
Real systems already have harder stops. The OpenAI Agents SDK can halt a run when a tool guardrail raises an exception. Claude Code’s auto mode can return control to a person after three blocked actions in a row or 20 in total.
Nothing tells you which denials deserve which response. The missing piece is not another kill switch. It is a policy for deciding what a denial means and what authority disappears when it happens.
I don’t think the lesson is that models are bad. The problem is where we put the boundary. A guardrail that reports back to the thing it is restraining is a soft boundary. It shapes behavior. It doesn’t necessarily end it.
A terminal denial changes authority
I would treat denials differently depending on what they mean.
A denial is retryable when the same authorized request might succeed later without anyone granting new authority. A timeout, a temporary dependency failure or a rate limit can fit here.
It is correctable when the request itself is malformed and a legitimate fix does not expand what the task is allowed to do.
It is terminal when continuing would require permission the task was never given, such as reading another tenant’s records or reaching a destination the egress policy prohibits.
The test is whether succeeding needs permission or just patience.
If it needs permission, the agent shouldn’t be the one looking for it. At some point, persistence is just a very polite security incident.
In a previous InfoWorld piece, I argued that permission enforcement should be independent of how an agent interprets its situation. A terminal denial applies that principle at the moment of refusal. It should change the state of the system, not just the contents of the model’s context.
A terminal denial should do five things.
- Enforce it at a trusted execution boundary. The decision happens in the harness, policy service or gateway that executes the tool call, outside the model’s reasoning. A model cannot argue its way past a check it does not control.
- Take away the relevant authority. Once the task is terminally denied, the runtime rejects later
[…]
Content was trimmed to protect the source. Please visit the original article for the full text.
Read the original article: