The Logins You Forgot to Turn Off

On 5 August 2026 the Australian Signals Directorate and the Australian Institute of Company Directors published joint guidance for boards on frontier AI cyber threats. Most of the coverage went to the headline: boards should treat foreign ownership and control of their AI providers as a cyber risk in its own right.

That is the right headline. But there is a line further down the document that will get skimmed past, and it is the one that changes what your next access review has to look like.

Under short-term priorities, ASD lists:

Restrict unnecessary privileges: Personnel and services, including AI agents, are granted the minimum access to systems required to undertake their duties.

Read those three words again. Including AI agents.

Your access review has a species problem

Ask most organisations for their last access review and you will get a spreadsheet of people. Names, roles, systems, a tick next to each. It is usually reasonable work.

Now ask the same question a different way. How many identities can reach your production data right now?

The honest answer is almost always higher than the list, because the list only has humans on it. It is missing the service account that was created for a migration in 2023 and never disabled. The API key sitting in a config file in a repository. The integration a departed contractor set up between two SaaS tools that still runs every night. And now, increasingly, the AI agent someone connected to the CRM so it could draft follow-up emails.

None of those people are people. All of them have access.

ASD has now said, in plain terms, that those services count. That is not a new control. It is the same control you already have, applied to identities you were not counting.

The classic version of this problem still has not been fixed

Before the agents, there were the leavers.

The pattern is familiar to anyone who has audited an ISMS. Someone resigns. HR runs the exit process. IT disables the email account. Six weeks later an internal audit asks a simple question: what else could that person reach?

The VPN profile, usually. The shared login for the supplier portal that three people knew and nobody rotated. The personal device with a saved session. The admin account on a system that was never in the directory because it was bought by a department rather than IT.

ISO/IEC 27001 covers this properly. Annex A 6.5 deals with responsibilities after termination or change of employment. 5.18 covers access rights, including their removal. 5.16 covers identity management across the whole lifecycle, not just the joining part. 5.17 covers authentication information, which is where shared credentials live.

The controls exist. What is usually missing is the trigger. If revocation depends on a manager remembering to email IT, it is not a control, it is a habit. And habits fail on the days that matter, which are precisely the days when someone leaves badly.

ASD’s practical actions say the same thing in operational language: identify and disable default and unused accounts on a regular basis, and periodically review and update access privileges in alignment with current roles and duties. Regular. Periodic. Not “when someone remembers”.

What makes AI agents different, and what does not

The thing that does not change: an agent is an identity with credentials, and everything you already know about privilege applies.

Three things do change.

Agents accumulate access quietly. A person asks for access and someone approves it. An agent is often given access by whoever set it up, at the speed of a settings page, with a scope chosen for convenience. “Read and write” is one click easier than working out what it actually needs.

Agents do not leave. A human triggers an offboarding process because HR has a record of them. An agent has no HR record, no last day and no exit interview. Nothing in your business fires an event when an agent stops being needed. It simply keeps its credentials.

Agents act at machine speed. ASD’s framing of frontier AI is that it compresses attack timelines from days to hours. An over-privileged agent that behaves unexpectedly, or is manipulated into behaving unexpectedly, does so faster than your detection cycle was designed for.

If you are still deciding whether to deploy an agent at all, that is a different question and we have written about the four questions to ask before you let an AI agent loose. This piece is about the agents you already deployed, and whether anything in your business will ever review what they can still reach.

Why most access reviews collapse under their own size

The reason access reviews get abandoned is rarely laziness. It is arithmetic. If the review is a list of every individual grant held by every individual identity, a mid-sized business is looking at several hundred rows, most of which nobody in the room can confidently judge. That review gets started once and then quietly dies.

Two things prevent that, and neither of them is a piece of software.

Roles rather than grants. Role-based access control attaches access to a defined role instead of to a person. Someone joins and receives the role. They change departments and the role changes. They leave and the role is removed, taking everything inside it. The review then becomes a much smaller question: are these twelve role definitions still right, and what is sitting outside them? ISO/IEC 27001 covers this at Annex A 5.15 access control, 8.2 privileged access rights and 8.3 information access restriction.

This matters more for agents than it does for people. A person granted too much access usually never touches most of it. An agent will use whatever is in scope, because scope is the only boundary it has. Giving an agent a defined role with a bounded scope is the difference between a mistake and an incident.

A register rather than a memory. The artefact that holds all of this is a user access register: every identity, what kind it is, whether person, service account, key, integration or agent, what it can reach, who owns it, and when it was last reviewed. Humans and non-humans on the same register, or the non-humans will keep falling off the end of it.

The register is also what an auditor will ask for. “We review access regularly” is a claim. A register with a review date against each line is evidence. The gap between those two is where most of the findings in this area actually get raised.

The exit question nobody has answered

There is one more thread in the ASD guidance worth pulling, because it sits in the same family of controls.

Boards are told to assess the risk of relying on particular AI providers, including cyber supply chain risk and foreign ownership, control or influence. In ISO/IEC 27001 that is Annex A 5.19 to 5.23, supplier relationships and cloud services. In ISO/IEC 42001 it runs through the third party and lifecycle requirements.

It is easy to read that as geopolitics and move on. It is not. It is an availability question with a very practical test.

If your AI provider became unavailable tomorrow, what is the documented substitute?

This is not hypothetical. On 12 June 2026 the US Commerce Department ordered Anthropic to prevent all foreign nationals from accessing its two most capable models. Anthropic disabled them within hours, which made them unavailable to everyone. Access was restored around 30 June, under revised licence terms, after safety guardrails were strengthened.

Note that ASD’s guidance does not mention that episode, and this article is not suggesting it prompted the advice. It is simply the clearest recent illustration of the point ASD is making. A capability your business had on Thursday was gone on Friday, by decision of a government that is not yours, and no attacker touched you.

If a process in your business now depends on a model, that dependency belongs in your risk register with a named alternative, the same as a sole-source supplier. Most organisations have not done this, because the tool arrived through a credit card and a browser tab rather than through procurement.

What to do

Not a transformation programme. One meeting and an honest list.

Count every identity, not every person. Humans, service accounts, API keys and tokens, integrations, and AI agents. One register, not five lists. If an agent is not on it, your access review cannot see it.

Give every non-human identity a named human owner. An unowned control is not a control. The owner is the person who answers “does this still need to exist, and does it still need this much access?”

Fix the trigger, not the task. Revocation should fire from an event, an HR exit, a contract end, a project closure, rather than from someone’s memory.

Test one leaver. Pick a person who left in the last three months and try to prove every access they held was removed and when. Whatever you cannot evidence is your actual gap.

Ask the exit question about your AI provider, and write the answer down even if the answer is “we have not decided”.

That last one usually takes the longest, because it is the first time anyone has asked.

The free checklist

We have put the whole thing into a checklist you can work through with whoever actually administers access. Thirty-two checks across roles and the access register, joiners, movers, leavers, service accounts, keys and secrets, AI agents, third party access and assurance, each mapped to the relevant Annex A control and to the ASD guidance.

It is a spreadsheet, it is free, and there is nothing to fill in to get it.

Download the access review checklist (XLSX)

Section 7 is the one to look at first. That is the AI agent section, and in our experience it is the one where the answers stop being confident.

Where this fits

An access review is exactly the kind of control that looks fine in a policy and falls over when tested against reality, which is what a clause 9.2 internal audit is for. If you are building or maintaining an AI management system, the governance side of this sits in ISO 42001, and the identity and supplier controls sit in ISO 27001.

One last thing, about timing. An access review that is not on a calendar is an intention. The organisations that actually do this have it scheduled alongside their internal audits, management review, supplier reviews and emergency exercises, as a named activity with an owner and a date, rather than as something that happens when someone has a quiet week. If you keep a management system calendar, the access review belongs on it. If you do not keep one, that is the more useful thing to fix first.

ASD’s point to boards was that management should be pressed to act now. The reasonable first step is finding out how many identities you actually have.

Sources

• ASD and AICD, Frontier AI cyber threat considerations for boards of directors, 5 August 2026
• AICD, ASD board guidance on frontier AI cyber threats
• Anthropic, statement on the US government directive to suspend access to Fable 5 and Mythos 5
• CNN, US government allows Anthropic limited release of Mythos, 26 June 2026