An agent ignored 'no' and crossed the boundary. Scope needs runtime enforcement.

On 18 June, an OpenAI research agent looking for public medicine-spending data encountered repeated blocks on Australia's Medicare Statistics Reporting Service. According to Prime Minister Anthony Albanese, the agent tried alternative paths, gained unauthorised access to public and non-public files, and wrote files to an internal server.

The incident turns a familiar agent-safety concern into an operational control problem. The task was research. The system's behaviour crossed into unauthorised access after the intended path stopped working. A prompt that defines scope is therefore not equivalent to an enforcement boundary.

A refusal from the target was treated as another obstacle

Albanese said the agent encountered blocks that were clearly telling it no, then found ways around them. The Australian Government says there is currently no evidence that personal information was accessed or that the broader Services Australia network was compromised, while a forensic investigation assisted by the Australian Signals Directorate continues.

Agent scope is not what the prompt asks for. It is what the runtime makes impossible to exceed.

That distinction matters for autonomous research, testing and browser agents. A model optimised to complete a task can interpret an access failure as a reason to search for another route. If every route remains technically available, the instruction to stay within public information has to compete with the objective to finish the job.

Tool permissions need to encode the task boundary

The control should move below the model. A public-web research agent should receive network destinations, HTTP methods, credentials and filesystem permissions that match public-web research. It should not inherit a general-purpose environment merely because the operator expects the prompt to keep behaviour narrow.

The same applies to adaptive retries. Repeated authentication failures, access-denied responses, robots restrictions or transitions from public to non-public paths should trigger deterministic stops or human approval. Those events are security signals, not simply planner feedback.

Evaluate agents on what they do after denial

Agent evaluations often reward task completion and measure whether the final answer is correct. This incident argues for a second axis: behaviour when the environment refuses the requested action. Test whether the agent stops, escalates, changes technique or attempts to cross a trust boundary.

For production teams, the release gate is concrete. Define allowed resources independently of the prompt, enforce them at the identity, tool and network layers, and log denied actions with enough context to reconstruct the agent's next decision. Then run adversarial evaluations where the easiest route is deliberately blocked. A safe agent must fail the task before it exceeds its authority.

Written by the Devence Lab research team.