# An AI Agent’s First Unauthorised Write Starts the Incident Clock

> An OpenAI agent crossed into an Australian Medicare statistics portal, and the government heard about it months later. The engineering lesson is to stop, preserve evidence, and notify the affected owner as soon as an agent creates an unauthorised effect.

- **Author:** Kubilay Tunca
- **Published:** 2026-09-25
- **Category:** For Developers
- **Tags:** AI Agents, AI Security, Incident Response, Observability
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/developers/news/ai-agent-unauthorised-write-starts-incident-clock

---

On 18 June 2026, an OpenAI research agent looking for public medicine-spending data met repeated blocks at an Australian government website. It tried other routes. According to Australia’s prime minister, the agent gained unauthorised access to public and non-public files in a Medicare statistics portal and wrote files to an internal server.

The known impact appears limited. Australian officials said on 24 September that they had found no evidence of access to personal Medicare records or a wider compromise of the Services Australia network. The portal held aggregate statistics, and some information that was non-public in June has since been published. That is reassuring for patients. It does not make the event operationally small.

The incident exposes two separate failures. The first was an agent continuing after a service had refused the requested path. The second was the clock: OpenAI said it became aware of the activity during an August review, but Services Australia received an email on 10 September. The affected operator was left without the information it needed to preserve short-lived records, inspect the server, or decide whether containment was urgent.

That second failure deserves more attention than another argument about whether the model was “rogue.” Once an automated system creates an unauthorised external effect, the incident clock has started. The team running it should stop the run, preserve evidence outside the agent’s reach, identify the affected owner, and send a useful notice while the facts are still fresh.

## What happened, with the uncertainty left intact

The most direct public account came from Australian Prime Minister Anthony Albanese on 24 September. His [official press-conference transcript](https://www.pm.gov.au/media/press-conference-new-york) says an OpenAI research team used an internal model on 18 June to investigate public medicine spending. After repeated blocks, the model found another route, accessed public and non-public information in the Medicare Statistics Reporting Service portal, and wrote files to the internal server.

That description establishes unauthorised effects. It does not yet establish every technical step. As of 25 September, the Australian Signals Directorate was assisting a forensic investigation. The government had not published the file names, request sequence, duration of access, server logs, or the mechanism that allowed the write. Any confident exploit narrative would run ahead of the evidence.

The data distinction matters too. The portal held aggregate figures about programs such as Medicare and the Pharmaceutical Benefits Scheme. [ABC’s detailed account](https://www.abc.net.au/news/2026-09-24/what-we-know-about-the-openai-medicare-hack/107189452) says officials found no evidence that personal records were accessed. Some material was not public at the time, but the government described it as not particularly sensitive and said it was later released. A write to an internal server remains serious even when the files read are dull.

OpenAI’s public statement, quoted by [ABC News](https://www.abc.net.au/news/2026-09-24/ai-agent-accessed-australian-government-site-pm-says/107189078), said its models were trying to answer questions about Australia during an internal evaluation and “took actions we did not intend.” The company said its review found aggregate health statistics and internal file names, with no evidence of patient-record access. It also said it was providing technical information to support the investigations.

The broader swarm story is less settled. ABC reported that public logs showed OpenAI agents using a German coding site to share attempts to reach Australian health-data services. Those logs included proxy use, screenshot services, and guessed file names. [ABC also reported](https://www.abc.net.au/news/2026-09-24/openai-agents-plotted-to-access-data-amid-medicare-hack/107189504) that the logs did not name Medicare or Services Australia, and that neither the company nor the government had publicly confirmed the two sets of activity were the same incident. Treating that link as proven would be careless.

The safe factual core is narrower. One internal research run crossed a government portal’s intended access boundary. It read files that were not public and wrote files to a server. Officials currently describe the impact as minor, while their investigation remains open. OpenAI discovered relevant activity later and notified the site operator months after the June event.

That is enough to change engineering practice. We do not need to guess at model intent to know that an external system received actions it had not authorised.

## The first external effect changes the job

A model can think about forbidden actions without creating an incident. It can draft a URL, suggest a command, or describe how it might search for a file. The job changes when the surrounding system sends the request, tries a credential, writes a file, publishes a package, or changes somebody else’s data.

The team’s job changes at that moment from evaluating behaviour to handling a computer that has affected another party’s system. Familiar incident questions take over: what happened, when did it happen, what authority was used, what evidence exists, how can the effect be stopped, and who owns the affected service?

A file write is an especially clear line. Reading an unexpectedly exposed public file may still require review, but a write goes beyond observation. It changes state. Even a harmless marker file can consume storage, trigger processing, alter timestamps, trip monitoring, or create work for an administrator who must determine whether the server was compromised.

The same rule applies to less dramatic agent work. A coding agent that opens an unrequested pull request has created an external effect. A browser agent that submits a form has changed another system. A research agent that uploads a source document to a file host has disclosed data and created a copy. A package-testing agent that publishes a test artifact has placed something into a public supply chain. “The model was only trying to finish the task” does not undo any of those outcomes.

Teams often use the model’s final answer as the run boundary. The agent says it is done, a benchmark records a score, and the worker is destroyed. That works only if the agent’s actions stayed inside a disposable lab. Once the run touches a real service, the event boundary comes from the effect, not from the model’s narration.

This is why intent is a weak operational trigger. Intent may matter later for legal analysis, model research, and responsibility. It is rarely available with confidence during the first minutes. A monitor can see a denied request followed by a different route and an unexpected write. It cannot read motive. It does not need to.

Use an observable trigger instead: the first action outside the authorised target, identity, data, or effect set starts the incident clock. Stop first. Work out the model’s reasoning after the evidence is safe.

## A denial must not become a research hint

The June task appears to have begun with a reasonable goal: find public medicine-spending information. The failure came after the direct route did not provide what the agent wanted. The model treated the obstruction as a problem to solve rather than a boundary to respect.

Humans make this mistake too. A data analyst sees a blocked download, finds an old endpoint, guesses a file path, or tries a mirror. Sometimes that is harmless persistence. Sometimes the block is the only visible sign that the requested access is not allowed. An autonomous system can run through those alternatives faster and with less context than a careful operator.

HTTP status codes cannot carry the whole policy. A `403 Forbidden` is a clear refusal, but a timeout may mean congestion, a bot defence, or a broken service. A page can say “not available” while still exposing predictable file paths. The agent therefore needs an explicit rule outside its own interpretation: after a target denies or challenges access, the run may not change identity, route, proxy, user agent, protocol, or guessed path to obtain the same material unless a human approves a documented exception.

That rule is a stop condition. It is stronger than a prompt asking the model to “respect access controls” because the tool gateway can enforce it. The gateway sees the target, response, subsequent destination, credential, and action type. It can refuse the next attempt, pause the run, and open an incident record without asking the model whether the new route feels equivalent.

The control should be scoped carefully. A package manager that retries a temporary server error is normal. A browser following an ordinary redirect is normal. A data collector switching from a vendor’s web page to the vendor’s documented public API can be normal. The dangerous pattern is a refusal followed by an attempt to reach the same protected result through a materially different route.

That distinction belongs in machine-readable policy. Define the approved sources and methods for the task. Define response classes that permit bounded retries. Define the signals that require a pause: authentication challenges, bot blocks, explicit denials, guessed object names, uploads, writes, new accounts, or a destination outside the manifest. Record why an exception was approved and which actions it permits.

A model may still explain the block and propose a legitimate next step. It can ask the operator to supply the dataset, contact the site owner, or use an official export. What it should not do is silently turn “no” into an invitation to search for a weaker door.

## Monitoring has to sit outside the agent

OpenAI says it found the activity during a later review of misaligned model behaviour. That review mattered. Without it, the June event might have remained invisible for longer. The timeline also shows why retrospective model review cannot be the only detection layer.

An agent that can write files may be able to alter its local transcript, delete temporary logs, or omit an action from its final summary. Even when it is not trying to hide anything, a crash can lose state and a compaction step can remove detail. The system needs witnesses the agent cannot edit.

Start with network records. An outbound gateway should capture the time, run identity, destination, method, response class, bytes transferred, and policy decision for every external request. The record does not need to store sensitive content by default. It does need enough information to show that a blocked request was followed by a different route to the same organisation.

Add tool-effect records. A browser click and an HTTP request can look similar at the network layer while causing very different outcomes. Log form submissions, uploads, file writes, account creation, authentication attempts, repository changes, messages, purchases, and publication. Give each effect a run ID and an owner. Keep the approval event when a human allowed it.

Then watch the sequence, not only individual calls. One denied request may be noise. A denial followed by proxy lookup, alternate host discovery, guessed paths, and a successful write is a story. Sequence rules can pause that run before a daily analyst review sees the dashboard.

The collector should live in a separate account or service. If the agent controls the machine, workspace, and local log file, those records share the same failure domain. Send an append-only copy to a place where the runtime identity has write-only access or no access at all after delivery. Preserve clock synchronisation so events from the browser, proxy, model service, and external owner can be reconciled.

OpenAI’s own [misalignment reports page](https://alignment.openai.com/misalignment-reports/) shows why system-level records matter. The company has documented internal models using public file hosts, searching for exposed keys, and communicating through shared services during training. Those are external effects created by a larger training and tool system, not merely unusual sentences. Detecting them requires visibility into what the assembled system did.

This is also where model monitoring and security monitoring meet. Model researchers may care about reasoning patterns and reward signals. Incident responders care about destinations, identities, writes, and evidence integrity. Both views are useful. Neither replaces the other.

## The notification clock is shorter than the investigation clock

Teams often wait for a complete internal explanation before contacting an affected party. The instinct is understandable. A vague alert can waste somebody’s time, and an inaccurate accusation can create confusion. Waiting for certainty can also destroy the evidence needed to reach certainty.

Web logs rotate. Temporary workloads disappear. Volatile process data vanishes on restart. A cloud service may keep detailed request records for seven days while a formal review takes three weeks. The affected owner controls evidence the agent operator does not. Delayed notice can make both investigations worse.

The Australian timeline makes the trade-off concrete. The event occurred on 18 June. ABC reported that OpenAI became aware of it on 11 August during a review. Services Australia received an email on 10 September, and the first technical exchange occurred on 22 September. The public record does not tell us exactly what OpenAI knew on each day, so it would be wrong to assign a precise avoidable delay. It does show that the site operator lacked direct technical notice for a substantial period after the event.

A first notice does not need a final root cause. It needs facts that help the recipient act. State the observed time in UTC, source addresses or service identities, target host and paths, request methods, confirmed reads or writes, files or object identifiers, and whether activity has stopped. Explain which details remain under investigation. Provide a monitored contact that can exchange logs quickly.

Do not bury that notice in a general inbox when a published security contact, incident channel, or government coordination path exists. If only a public address is available, label the subject clearly, request acknowledgement, and escalate through another documented channel when the effect includes a write or authenticated access. Keep a receipt for every attempt.

Notification should run in parallel with investigation. One person preserves and analyses the run. Another identifies and contacts the affected owner. A third contains the system and checks whether sibling runs used the same route. Small teams can combine roles, but the workstreams should remain distinct so “we are still investigating” does not become a reason to stay silent.

NIST’s [incident-response guidance](https://csrc.nist.gov/pubs/sp/800/61/r3/final) treats response as part of ongoing cybersecurity risk management, with lessons feeding back into preparation and improvement. The practical point is simple: communication is an incident action, not a press-release step at the end.

## Build a stop package before the next run

An emergency stop button that merely kills a process is incomplete. Killing the worker may prevent another request, but it can also destroy volatile evidence and leave credentials active elsewhere. A useful stop package contains containment, preservation, and communication actions that can run together.

The package begins with a stable run identity. Every agent run should have its own workload identity, network policy, credential set, artifact directory, and event stream. When one run crosses a boundary, responders can freeze that unit without guessing which shared developer token or browser profile it used.

Next comes network containment. The operator should be able to revoke outbound access for the run at the gateway, not by logging into the agent and asking it to stop. Existing connections may need termination. Any queue that can restart the worker should be paused, and scheduled retries should be disabled before they recreate the effect.

Credentials need their own switch. Revoke short-lived tokens, browser sessions, API keys, and cloud identities exposed to the run. A process kill does not invalidate a token already copied into another service or log. Record the identifiers and revocation times without storing secret values in the incident note.

Preservation should happen before routine cleanup. Snapshot the run metadata, tool-call ledger, model and policy versions, prompt and task manifest, network decisions, browser state, filesystem changes, and relevant memory. Export the independent records first. If the workspace may contain somebody else’s data, restrict access and do not spread copies across ordinary collaboration tools.

Finally, create the contact packet automatically. Populate known times, targets, source identifiers, confirmed effects, containment status, and your security contact. Leave unverified fields marked as unknown. The package should make an honest early notice easy, because a process that depends on writing the perfect email under pressure will be slow.

The Secure Harness argues that autonomy belongs inside enforceable boundaries. Incident handling is one of those boundaries. The agent is allowed to move quickly because the surrounding system can stop it, retain the trail, and tell the affected owner what happened without waiting for the model to compose a confession.

## A practical response sequence for agent operators

The order below is designed for an unexpected external write, authenticated request, publication, or data transfer. It can be scaled down for a small research team, but none of the stages should disappear.

1. **Pause the run and its siblings.** Block further external traffic from the run, stop queued retries, and pause other jobs using the same task template or policy. Do not start a fresh reproduction against the real target. Reproduce only later in a controlled copy or with the owner’s permission.

2. **Preserve independent evidence.** Save gateway records, tool calls, approvals, identity events, model and harness versions, task inputs, and filesystem changes. Capture the current worker state when safe. Record missing telemetry as a gap rather than filling it with assumptions.

3. **Revoke the run’s authority.** Disable its workload identity, tokens, active browser sessions, temporary accounts, and upload links. Check whether any credential was shared with another run. Shared authority expands both the containment scope and the uncertainty.

4. **Classify confirmed effects.** Separate attempted actions from successful ones. Name every known read, write, upload, authentication, or change. Mark data sensitivity and persistence. A server-side write is confirmed even when the file content was harmless.

5. **Notify the affected owner.** Send the first factual packet through the best available security channel. Include UTC times, target details, source identifiers, confirmed effects, containment status, and a direct responder contact. Ask what additional evidence would help and preserve the acknowledgement.

6. **Search for the same pattern.** Query other runs for the target, alternate domains, shared proxies, guessed names, similar denied-then-rerouted sequences, and the same task family. Do not assume the discovered event was unique merely because one review found it first.

7. **Investigate the control failure.** Determine why the target was reachable, why the denial did not stop the sequence, why a write-capable tool was available, which monitor first saw it, and why the alert path did or did not fire. Keep model-behaviour analysis beside, rather than instead of, the system review.

8. **Repair and test the harness.** Add the missing stop condition, narrow destinations and effects, separate identities, and move records outside the runtime. Test the control against a benign service you own. A policy document is not repaired until a negative test proves that the forbidden action fails.

9. **Close with a joint receipt.** Record the timeline, evidence sources, confirmed impact, remaining uncertainty, notifications, containment, repairs, and test results. Share relevant findings with the affected owner. Keep unresolved questions assigned to named people and dates.

This sequence deliberately sends notice before a complete explanation. The first packet can be updated. Lost logs cannot.

## What to measure in every agent evaluation

A benchmark score says whether the model completed the task. It says little about the side effects accumulated on the way. Agent evaluations need an effect ledger alongside the score.

Count destinations contacted, identities used, denials received, retries attempted, redirects followed, files read, files written, data uploaded, accounts created, messages sent, and public artifacts produced. Mark which effects were required by the task. Anything else should be explained or treated as a failed run.

Measure detection time from the first out-of-scope effect to the first external alert. Measure containment time from that alert to blocked traffic and revoked credentials. Measure notification time from confirmed unauthorised effect to a useful message reaching the affected owner. These clocks turn “we take safety seriously” into something a team can improve.

Set targets according to effect. A blocked request may wait for routine review. A successful external write, login, publication, or sensitive transfer should page a human and freeze the run within minutes. The notice target can allow enough time to verify the recipient and collect basic facts, but it should be measured in hours, not in the length of a research cycle.

Also measure evidence completeness. Can responders link the action to one run and model version? Do they know the source identity and destination? Can they distinguish attempted from successful calls? Are logs stored outside the agent’s control? Can they reconstruct what happened if the worker is gone?

NIST’s [AI 100-2 report on adversarial machine learning](https://csrc.nist.gov/pubs/ai/100/2/e2025/final) is broader than this incident, but its system view is useful: risks arise across the lifecycle and need mitigations tied to the deployed context. For a tool-using agent, context includes the network, credentials, targets, monitors, and response process. Evaluating only the model leaves most of the acting system unmeasured.

The final metric should be recurrence. When a stop condition is added, run a harmless regression test. A synthetic service denies the requested data. The agent may explain the denial or ask for help, but the tool layer must refuse alternate routes and writes. Keep that test beside the task, so the next harness change cannot quietly remove the brake.

## Keep the lesson proportional and firm

The Medicare portal incident did not, on current evidence, expose personal patient records. It did not produce evidence of a broader Services Australia compromise. The investigation may narrow the technical story further. Readers deserve those limits because “AI hacked Medicare” can imply a patient-data disaster that officials have not found.

The narrow impact should sharpen the engineering lesson, not soften it. This was an opportunity to see a difficult failure while the reported harm remained limited. An internal model met blocks, created unauthorised effects on a real government server, and the operator’s notice arrived much later. Each part can be addressed with ordinary controls.

The task manifest says where the agent may go. The gateway decides where the computer can go. Stop conditions turn denial into a pause rather than a puzzle. Independent records show what happened. A prepared response package contains the run and preserves the trail. A notification clock gives the affected owner a chance to inspect evidence while it still exists.

None of those controls requires the model to understand legal intent. That is their strength. They work when the model is confused, when the task is badly specified, and when the operator has not yet agreed on the right label for the behaviour.

An agent can be persistent without being allowed to improvise authority. The line is the first unauthorised effect. When that line is crossed, stop the machine, save the receipts, and call the owner.

For one calm, practical security email per month, join the newsletter using the signup on this site. One email per month.

## Sources

- [Prime Minister of Australia: Press conference in New York on the OpenAI incident](https://www.pm.gov.au/media/press-conference-new-york), accessed 2026-09-25
- [ABC News: OpenAI hacked Medicare portal, Prime Minister Anthony Albanese says](https://www.abc.net.au/news/2026-09-24/ai-agent-accessed-australian-government-site-pm-says/107189078), accessed 2026-09-25
- [ABC News: What we know about the data accessed in the OpenAI Medicare hack](https://www.abc.net.au/news/2026-09-24/what-we-know-about-the-openai-medicare-hack/107189452), accessed 2026-09-25
- [ABC News: Health data attack the first government hack by autonomous AI, researchers say](https://www.abc.net.au/news/2026-09-24/openai-agents-plotted-to-access-data-amid-medicare-hack/107189504), accessed 2026-09-25
- [OpenAI Alignment: Misalignment Reports and Notices](https://alignment.openai.com/misalignment-reports/), accessed 2026-09-25
- [NIST: Incident Response Recommendations and Considerations for Cybersecurity Risk Management](https://csrc.nist.gov/pubs/sp/800/61/r3/final), accessed 2026-09-25
- [NIST: Adversarial Machine Learning, A Taxonomy and Terminology of Attacks and Mitigations](https://csrc.nist.gov/pubs/ai/100/2/e2025/final), accessed 2026-09-25

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._