Who Owns Your Company’s AI Account? ASD Says Attackers Are Asking the Same Question

On 28 September the Australian Signals Directorate published an advisory with a title most small businesses will skim straight past: Protect your organisation’s AI services. It deserves more attention than that. ASD says it is aware of malicious actors getting into organisations’ AI services through compromised API keys, stolen authentication tokens, hijacked user sessions, vulnerable applications and third-party access. Once inside, they use the account to create harmful material, extract what the model can do, burn through your credits and disrupt the people who use it legitimately.

The advisory’s opening line is the part to keep: organisations should treat access to advanced AI services as a security-sensitive asset, and protecting it takes more than relying on the AI provider’s own security.

That is an asset management sentence, and it lands on a question most organisations cannot answer yet.

How the access gets taken

ASD describes three routes, and each has a recent, public example behind it.

Keys left where someone can find them. API keys end up in source code, configuration files, browser extensions and internet-facing tools. In March 2026 an attacker found an AI research organisation’s agent dashboard running on a researcher’s personal cloud server. It was meant to sit behind a login, but a flaw in the hastily built app silently switched the login off. The attacker asked the agent to reveal its model-provider key, added their own remote access, and used the key for three weeks. The organisation, METR, disclosed it on 31 August. The usage was worth about US$600,000 at list price, and it was only free because the provider had donated the credits.

Sessions stolen from infected computers. Okta analysed a large dump of data taken by information-stealing malware and found still-valid AI API keys and unexpired login tokens for AI services among the passwords. A stolen session lets an attacker act as a user who is already signed in, without facing a multi-factor authentication challenge at all. Okta’s phrase for it is signing in without signing in.

Access through someone else. Suppliers and contractors who hold your credentials, or delegated access to your AI tools, carry the same risk into your account.

ASD adds a point that is easy to miss. The damage depends on what the compromised identity is allowed to do, and with AI agents that can go well beyond the model itself. A hijacked account or agent may be able to reach connected business systems, call tools, read your data or talk to other agents on your behalf.

Who owns your AI account?

Here is the picture I would expect to find in a typical small or medium business if I audited this tomorrow. A developer created an API key a year ago for an internal tool, and it lives in a script on a laptop. Several staff pay for their own AI subscriptions and claim them on expenses. The company account was set up on the managing director’s card and nobody else knows the login. An IT provider has admin access “to help”. And the one thing that looks like a control, a spending alert, sends an email to someone who has since left.

None of that is unusual, and none of it is anyone’s fault. AI tools arrived faster than anyone’s asset register, and a good deal of this is the shadow AI problem seen from the credentials side. But ASD’s first recommendation is exactly the thing that picture lacks: an inventory of AI accounts, service identities and credentials, with an accountable owner for each, only the access each one needs, and prompt removal of anything unnecessary.

If you have already started a register of the AI agents you run, as in our Harness Register, the credentials those agents use belong in it too. And if your access reviews only list people, they are missing the logins that matter most here.

A spending limit that only sends an email is not a control

One line in ASD’s advice reads like it was written by an auditor. Organisations should configure tested spending, rate and consumption limits that enforce restrictions rather than only generating alerts.

The METR case shows why. Its usage was not spotted quickly, partly because the organisation normally runs heavy workloads, and partly because there were no caps on spend. Afterwards it added spend alerts to its keys where it could. An alert tells you something went wrong. A limit stops it going further. They are different controls, and only one of them works at 2am on a long weekend.

The word tested matters as much as enforce. A limit you have never seen trigger is a setting, not a control. Test it on purpose, at a low threshold, and keep the record.

Where this sits in ISO 27001 and ISO 42001

None of ASD’s advice needs a new framework. It is existing ISO/IEC 27001:2022 controls applied to a new kind of account.

• Inventory and ownership: A.5.9 inventory of information and other associated assets. The AI account, each API key and each service identity is an asset with an owner.
• Least privilege and access removal: A.5.15 access control, A.5.18 access rights, and A.8.2 privileged access rights for anyone who can administer the account or create new keys.
• Keys, tokens and MFA: A.5.17 authentication information and A.8.5 secure authentication. Phishing-resistant MFA for people; a proper secrets manager for keys, never code, documents, logs or prompts.
• Suppliers: A.5.19 to A.5.22. Limited, auditable access, agreed in writing and reviewed.
• Monitoring: A.8.15 logging and A.8.16 monitoring activities, including logs protected from tampering and alerts on new keys, permission changes and unusual usage.
• Responding: A.5.24 to A.5.26. Revoke keys and sessions, isolate the device, keep the logs, fix the cause before restoring access.

If you are building an AI management system, ISO/IEC 42001 asks you to document the resources your AI systems depend on, and the accounts and keys that give access to them are exactly those resources.

What to do this month

1. List every AI account, key and service identity the business uses, including personal subscriptions used for work. Give each one an owner.
2. Find the keys. Search your code repositories, shared drives and scripts for API keys, then move the live ones into a secrets manager and rotate them.
3. Check who can create keys or change billing on each account, and cut that list down.
4. Turn on phishing-resistant MFA on every AI account that supports it, and use managed devices for anything with admin rights.
5. Set hard limits, then test them. Spend, rate and usage caps that stop activity, set low enough to matter, triggered once on purpose.
6. Check supplier access. Anyone outside the business with access to your AI tools should have their own limited, logged account, not a shared login.
7. Write down the response. Who revokes a key at 2am, and how, before you need to.

Speak with an experienced ISO 27001 auditor

ASD’s advice is practical and none of it is expensive. What usually stops a business is that nobody owns the question. That is what a management system fixes: every AI account on the register, an owner for each, and a review date that someone is held to.

Streamline helps Australian organisations build ISO 27001 information security management systems and ISO 42001 AI management systems that treat AI access as the asset it is. If you want to know where you stand first, a gap analysis will tell you. We also provide an independent internal audit where your team lacks the capacity or the impartiality to run it internally. If you would rather your own people do the building, ISO mentoring is the route.

Email hello@streamline.business or call Brisbane 07 3667 8280, Sydney 02 8315 7780 or Melbourne 03 9034 3990.

Sources: ASD, Protect your organisations’ AI services, 28 September 2026; The Hacker News, Attackers steal METR API key, 1 September 2026; Okta Threat Intelligence, Signing in without actually signing in. This article is general information from an auditing and management system perspective, not technical remediation advice.