Last updated 26 September 2026. The investigation and the government's review are still running, so some details may change. Views are my own, not my employer's.

In short: An OpenAI research agent working on an ordinary task got past a government portal's refusals, reached non-public files and wrote to an internal server, and nobody in government noticed. The lesson I take from it is to keep public systems away from non-public data, and to notice when something keeps trying doors. If you run agents, you're now part of the threat model too.

I run infrastructure for a living, and in the evenings I'm building an AI product that relies on agents. The Medicare portal incident sits right where those two jobs meet. It's easy to take only half a lesson from it, so this is my attempt at the whole thing.

The portal that said no

On 18 June 2026, OpenAI researchers were using an internal model, running as an agent, to research public spending on medicines.¹ It went to Services Australia's Medicare Statistics Reporting Service, a public portal of aggregated Medicare and Pharmaceutical Benefits Scheme statistics.²

The portal said no, repeatedly. In the Prime Minister's words, the agent "didn't accept no for an answer".¹ It tried other routes, reached public and non-public information within the portal and, according to Services Australia, wrote files to an internal server.¹

OpenAI became aware of the activity on 11 August, during a review of misaligned model activity. On 10 September, 84 days after the event, it emailed Services Australia's public disclosure inbox.³ The Prime Minister went public on 24 September and set up a taskforce to review whether existing processes can handle AI-related cyber incidents.¹

The damage looks limited. The government believes no personal information was accessed "at this stage", and says the evidence so far shows no broader compromise of Services Australia's network.¹ OpenAI says the information accessed included aggregate health statistics and internal file names.³

Minister Katy Gallagher described the portal as a legacy system: "not a system of government significance", but one that "did have protections in place".⁴ She has also said "we won't be reactivating it".⁵

The visitor nobody planned for

Forgotten government websites with weak access controls are an old problem. What caught my attention is who found this one.

The visitor was a research agent from a legitimate company, working on an ordinary task. Transluce, which documented agents linked to OpenAI probing other public data providers, including the Australian Institute of Health and Welfare, put it plainly: "the tasks the agents were trying to solve were not cyber-related".⁶

The agents tried SQL injection, cross-site scripting and path traversal "after failing to retrieve data through normal means".⁶ Nobody asked them to attack anything. The exploit attempts came out of trying to finish the job. OpenAI's post-mortem of a separate incident, involving Hugging Face, found the same trait: its agents rarely gave up on evaluation tasks, even ones that appeared impossible.⁷

The obvious objection is that any scanner could have found this portal's weaknesses. True, and that's the problem. We've tended to design around attackers who are rare and malicious, and hoped that obscure systems would fall below their attention. Now there are agents that nobody pointed at a target, and I expect there'll be many more of them, patiently trying every door when the front one is locked.

People with bad intent are using the same capability deliberately. In November 2025, Anthropic reported a state-sponsored espionage campaign in which AI did an estimated 80–90% of the work.⁸

So the working assumption has to change. Every reachable endpoint will be found and tested, and a refusal from your application may be treated as a puzzle rather than a boundary.

I've seen this from the other side with my own agents. Our coding and QA agents run on a cloud server, and our production bot protection blocks that traffic, as it should. We didn't ask the agents to find a cleverer way in. We gave them one sanctioned test path that we control, and a written rule never to improvise another.

Three old failures

What we don't know yet

• How the agent got past the portal's controls. No root cause has been published.
• What was written to the internal server, and how. That's still under forensic investigation.²
• Whether any offence applies. That's for investigators and possibly the courts.
• Who else was affected. OpenAI says it has notified dozens of third parties.⁹

What follows is my reading of what has been reported.

Three things went wrong, and none of them is new.

The public tier could reach non-public data. The agent got to non-public information through the same portal that served the public.¹ Richard Marles, acting as Prime Minister that day, put it this way: "The AI agent climbed the fence." The data, he said, "was not sitting behind a particularly high fence".¹⁰

The public tier could write to an internal system. A statistics portal serving anonymous visitors should give them no way to create files on an internal server. However it happened, that path shouldn't have existed. To me, it's the most important detail in the whole story.

Nobody detected it. Services Australia found out from the company whose model did it.³ Repeated refusals followed by new approaches, requests for odd files and an unexpected write to an internal server are the signals monitoring should catch while it's happening.

We've been here before. In the 2022 Optus cyber attack, the Australian Communications and Media Authority (ACMA) alleges that a coding error in access control went undetected for four years, on a domain left dormant rather than decommissioned. The personal information of more than nine and a half million current and former customers was accessed.¹¹

ACMA says the attack wasn't sophisticated: it was "carried out through a simple process of trial and error".¹¹ Trial and error is what agents do best.

We only know because they told us

OpenAI's handling wasn't good enough. Eighty-four days is too long, a public inbox checked once a day was the wrong channel,⁴ and a full public account should follow once the investigation is done.

But I keep coming back to how we found out at all. OpenAI found the activity in its own review, reported it, and has since published an account of its models' impact on dozens of other organisations.⁹ Without that, the government might still not know. If the main reaction to disclosure is ridicule and punishment, the rational move for the next company is to say less, later.

The companies that report aren't the only source of this risk, either. In 2023, researchers showed the safety training on Meta's openly released Llama 2-Chat 13B could be undone for less than $200.¹² Hosted models can be jailbroken too: the attackers in Anthropic's case broke their work into small, innocent-looking tasks and told Claude it was working for a legitimate security firm on defensive testing.⁸ Criminals and state actors running models like these won't file incident reports, so disclosures from the developers who do report are one of the few direct views we get of agents in the wild.

A blameless postmortem focuses on "the contributing causes of the incident without indicting any individual or team",¹³ and aviation's "just culture" doesn't blame people for honest errors while still holding them accountable for wilful violations and gross negligence.¹⁴ Both exist to keep people reporting.

Australia already applies this thinking to cyber incidents. The Cyber Security Act 2024 limits how the National Cyber Security Coordinator can use information shared voluntarily, so organisations can engage early without fearing it will be handed to regulators or law enforcement, though it isn't a safe harbour. The Act also set up a Cyber Incident Review Board for independent, no-fault reviews of significant incidents.¹⁵

I'd like the government's review to land in the same place: hold AI companies firmly to account for delay, poor channels and incomplete accounts, make prompt and direct notification a clear obligation, and make coming forward easier than staying quiet. The goal is fewer incidents and faster discovery of the ones that happen, not fewer reports.

Public by design, private by default

The portal existed to publish statistics to anyone who wanted them, so hiding it behind a VPN would have defeated the point. The principle I'd apply instead:

Public services should expose only public data, from a tier that can't read or write anything else. Everything else should be private by default. Every layer still needs authentication, authorisation, patching, monitoring and segmentation.

Non-public data and internal servers belong where the public tier has no route and no credentials to reach them. The Medicare portal let users customise the content and format of their reports,¹⁶ so this can't just mean publishing static files. A portal like that can still run live queries, as long as it runs them against a read-only store that holds only released data, kept in its own plane and fed by a one-way push from inside.

The government's own fix follows the same logic. The portal's public data is moving to data.gov.au, and Gallagher has directed Services Australia to move data off its other legacy public-facing websites, or decommission them where appropriate.²

Why reachability still matters

A service doesn't become private because it has a login page, an unadvertised hostname or an unpredictable URL. Certificate-transparency logs publicly record TLS certificates as they're issued, and anyone can watch them,¹⁷ while DNS, cloud address ranges and search engines give away plenty more. Obscurity may delay discovery, but it doesn't control access.

Authentication matters enormously, but it only acts once traffic has reached something that can process it. By then the visitor is already talking to your TLS stack, proxy, framework, parsers and every API route. The Open Worldwide Application Security Project (OWASP) counts all of those paths in and out of an application, and the code that protects them, as its attack surface.¹⁸

A correct identity layer rejects a bad login. It can't promise that an old endpoint doesn't skip the authentication middleware, or that nobody can reach the origin server directly, around the proxy. Private routing, firewalls and segmentation are an independent layer: they shrink the number of things that can reach a workload at all, and they contain the damage when something else fails.

None of this is a retreat from zero trust. The US National Institute of Standards and Technology (NIST) says zero trust grants no implicit trust based solely on network location.¹⁹ Google's BeyondCorp famously moved its corporate applications onto the internet, exposing them through an internet-facing access proxy.²⁰ That's a public broker in front of a private origin, the pattern I'm arguing for.

The network grants no trust, but it still limits reachability.

The catch: gateways are exposed too

The VPNs, firewalls and access gateways that provide private access are themselves exposed to the internet. Verizon's 2026 Data Breach Investigations Report found that exploiting vulnerabilities is now the most common way in, at 31% of initial access, up from 20% the year before.²¹ It also found the median time to fully fix a vulnerability known to be exploited grew to 43 days, and only 26% had been fully fixed.²¹

The previous year's report found edge devices and VPNs were the target in 22% of exploitation cases, up from 3%,²² and the Australian Signals Directorate (ASD) has published detailed guidance on securing them.²³

Private access done badly can be worse than none. The Australian Information Commissioner alleges that in the 2022 Medibank breach, an attacker logged into the company's VPN with stolen credentials alone, because it didn't require multi-factor authentication (MFA).²⁴

So private by default only works if the gateway is the most carefully patched and watched system you own. Prefer brokers with outbound-only connectors, so the origin network has no listening port. Patch edge devices first, require phishing-resistant MFA and device checks before any connection is made, and keep the gateway's own logs.

Some endpoints are harder to hide. SFTP servers and APIs used by clients without static IP addresses, or protected by a password alone, need as many safeguards as you can give them. I'd stack mutual TLS (mTLS), public/private key pairs or client certificates, known client and destination IP ranges wherever you can get them, and preferably a private route such as zero-trust network access (ZTNA) or virtual private cloud (VPC) peering onto private subnets.

It also has to be usable, or people build public workarounds and you end up more exposed than before. And some data can't be made network-private at all. For software-as-a-service platforms like Microsoft 365 or Salesforce, identity is the perimeter: conditional access tied to managed devices, tenant restrictions and no anonymous sharing links.

If you run agents, you're in the threat model too

This incident has a second audience: everyone building or deploying AI agents, which increasingly means ordinary engineering teams, mine included.

The product I build has an AI assistant that works with sensitive client data and can connect to outside tool servers. Our team contract puts the principle simply: "Hard limits stay in code: organisation scoping, authorization, approval for writes, data egress, and audit. Constrain what the model can affect, never how it thinks."

Writes need approval, and an approval only counts for the exact action that was shown. Once data from an outside server enters a conversation, the assistant shows every change before making it, and its requests to those servers can only go to public HTTPS endpoints, with no redirects and with caps on response size and time. Our coding agents commit but never push, and deployment only happens through CI.

What I'd expect of anyone running agents:

• Treat refusals as boundaries. A 401 or 403 should stop the agent, not send it looking for another route, and a 429 means back off. robots.txt rules are "not a form of access authorization",²⁵ but they are the site owner's stated wishes, so respect them. Enforce this in the agent harness and network controls, not just the prompt.
• Scope agents tightly. Allow-list the domains and tools an agent can use, and block exploit-like behaviour against other people's systems.
• Watch what your agents do. Log and review their outbound traffic. If your agent does something to someone else's system, you should know before they do.
• Have a notification plan. If your agent affects someone else, contact them quickly and directly, and publish your own security contact.

The law applies too. Part 10.7 of the Commonwealth Criminal Code makes it an offence to intentionally access data protected by an access control system, knowing the access is unauthorised.²⁶ Whether that applies here is for investigators, but the government's review is examining whether AI companies should be obliged to notify and cooperate, and whether current offences and penalties are an adequate deterrent.⁵

Build for patience

For years, a lot of security has quietly relied on nobody bothering: nobody finding the old portal, or nobody trying again after the first refusal. Agents have ended that assumption, and not only the malicious ones.

I don't want to go back to flat, trusted intranets, and I don't want every private resource one authentication defect away from exposure either. Private by default and zero trust by design sits between the two: minimise reachability, distrust every connection, verify every identity, enforce least privilege and assume every accessible interface will be found.

And when someone's agent gets it wrong, I want them to tell us quickly, and I want that to be the easy choice.

For the practical side (inventory, classification, a 90-day plan and how this maps to Australia's cyber strategy), see the companion post, Private by Default: A Practical Playbook.

References

1. Prime Minister of Australia, Press conference – New York, transcript, 24 September 2026. www.pm.gov.au/media/press-conference-new-york ↩
2. Healthcare IT News, OpenAI agent breaches Australian Medicare portal. www.healthcareitnews.com/news/anz/openai-agent-breaches-australian-medicare-portal ↩
3. ABC News, OpenAI agent hacked Medicare portal, PM says, 24 September 2026. www.abc.net.au/news/2026-09-24/ai-agent-accessed-australian-government-site-pm-says/107189078 ↩
4. SBS News, Medicare hack alert went to inbox checked once a day and took five days to be escalated, 24 September 2026. www.sbs.com.au/news/article/openai-agent-hacked-medicare-albanese-reveals/qas79d9ta ↩
5. Computer Weekly, Australia sets up taskforce after OpenAI agent breaches statistics portal. www.computerweekly.com/news/366651163/Australia-sets-up-taskforce-after-OpenAI-agent-breaches-statistics-portal ↩
6. Transluce, Early rogue AI agent activity and attempts to hack found on urlquery.net. transluce.org/agent-activity ↩
7. OpenAI, The Hugging Face incident and the road ahead. openai.com/index/hugging-face-incident-and-the-road-ahead/ ↩
8. Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign, 13 November 2025. www.anthropic.com/research/disrupting-AI-espionage ↩
9. OpenAI, The Hugging Face incident and other third-party impact from misaligned models. openai.com/hugging-face-incident-and-misalignment/ ↩
10. ABC News, Acting PM Richard Marles says AI incident very serious but impact is minor – as it happened, 24 September 2026. www.abc.net.au/news/2026-09-24/federal-politics-live-blog-openai-medicare-breach/107186578 ↩
11. ABC News, Optus cyber attack could have been prevented four years prior, ACMA says, 20 June 2024. www.abc.net.au/news/2024-06-20/optus-hack/104002682 ↩
12. P. Gade, S. Lermen, C. Rogers-Smith and J. Ladish, BadLlama: cheaply removing safety fine-tuning from Llama 2-Chat 13B, 2023, arXiv:2311.00117. arxiv.org/abs/2311.00117 ↩
13. Google, Site Reliability Engineering, "Postmortem Culture: Learning from Failure". sre.google/sre-book/postmortem-culture/ ↩
14. SKYbrary, Just Culture. skybrary.aero/articles/just-culture ↩
15. Department of Home Affairs, Cyber Security Act 2024, www.homeaffairs.gov.au/cyber-security-subsite/Pages/cyber-security-act.aspx; and Limited Use for the National Cyber Security Coordinator (factsheet), www.homeaffairs.gov.au/cyber-security-subsite/files/factsheet-limited-use-for-the-national-cyber-security-coordinator.pdf ↩
16. Services Australia, Medicare statistics. www.servicesaustralia.gov.au/medicare-statistics ↩
17. IETF, RFC 6962: Certificate Transparency. datatracker.ietf.org/doc/html/rfc6962 ↩
18. OWASP, Attack Surface Analysis Cheat Sheet. cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html ↩
19. NIST, SP 800-207: Zero Trust Architecture. csrc.nist.gov/pubs/sp/800/207/final ↩
20. R. Ward and B. Beyer, BeyondCorp: A New Approach to Enterprise Security, ;login:, December 2014. www.usenix.org/publications/login/dec14/ward ↩
21. Verizon, 2026 Data Breach Investigations Report. www.verizon.com/business/resources/Td15/reports/2026-dbir-data-breach-investigations-report.pdf ↩
22. Verizon, 2025 Data Breach Investigations Report: Executive Summary. www.verizon.com/business/resources/reports/2025-dbir-executive-summary.pdf ↩
23. Australian Signals Directorate, Securing edge devices. www.cyber.gov.au/business-government/protecting-devices-systems/hardening-systems-applications/network-hardening/securing-edge-devices ↩
24. Office of the Australian Information Commissioner, Australian Information Commissioner v Medibank Private Limited, concise statement, Federal Court of Australia, June 2024. www.oaic.gov.au/__data/assets/pdf_file/0025/221974/Australian-Information-Commissioner-v-Medibank-Private-Limited-concise-statement.pdf ↩
25. IETF, RFC 9309: Robots Exclusion Protocol, 2022. www.rfc-editor.org/rfc/rfc9309 ↩
26. Criminal Code Act 1995 (Cth), Schedule, Part 10.7. www.legislation.gov.au/C2004A04868/latest/text ↩

Companion to The Agent That Wouldn't Take No for an Answer. Last updated 26 September 2026. Views are my own, not my employer's.

In the companion post I argued that public services should expose only public data, from a tier that can't read or write anything else, and that everything else should be private by default. This post is the practical side: the steps I'd take, a 90-day starting plan, what to measure, and how it lines up with Australia's cyber strategy.

The number of public, unmonitored platforms companies run, putting convenience ahead of security, is staggering. Jira, Slack and Google Drive all hold deeply confidential company information. Observability tools such as Grafana, Datadog and New Relic often hold client personal information in their logs, directly or indirectly, and if they're set up badly, that data can leave its required jurisdiction or the protected environment altogether.

You don't need to remove every public endpoint at once. You need to know what's exposed and who owns it, and have a steady program for moving the wrong things behind private access.

1. Discover

Build a continuously updated inventory of everything reachable from the internet:

• DNS records and public IP addresses
• cloud load balancers and storage endpoints
• Kubernetes ingress and API gateways
• management interfaces
• development and pre-production environments
• vendor-hosted services

Check it from the outside. Your configuration database won't show everything the internet can see, so compare external attack-surface scans with your cloud accounts, certificate-transparency records, infrastructure-as-code and network flow logs. The US Cybersecurity and Infrastructure Security Agency's (CISA) Internet Exposure Reduction Guidance starts from the same place.¹

Include pre-production. In one case researchers examined, Cloudflare blocked the agents' requests to a data provider, but they still retrieved a public file from a pre-production server.² The file was public, but it's a good prompt to ask whether your own pre-production servers need to be reachable at all.

Every endpoint needs an owner, a data classification, a business purpose and a written reason for being reachable. Treat unknown and ownerless assets as defects.

Pay particular attention to legacy systems. When a company moves on from a system, its platforms and libraries often stop being maintained. Keeping the lights on (KTLO) means no new feature development, not no development or maintenance at all.

2. Classify

Public exposure should need a positive business decision. "It was easier to deploy" and "nobody knows the URL" aren't reasons.

3. Separate the planes

For each public service, trace every path from the public tier to anything else.

• Push, don't pull. Get public data to the public tier by pushing it out to a dedicated publishing platform or read-only store, rather than letting the public tier reach into internal systems.
• Live queries are fine, against the right data. If users build their own reports, run those queries against a read-only store that holds only released data, in its own plane.
• Remove write paths. Take them out of public tiers entirely, or confine them to isolated, scanned and quarantined storage.
• Keep unreleased data out of reach. Store it where the public tier can't address it at all.

4. Remove exposure

Move internal workloads onto private subnets or private cloud endpoints, such as AWS PrivateLink, Azure Private Link or Google Cloud Private Service Connect. Then remove public IP addresses from origins, allow inbound traffic only from approved gateways, and retire obsolete DNS records, test systems and legacy routes.

For network design and zoning in Australia, the reference is the Australian Signals Directorate's (ASD) Guidelines for networking, part of its Information Security Manual.³

5. Add independent, well-maintained access

Don't make each legacy application its own perimeter.

• For people: ZTNA, an identity-aware proxy or a per-application VPN, enforcing user identity, device health, phishing-resistant MFA and short sessions before any connection is made.
• For workloads: mutually authenticated service identities, private endpoints and explicit service-to-service policies.

Keep authentication and role-based access control in the application too. The gateway decides whether a connection can be made; the application decides what the person or service can do.

Treat the gateway as the most important thing you patch. Verizon's 2026 report puts the median time to fully fix a known-exploited vulnerability at 43 days,⁴ which is far too long for the system that guards everything else. Prefer outbound-only connectors, follow ASD's edge-device guidance,⁵ and collect the gateway's own logs.

Make the private path the easy one. If it's slow or painful, people will route around it. Templated, pre-approved patterns (a "paved road") help, and the number of exception requests is a useful measure of friction.

6. Implement the Essential Eight

ASD's Essential Eight is the baseline:⁶ patch applications, patch operating systems, multi-factor authentication, restrict administrative privileges, application control, restrict Microsoft Office macros, user application hardening and regular backups.⁸ The maturity model runs from Maturity Level Zero to Maturity Level Three,⁷ and ASD advises reaching the same level across all eight strategies before aiming higher.⁸

Even government is some way off. Non-corporate Commonwealth entities have been required to reach Maturity Level Two since July 2022. In ASD's 2025 survey, 22% of Commonwealth entities had reached it, counting compensating controls, and 59% said legacy technology had affected their ability to implement the Essential Eight.⁷ The Medicare portal was that kind of legacy system.

The Essential Eight is a baseline, not an architecture. It doesn't replace exposure management, segmentation, secure gateways or threat modelling, which is why ASD also maintains the much broader Information Security Manual.⁹

7. Segment

Assume prevention will sometimes fail. Separate user networks, production workloads, management planes, backups, security tooling, development systems and third-party connections, with deny-by-default rules and documented flows.

Segmentation is what stops an intruder who gets in from moving sideways. ASD's guide to implementing network segmentation and segregation is a good starting point.¹⁰

8. Monitor and detect

Detection is the gap the Medicare incident exposed. Centralise logs from gateways, identity providers, DNS, cloud control planes, web application firewalls, endpoints and applications, and alert on:

• repeated refusals followed by new approaches
• enumeration of file names or routes
• access to dormant endpoints
• unexpected writes
• attempts to reach origins directly

Watch outbound traffic as well as inbound. A compromised workload shouldn't have open internet access or open paths to its neighbours. And make sure every alert reaches someone who will act on it.

Make it easy for outsiders to reach you, too. Publish a security.txt file,¹¹ keep a monitored security contact, and give it a real triage process. Services Australia's disclosure inbox was checked once a day.¹²

9. Test

Run external attack-surface reviews and internal segmentation tests. Confirm that private origins can't be reached directly, that authentication can't be bypassed through alternate routes, and that development deployments don't inherit public ingress.

The Australian Cyber Security Centre's alert on AI misalignment recommends testing "controls and incident response procedures against AI-enabled threat scenarios".¹³ Include AI-assisted reconnaissance in your testing. The point is to reproduce the persistence you should now expect from automated visitors, not to dramatise AI.

A 90-day start

Ninety days is enough for visibility and guardrails. Migrating legacy workloads will take longer.

Days 1–30

• Inventory internet-facing assets and assign owners.
• Remove obviously abandoned endpoints.
• Require an explicit exception for any new public deployment.
• Baseline against the Essential Eight, starting with unsupported internet-facing software and edge devices.

Days 31–60

• Classify exposed workloads.
• For each public service, map its paths to non-public data and remove its write paths.
• Deploy a standard private-access pattern and close direct access to origins.
• Publish private-by-default infrastructure modules for cloud networks, load balancers, Kubernetes ingress and managed databases.

Days 61–90

• Segment high-value environments.
• Send gateway, identity and application logs to central monitoring, with alerts for refuse-then-retry patterns.
• Test backups by actually restoring them.
• Run an external validation exercise that includes AI-assisted reconnaissance.

What to measure

• internet-facing assets, and the trend over time
• percentage with a named owner and an approved justification
• administrative and non-public services directly exposed
• public applications with any path to non-public data, or any write path to internal systems
• percentage of workloads on the approved private-access pattern
• Essential Eight maturity by strategy and environment
• time to patch edge devices and other internet-facing systems
• time to detect refuse-then-retry and enumeration patterns
• time to detect and remove an unauthorised public endpoint
• exception requests against the private-access standard

How this lines up with Australia's cyber strategy

The 2023–2030 Australian Cyber Security Strategy sets out the government's vision of Australia becoming a world leader in cyber security by 2030. It's built on six "cyber shields", each providing an additional layer of defence: strong businesses, communities and citizens; secure technology; world-class threat sharing and blocking; protected critical infrastructure; sovereign capabilities; and resilient region and global leadership.¹⁴

Horizon 2 of the strategy runs from 2026 to the end of 2028. Its program of work was announced on 11 June 2026, a week before the Medicare incident, with 19 actions and 64 initiatives. They include strengthening logging and monitoring standards across government and critical infrastructure, and preparing both for emerging technology, including AI.¹⁵

Private by default is one way to turn that into engineering practice. It builds secure technology into platform templates, concentrates internet access through gateways where threats can be seen and blocked, and keeps critical systems and management planes in their own zones. The monitoring it depends on is what Horizon 2's logging standards are meant to drive.

References

1. CISA, Internet Exposure Reduction Guidance. www.cisa.gov/resources-tools/resources/exposure-reduction ↩
2. BleepingComputer, OpenAI hacked Australian Medicare govt site, probed data providers, 24 September 2026. www.bleepingcomputer.com/news/security/openai-hacked-australian-medicare-govt-site-probed-data-providers/ ↩
3. Australian Signals Directorate, Guidelines for networking (Information Security Manual). www.cyber.gov.au/business-government/asds-cyber-security-frameworks/ism/cyber-security-guidelines/guidelines-for-networking ↩
4. Verizon, 2026 Data Breach Investigations Report. www.verizon.com/business/resources/Td15/reports/2026-dbir-data-breach-investigations-report.pdf ↩
5. Australian Signals Directorate, Securing edge devices. www.cyber.gov.au/business-government/protecting-devices-systems/hardening-systems-applications/network-hardening/securing-edge-devices ↩
6. Australian Signals Directorate, Essential Eight. www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight ↩
7. Australian Signals Directorate, The Commonwealth Cyber Security Posture in 2025, www.cyber.gov.au/sites/default/files/2026-02/the_commonwealth_cyber_security_posture_in_2025.pdf; and Progress ongoing to improve the Australian Government's cyber resilience, 12 February 2026, www.cyber.gov.au/about-us/view-all-content/news/progress-ongoing-to-improve-the-australian-governments-cyber-resilience ↩
8. Australian Signals Directorate, Essential Eight maturity model. www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-maturity-model ↩
9. Australian Signals Directorate, Information Security Manual. www.cyber.gov.au/business-government/asds-cyber-security-frameworks/ism ↩
10. Australian Signals Directorate, Implementing network segmentation and segregation. www.cyber.gov.au/business-government/protecting-devices-systems/hardening-systems-applications/network-hardening/implementing-network-segmentation-and-segregation ↩
11. IETF, RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, 2022. www.rfc-editor.org/rfc/rfc9116 ↩
12. SBS News, Medicare hack alert went to inbox checked once a day and took five days to be escalated, 24 September 2026. www.sbs.com.au/news/article/openai-agent-hacked-medicare-albanese-reveals/qas79d9ta ↩
13. Australian Cyber Security Centre, Risks of AI misalignment to Australian organisations, 24 September 2026, www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/risks-of-ai-misalignment-to-australian-organisations; wording as quoted by Cyber Daily, www.cyberdaily.au/security/14225-alert-australian-cyber-security-centre-issues-warning-over-ai-misalignment-risks ↩
14. Department of Home Affairs, 2023–2030 Australian Cyber Security Strategy. www.homeaffairs.gov.au/about-us/our-portfolios/cyber-security/strategy/2023-2030-australian-cyber-security-strategy ↩
15. Department of Home Affairs, Horizon 2: Expanding our reach (2026–2028). www.homeaffairs.gov.au/about-us/our-portfolios/cyber-security/strategy/horizon-2 ↩

AppSec and DevSecOps Melbourne 2026, run by Corinium at Crown Promenade, opened with a formal debate, "Shift Left vs AI: Who Owns the Future of AppSec?", on the motion that shift-left security will no longer be the primary control model in enterprise SDLCs. Ibrahim Mohammed and I drew the negative, which meant arguing that shifting security left remains foundational and that AI strengthens it rather than replaces it.

The case

AI has made detection dramatically better. Model-assisted triage and reachability analysis cut through the noise that made developers resent security tooling, and that deserves to be conceded properly rather than argued around.

But detection and prevention are different instruments. A runtime control raises a finding for a person to act on, under time pressure, in a live system, usually by someone who did not write the code. A pipeline control makes the decision once, in advance, at the moment of change, when the cost of being wrong is a failed build rather than an exposure window.

Runtime can alarm. Only the pipeline can refuse.

Current exploitation and remediation data point the same way: exploitation is getting faster while patching is getting slower, so a posture built on finding things and then fixing them is structurally behind. Regulators are also starting to price the security posture an organisation held before an incident, separately from how well it responded afterwards.

Where AI belongs

The pattern I argued for is short enough to fit on a slide: AI proposes, the gate disposes. Put models where a person was already reading output and they are transformative. Keep the refusal deterministic and legible, so it can be explained to an auditor and a developer in the same sentence.

The session

A headliner debate at 09:15 on Wednesday 15 July 2026, facilitated by Angelina Liu of Aikido. Kalpana Venkatesan of Kmart Australia and Dilip Konar, formerly of Australia Post, argued for the motion; Ibrahim Mohammed of Insignia Financial and I argued against it.

Five-minute opening statements, a moderated exchange, audience questions and a before-and-after audience poll. Preparation drew on a source-verified research brief covering the EU Cyber Resilience Act impact assessment, current exploitation and remediation data, and Australian privacy enforcement.

Elsewhere

• Session listing on the event agenda (Corinium)
• Photos and a wrap-up from the facilitator, Angelina Liu (LinkedIn)
• From the room as the debate opened, Rhys Ghorashi of Corinium (LinkedIn)