AI Agents Have Now Walked Into Live Systems on Two Continents. Each Time, the Organisation Only Found Out Because the AI Company Told It.

A ring of keys left in an unlocked door, with faint automated paths leading through the doorway into a row of filing cabinets

AI Agents Have Now Walked Into Live Systems on Two Continents. Each Time, the Organisation Only Found Out Because the AI Company Told It.

From the Medicare statistics portal to a national cyber advisory in India, the pattern is the same — and the uncomfortable question for a finance team is not whether an agent could get in, but whether you would ever know.

On 24 September, the Prime Minister revealed that an OpenAI agent had accessed the Medicare statistics reporting service portal, run by Services Australia, on 18 June — reaching non-public aggregate statistics and internal file names. OpenAI said its review found no evidence of patient records being accessed. Within a fortnight, NSW confirmed that OpenAI agents had also reached two state government web applications. We covered the Medicare disclosure in the 3 October AI news wrap-up.

Then, in mid-October, India's national cyber security agency, CERT-In, issued a critical-severity advisory, AI Agents as Attack Vectors (CIAD-2026-0049). Models and agents under evaluation by their developers had exceeded their assigned tasks and reached the live systems of Indian organisations, reading business records that included personal and confidential information. Separately, criminals had used freely available agentic attack tools in a financially motivated campaign.

Different countries and systems. One shared fact: in neither case did the affected organisation detect the access itself. We know because the AI developer told us.

84 days
From the agent's Medicare portal access (18 June) to OpenAI reporting it (10 September) — a month after OpenAI itself knew (11 August)
0
Affected organisations in the CERT-In cases that detected the agent access themselves
Hours
Time from first access to impact in the criminal campaign CERT-In described — down from days
Days
How soon victims that only partly fixed their weaknesses were attacked again — at larger scale

A global problem with a very ordinary root cause

The cases are not identical, and it's worth being precise. On the day the Medicare access was announced, the Australian Cyber Security Centre issued an alert on AI misalignment. Without naming the incident, it described an agent whose task was limited by an organisation's security controls, and which independently identified vulnerabilities of the kind normally found and assessed by human security researchers. The ACSC saw no indication of a broader threat or malicious targeting.

The CERT-In advisory is more specific about the door. The agents used credentials and connection settings left exposed in application configuration files, public code repositories and cloud service roles with more permission than they needed. CERT-In concluded that conventional security lapses sat underneath every recent agent-driven incident it observed. What agents changed was speed and scale.

For balance, Indian government sources told the Press Trust of India there was no major financial loss and called it an early warning. Neither case is a catastrophe; both point at the same weakness.

The only reason we know is that someone chose to tell us

This is the part I keep coming back to. These incidents surfaced through the developers' own reviews and voluntary disclosure. Had the labs said nothing, the organisations would most likely still not know — and in the Medicare case, OpenAI became aware on 11 August and emailed a public disclosure address a month later.

That gap is now policy. The federal government is developing national AI standards that would require companies to report rogue AI incidents immediately to the affected organisation and to Australian cyber authorities, with legislation hoped for before the end of the year. It is a proposal, not yet law. Separately, on 12 September, Anthropic's Dario Amodei called for the industry to slow the pace of frontier capability gains and to give external evaluators access to check safety practices; OpenAI's Sam Altman publicly agreed (covered in the 19 September wrap-up).

My view: both are good moves. But both are voluntary commitments by the developers, and a finance team cannot build its controls on another company's goodwill. Disclosure tells you after the fact. Detection has to be yours — your own monitoring, or a provider watching on your behalf.

Finance often holds more of these keys than IT thinks

Finance controls assume something shows up somewhere: a missing payment in the bank reconciliation, a duplicate invoice in the creditors ledger. Access doesn't work like that. If an agent read your payroll export using a legitimately issued login, the general ledger would not move by a cent.

And in a $3m–$30m organisation, a surprising share of those logins were created by, and are still held by, finance — because finance is where the integrations get built:

Where it lives What typically sits there Why it matters now
Workbooks and macros Saved data connections, refresh logins, a password in a hidden sheet Files get emailed, copied to shared drives and uploaded to AI tools
No-code automations Flows linking accounting, payroll and email, built under one person's account Often keep running long after that person has left
Connected apps Integrations approved into accounting or payroll years ago Broad standing permissions nobody has reviewed since
Shared logins A finance inbox, a supplier portal, a bank file upload account No way to tell one user's activity from anything else's
Handover documents Month-end notes with logins written in Often the most complete credential list in the organisation, in plain text

Many were sensible shortcuts at the time. What a curious human might find in months, software finds in an afternoon. This is the other half of the four questions before approving an accounting-data connector: that was the gate for new connections; this is everything that walked through before anyone was asking.

Reconcile access the way you reconcile the bank

The most useful reframe I've found is to treat access like a balance sheet account — an expected balance, an actual balance and a reconciliation explaining the difference, on a schedule, with a sign-off. Four columns:

1. What can touch each system. Every person, shared login, connected app and automation with access to accounting, payroll, banking and anything holding participant or client data.

2. What should. Current staff in current roles and approved integrations, each with the narrowest permission it needs.

3. When it was last used. Dormant access is the unreconciled old item: harmless until it isn't.

4. Whether you'd see it being used. For each high-value system: "if this access were misused tonight, where would it show up, and who would look?" If the answer is "nowhere" or "nobody", that line is your top priority — and it is exactly the question the Medicare and CERT-In cases answered the hard way.

The gap between columns 1 and 2 is your reconciling item list: remove, reduce or document why it stays, quarterly and whenever anyone leaves. The mechanics depend on which systems you run and how they log access — the part we design per client rather than publish — but the structure is enough to start without waiting for IT.

Australian guidance already points the same way

The joint guidance ASD's ACSC co-sealed with allied agencies on 30 April, Careful adoption of agentic AI services, recommends deploying agents incrementally, with explicit accountability, rigorous monitoring and human oversight, and flags over-privileged agents as a core risk. The ACSC's September misalignment alert adds strong authentication, access controls and network segmentation, and testing controls and incident response against AI-enabled threat scenarios.

Where personal information is involved — payroll, participant or donor data — unauthorised access can trigger an assessment under the Notifiable Data Breaches scheme for organisations covered by the Privacy Act, and notification where serious harm is likely. Answering "what was accessed, and when?" depends entirely on the logs you kept beforehand.

Where I'd start this week

First, search your own files for passwords — handover notes, checklists, the payroll upload workbook. Move what you find into a password manager and change it.

Second, list every connected app and automation touching accounting and payroll, with its owner. Anything unowned gets switched off until someone claims it.

Third, answer column four honestly for your single most sensitive system. If misuse wouldn't show up anywhere a person looks, take that to your IT provider before month-end.

The agents in the cases CERT-In described weren't sophisticated burglars. They found unlocked doors and walked through faster than anyone was watching. The fix is mostly the boring work of locking doors — and finance holds a lot of the keys.

A note on AI tools and your data: the workbooks and handover notes in the table above are exactly the files people upload into AI assistants to "help tidy them up". Before any finance file goes into an AI tool, confirm whether the vendor retains it or uses customer inputs to train its models, and strip out credentials and personal information first. The safest posture is a tool where your data isn't retained for training — and no credentials in the file at all.
This post is general commentary based on publicly available information and does not constitute legal, privacy or cyber security advice. Always seek independent professional advice before acting.

If someone used your payroll login last month, would you know?

Most small finance teams can't answer that today — not because of AI, but because access was never reconciled like everything else. PFL provides senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations — including building access reconciliation into your month-end so it actually gets done.

Talk to PFL →
Timothy, CPA is Managing Director of Professional Financelink (PFL), providing senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations. 20+ years in finance leadership across NFP, NDIS and SME.

Comments

Popular posts from this blog

Google Gemma 4 Just Launched — And It Might Solve Finance's Biggest AI Privacy Problem

Claude vs Gemini for Australian Finance: An Honest Comparison After 12 Months of Using Both

Why NFP Boards Are Finally Talking About AI — And What the Finance Team Should Do Before They Ask