Outsourcing the AI does not outsource the risk. You are still the pilot, even when someone else built the autopilot.
In April 2026, APRA told Australia’s banks, insurers and super funds plainly: the AI risk most likely to hurt them first isn’t the model they built — it’s the one they didn’t know they were using.
Days later, a compromised employee account at an AI tooling vendor called Context.ai gave attackers a path straight into Vercel, a platform a huge share of the AI development ecosystem relies on. Neither organisation signed up for the other’s failure. That’s the point.
The 30-second take
Your AI risk assessment stops where your vendor’s contract starts — and that’s exactly where APRA, and a growing list of real-world breaches, say the risk actually lives.
A signed-off checklist from a supplier is not evidence; it’s a starting point.
Organisations remain accountable for AI embedded in vendor platforms, including the vendors your vendors use. If you can’t map it, test it, and walk away from it when needed, you don’t control it.
APRA names third-party AI risk as the biggest gap
Using a third-party AI vendor or model is like flying an aircraft with an externally developed autopilot system. You may not have designed the system or understand every line of its code, but you remain responsible for:
- deciding when it can be used;
- checking that it is fit for the journey;
- monitoring how it behaves;
- recognising when it is going off course; and
- taking manual control when something fails.
The vendor supplies the technology, but your organisation carries the passengers, owns the decision and bears the consequences.
On 30 April 2026, APRA wrote to all regulated entities with the findings of a targeted supervisory review of large banks, insurers and superannuation trustees. Third-party and supply chain risk was one of four themes it called out directly, alongside AI governance and assurance. APRA’s own language was blunt: AI is often embedded in vendor platforms with opaque upstream dependencies and limited transparency until something fails.
The practical trigger is CPS 230. Many AI providers now meet the material service provider threshold, and for pre-existing arrangements, the contractual requirements are not optional past 1 July 2026. APRA expects contracts to cover model update and data handling change notices, incident triggers, audit and inspection rights, and termination and portability — not as boilerplate, but as terms entities actively monitor and enforce. It also expects entities to map their fourth parties and test substitution or fallback plans for critical AI providers, not just assume one exists.
Context.ai, Vercel, and the vendor nobody assessed
The APRA letter’s warning about opaque upstream dependencies played out in public weeks later, outside financial services entirely. In April 2026, a threat actor compromised an employee account at Context.ai, an AI tooling vendor, using infostealer malware. That access was used to reach a Vercel employee’s Google Workspace account, and from there into Vercel environments where some environment variables — not flagged as “sensitive” and stored in plaintext — were exposed, including API keys, tokens and database credentials.
A group claiming to be ShinyHunters posted the stolen data for sale on a criminal forum with a US$2 million ransom demand (ShinyHunters itself later denied involvement, and attribution remains unresolved). Vercel engaged Mandiant, notified law enforcement, contacted affected customers directly, and advised a review of environment variable security settings. The organisation that got breached wasn’t the one that made the security decision that mattered — that decision sat two vendors upstream, invisible to anyone doing a standard supplier assessment.
Innovation of Risk Thinking: from vendor assurance to vendor accountability
Both examples point to the same failure mode: risk assessment that stops at the first vendor.
APRA is now writing that expectation into enforceable contract terms for material service providers. The Context.ai–Vercel breach shows what happens when nobody maps the layer below that. Effective oversight means treating vendor AI evidence as a claim to be tested, not a box to be ticked, and extending that testing to the vendors your vendors depend on.
Questions to ask your organisation
- Do we have a current, complete inventory of every AI component embedded in our vendor platforms — including the vendors our vendors use?
- For vendors that meet the material service provider threshold, do our contracts already include model and data change notices, incident triggers, audit rights and termination or portability — or are we still working from a pre-AI template?
- If an AI tooling supplier to one of our vendors were compromised tomorrow, would we know, and how long would it take us to find out?
- Have we independently tested or verified any vendor’s privacy, security or model risk claims, or are we relying entirely on their own attestation?
- Do we have a substitution or exit plan for our most critical AI vendors, and has it actually been tested?
- Who in our organisation owns the residual risk when an AI failure originates two or three layers down the vendor chain?
“A signed-off vendor checklist is not AI risk management. Ownership, tailored evidence and mapping the layer you can’t see are what actually close this gap.”
Innovation of Risk provides AI maturity and risk assessment tools to help organisations have better internal risk, governance and assurance discussions.
Take a readiness snapshot in the Reading Room to see where your third-party AI oversight actually stands.