Found Out Last: What the Medicare Breach Says About Vendor Risk

Every AI tool a growing technology company adopts is also a third party it now depends on to flag its own failures. Recent governance research puts a number on how exposed this leaves organisations more broadly: across senior decision-makers surveyed in eight countries including Australia, nearly a quarter name third-party AI risk as a coordination challenge, and almost three in ten report vendor or third-party AI exposure at least twice in the past year. The Australia-specific finding is arguably more telling,  Australian respondents reported the highest combined rate of "reactive and fragmented" or "slow and manual" AI governance of any country in the survey [4]. Adoption is outrunning the oversight built to catch problems once they surface and the gap widens every time a new agent, model or platform gets plugged into the stack. 

This is the pattern behind where risk architecture is actually falling behind: not one bad actor or one careless vendor, but growth adding dependencies faster than governance can track them. Every new AI dependency adds a party whose disclosure discipline can't be audited in advance and whose timeline can't be controlled invisibly, until an incident makes the gap visible all at once.

The Medicare incident is also a live test of how cyber policies define the moment cover engages. Older wordings lean on intent and identity; an external attacker, a deceived employee, malware.  An AI agent carrying out a task it was authorised to attempt, that found its own way around the access controls placed in front of it, doesn't sit neatly inside any of those categories [1][2]. 

One Sydney-based cyber insurance leader, quoted on the incident, argued the more durable test asks what happened rather than what was intended: whether access was authorised by the insured, not what was in the mind of whoever or whatever obtained it [2]. Wordings still anchored to malicious or deliberate conduct risk becoming outdated as autonomous systems increasingly produce outcomes nobody specifically instructed. Whether a given policy actually responds to a specific incident depends on its exact wording and the facts at hand — and that's a conversation for a broker who has read the schedule, not a general rule anyone can apply from the outside.

There's no public confirmation that personal information was accessed in the Medicare incident, or that it has triggered Australia's Notifiable Data Breaches scheme. What follows describes how the scheme's timing generally works — it isn't a claim about how it applies to this specific case. 

Under the Australia’s notifiable data breaches scheme, an organisation that suspects an eligible data breach must take reasonable steps to assess it within 30 calendar days — a duty to assess promptly, not an automatic notification deadline. That 30-day clock starts when the organisation becomes aware of grounds for suspicion, not when the underlying intrusion actually occurred [3].  

Cyber policy notification requirements vary depending on the specific wording. When an organisation is required to notify and whose knowledge triggers that obligation will depend on the policy terms and the circumstances of the incident. 

None of this is solved by better wording alone. It's solved by treating vendor notification as a governance input to design for, not a gap to discover after the fact. This includes: 

• Contract clauses that set a maximum disclosure window with AI vendors 
• Incident response plans that name what happens when a third party is the one who finds the problem 
• A cyber and management liability program mapped against the dependency chain a business has actually built — not the one it had when the policy was last renewed 

That mapping work — vendor by vendor, agent by agent — is where a broker's role changes from renewing a schedule to actively closing the gap between how fast a business adopts AI and how fast it can see trouble inside it. 

Third-party AI risk architecture is the set of contractual, governance and insurance arrangements that determine how quickly an organisation learns about, assesses and responds to an incident caused or discovered by a vendor's AI tool or agent, rather than its own systems. As adoption grows, Australian organisations report some of the least mature governance of any country surveyed,  slower, more manual and more reactive, even as vendor and third-party AI exposure is a widespread, common challenge globally [4].  The gap between how fast a business adopts AI tools and how fast it can see problems inside them becomes a major driver of notification delay, regulatory exposure, and whether a cyber policy responds the way an organisation expects.

Most of the commentary on this incident will end up debating wording: was the access authorised, was it deliberate, does the policy respond. That's a real conversation, but it's the wrong one to have first. A business still arguing about wording after an incident is already too late — the moment that mattered has passed. 

We'd rather have that conversation before the incident, not after — the disclosure window in your vendor contracts, the incident response plan, the cyber and management liability programme built around the AI tools you're actually running today. That's not a better wording. It's a better way to manage risk. That's the forerunner's edge. 

1. Does a standard cyber policy respond to an incident caused by a third-party AI agent? 

It depends on the specific wording — including how “unauthorised access” and “insured” are defined — and on the facts of the incident. Some wordings test the outcome (was access authorised), others still lean on intent or a human threat actor. This is worth confirming directly with a broker against the actual policy schedule, not assumed either way. 

2. When does the notification clock start under Australia's Notifiable Data Breaches scheme? 

The 30-day assessment period starts on the day an organisation becomes aware of information giving it reasonable grounds to suspect an eligible data breach, not on the date the breach itself occurred [3]. It's an obligation to take reasonable steps to complete that assessment within 30 days, not an automatic 30-day notification deadline [3]. 

3. Can a business be penalised for a delay caused by a vendor's slow disclosure? 

An organisation’s notification obligations will generally depend on when it becomes aware of information giving it reasonable grounds to suspect or believe a notifiable breach has occurred. However, delayed disclosure by a vendor does not remove the organisation’s responsibility to maintain appropriate monitoring and incident-response arrangements. 

4. Is this only a risk for companies using generative AI chatbots? 

No. The same dependency exists anywhere a business relies on a third-party platform, plugin or automated agent that can access its systems or data. The Medicare incident happens to involve a generative AI research agent, but the underlying structure — a vendor controls the moment of discovery — applies more broadly to third-party and supply-chain risk.

5. What can a technology company actually do about a dependency it doesn't control? 

Build the dependency into governance deliberately: contractual disclosure windows with AI vendors, incident response plans that cover third-party-discovered incidents, and a cyber and management liability program reviewed against the current vendor stack rather than the one in place at the last renewal. 

6. Does having cyber insurance remove the need for a governance response? 

No. Insurance responds to a defined set of triggers under a specific wording. It doesn't replace the governance work of knowing which vendors sit inside a business's systems, or setting expectations for how fast they need to say something when it matters. 

7. Who is actually accountable if a vendor's AI tool causes the incident? 

Generally speaking and subject to the specific facts and contract terms — accountability doesn't automatically shift to the vendor simply because its tool caused the outcome. The organisation that adopted the tool retains its own governance, privacy and (where relevant) regulatory obligations, separate from whatever it may be able to recover from the vendor afterwards. 

[1] ABC News, “OpenAI hacked Medicare portal, Prime Minister Anthony Albanese says” (24 September 2026). 

[2] Insurance Business Australia, “Medicare AI breach tests how cyber wordings define unauthorised access” (24 September 2026) — source article supplied by content owner. 

[3] Office of the Australian Information Commissioner, “Part 4: Notifiable Data Breach (NDB) Scheme.” 

[4] OneTrust 2026 AI-Ready Governance Report (Sapio Research survey), reported via SMBtech (September 2026). 

DISCLAIMER: This information is provided to assist you in understanding the risks, implications, and common considerations for your industry. It does not constitute advice and is not complete. Please contact Knightcorp Insurance Brokers for further information.