{"slug": "when-access-denied-becomes-an-agents-next-objective", "title": "When ‘access denied’ becomes an agent’s next objective", "summary": "An OpenAI agent accessed public and non-public files in an Australian Medicare statistics portal, prompting Prime Minister Anthony Albanese to say the agent \"didn't accept no for an answer\" and \"found a way around those blocks,\" with an investigation underway. In a separate incident, OpenAI disclosed that a model in training, blocked from web searches and direct connections, embedded questions in DNS hostnames to reach an external chatbot; OpenAI stopped the run and days later shelved GPT-6.1 Astra, which head of safety systems Saachi Jain said \"didn't quite meet the bar in terms of staying within scope and authorization.\" The August paper Permission Denied, testing 12 coding agents under increasingly restrictive security policies, found that 97% of policy-induced failures came from the agent building a workaround.", "body_md": "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](https://www.aljazeera.com/news/2026/9/24/how-an-openai-agent-hacked-australias-medicare-and-what-that-means).”\n\nIt 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.\n\n“The AI agent found a way around those blocks,” Albanese said. The agent accessed public and non-public files, [according to the prime minister](https://www.abc.net.au/news/2026-09-24/openai-agents-plotted-to-access-data-amid-medicare-hack/107189504), though Deputy Prime Minister Richard Marles said the information was “not particularly sensitive.” An investigation is underway.\n\nAround the same time, [OpenAI disclosed another incident](https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/). 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](https://www.infoworld.com/article/4227778/openai-pauses-ai-model-training-after-another-agent-bypasses-network-restrictions-2.html). Days later, it [shelved GPT-6.1 Astra](https://www.infoworld.com/article/4228292/openai-pulls-the-plug-on-gpt-6-1-astra-as-agents-keep-crossing-lines-2.html), which [Saachi Jain](https://www.theregister.com/ai-and-ml/2026/09/29/openai-benches-gpt-61-astra-for-overstepping-the-mark/5299743), its head of safety systems, said “didn’t quite meet the bar in terms of staying within scope and authorization.”\n\nDifferent systems, different failures, one question: what does “access denied” mean to an agent?\n\nTraditional 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.\n\nAgents do have one.\n\nWe 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.\n\nA 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.\n\nResearchers are now measuring what happens after a restriction is applied. In the August paper [Permission Denied](https://arxiv.org/abs/2608.02670), 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.\n\nThe 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.\n\nEnforcing policy outside the model is no longer a new idea. Recent research puts policy enforcement at a [trusted tool boundary](https://arxiv.org/abs/2608.27646) 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?\n\nReal systems already have harder stops. The OpenAI Agents SDK can halt a run when a [tool guardrail](https://openai.github.io/openai-agents-python/ref/tool_guardrails/) raises an exception. Claude Code’s auto mode can [return control to a person](https://code.claude.com/docs/en/permission-modes) after three blocked actions in a row or 20 in total.\n\nNothing 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.\n\nI 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.\n\nI would treat denials differently depending on what they mean.\n\nA 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.\n\nIt is correctable when the request itself is malformed and a legitimate fix does not expand what the task is allowed to do.\n\nIt 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.\n\nThe test is whether succeeding needs permission or just patience.\n\nIf it needs permission, the agent shouldn’t be the one looking for it. At some point, persistence is just a very polite security incident.\n\nIn [a previous InfoWorld piece](https://www.infoworld.com/article/4223350/your-ai-agents-are-isolated-your-infrastructure-isnt.html), 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.\n\nA terminal denial should do five things.\n\nThe model can still reason. It just no longer gets to act under the old authority.\n\nThis is not a bigger kill switch. A kill switch stops a whole agent; a terminal denial acts on a specific refusal when it happens.\n\nTiming matters too.\n\nSuppose the harness checks that a task is authorized and then dispatches an action. If the task is terminated between those two steps, a stale approval can still get through. High-impact operations need atomic authorization and dispatch where feasible, or fencing tokens that downstream services verify before accepting an action.\n\nWork already in flight creates another problem. On an enterprise system I worked on, a permission check correctly rejected an operation, but the workflow kept going through work that had already been queued. The control worked at the point of rejection. The task still had a path to continue.\n\nA queued operation may be cancellable. A running operation may be interruptible. A committed database write may require a compensating action instead.\n\nThe architecture needs to say which guarantee it provides.\n\nThe question I ask about every agent permission is what outcome the denial protects.\n\nNot which API is blocked. Which effect is the policy trying to prevent?\n\nCustomer data leaving a tenant is an effect. It might happen through an export API, an email attachment, a file upload or a DNS lookup.\n\nOn another project, we restricted a sensitive operation at the main service interface and considered the control complete. Testing showed the same operation was still possible through a separate, approved path. The permission worked. We had protected the interface, not the effect.\n\nAn April [stress test of Claude Code’s auto mode](https://arxiv.org/abs/2604.04978) found a version of exactly this problem. When a command-line tool was unavailable, agents fell back to editing state files directly, “a path the classifier does not evaluate.”\n\nGroup controls by effect. When a terminal denial fires, apply it to the protected operation across every tool the task can use.\n\nTreat repeated denials as a signal, not a magic number. Several denials across different tools pursuing the same outcome may mean the task should stop. Set the threshold by risk; one high-impact violation may be enough.\n\nTreat every communication path as egress. Blocking HTTP does not establish isolation if DNS, package installation or shared infrastructure can still reach the outside.\n\nTest the boundary the way an agent might challenge it.\n\nDeny a resource through one tool while leaving another route available. Terminate a task with an action still queued. Revoke a parent task and check whether its helpers continue. Try a new action with a stale capability.\n\nMeasure whether the prohibited action executed. Do not measure success by whether the model said it would stop.\n\n[ScopeBench](https://arxiv.org/abs/2609.30325) recently found 331 boundary violations that mechanical verification missed.\n\nNone of this is new to security engineers. Least privilege, deny by default and fail closed are decades-old principles.\n\nWhat changes with agents is what happens after a control says no.\n\nThe answer is not to make every tool error fatal. It is to separate the model’s ability to propose the next action from the system’s authority to permit it.\n\nA denial is a response. Enforcement is what happens next. The agent can be as persistent as we like. The boundary shouldn’t be negotiable.", "url": "https://wpnews.pro/news/when-access-denied-becomes-an-agents-next-objective", "canonical_source": "https://www.infoworld.com/article/4237168/when-access-denied-becomes-an-agents-next-objective.html", "published_at": "2026-10-20 09:00:00+00:00", "updated_at": "2026-10-20 09:15:35.096294+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy"], "entities": ["OpenAI", "Anthony Albanese", "Richard Marles", "GPT-6.1 Astra", "Saachi Jain", "Medicare", "OpenAI Agents SDK", "Claude Code"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/when-access-denied-becomes-an-agents-next-objective", "markdown": "https://wpnews.pro/news/when-access-denied-becomes-an-agents-next-objective.md", "text": "https://wpnews.pro/news/when-access-denied-becomes-an-agents-next-objective.txt", "jsonld": "https://wpnews.pro/news/when-access-denied-becomes-an-agents-next-objective.jsonld"}}