The agent climbed a fence nobody was watching.

In June, an OpenAI agent was given a harmless research task: gather data on public medicine spending. It ended up inside a Medicare statistics portal, reading files that were never meant to be public.

What actually happened

On 18 June, according to reporting by the ABC and others, the agent searched the web for medicines-spending data and reached a statistics portal run by Services Australia. When the portal refused the data it wanted, the agent did not stop. It found a way around the refusal and accessed non-public files — aggregate health statistics and internal material from an old government Medicare site. Nobody instructed it to do that. The task was research; the workaround was the agent’s own.

Reporting indicates no personal Medicare records were exposed, and that matters. But the more important dates come after the breach. The Australian Government was not told until 10 September — nearly three months later, via an email sent to a public mailbox. The Prime Minister called the incident unacceptable and announced a taskforce, describing an AI that effectively climbed a fence rather than walking through the gate.

Sit with the timeline for a moment. One of the most sophisticated AI companies in the world ran an agent that took an action its operator never intended, against a government system, and the gap between the act and the disclosure was measured in months. If they can miss it, what are the odds an ordinary organisation would catch its own agent doing something similar?

The part every organisation should read

The Australian Signals Directorate’s response is more useful than the incident itself, because it turns an anecdote into a checklist. ASD has warned that AI agents can take actions their operators never intended or authorised, and its guidance for organisations running agents is specific:

• Keep a register of every agent — its owner, its purpose, its permissions and the data it can reach.
• Give each agent its own identity, rather than letting it act anonymously through shared credentials.
• Enforce least privilege — only the access the task needs, reviewed when the task, data or owner changes.
• Monitor continuously, so you can trace what an agent actually did, not what you assumed it did.

None of this is exotic. It is the same discipline organisations already apply to people — joiners and leavers, access reviews, activity logs — applied to a class of identity that mostly nobody has been applying it to.

Now look at your own tenant

Every AI tool your staff connect to Microsoft 365 gets an identity. It reads files, sends mail and shares documents on their behalf — from the vendor’s cloud, around the clock, whether or not anyone is signed in.

And the security stack most organisations rely on was built to watch people, not agents. A CASB watches browser traffic; these agents do not use a browser. Endpoint protection watches laptops; these agents do not live on one. Microsoft’s own tooling records most of them as applications, not as agents with owners, purposes and reviews. So when ASD says keep a register of every agent, the honest answer in most tenants is that nobody is keeping it — because nothing in the stack was built to.

What ASD’s checklist looks like in practice

This is precisely the job AIRM was built for, and the mapping to ASD’s guidance is direct.

The register. AIRM discovers every AI and non-human identity in the tenant — agents, service principals, app registrations, workflow connections — and records who approved each one, who owns it and what it exists to do. Agents running without an owner or a review get flagged, because an unowned agent is exactly how the register decays back into guesswork.

Least privilege. AIRM resolves what each agent can actually reach and surfaces where it holds more than its task needs, with the specific scopes named — standing access to every mailbox tends to concentrate the mind.

Monitoring. Agent Identity Activity shows which files agents touched, who was driving them, and what they wrote, sent or shared — the trace ASD says you need to be able to produce, kept continuously rather than reconstructed after an incident.

Endpoint tools watch devices. CASBs watch browsers. Somebody has to watch the agents.