A stolen AI login can run up the bill and reach the rest of your business

An AI account is becoming another business system worth stealing. The immediate loss might be a pile of model credits. The more awkward question is what else the account was allowed to touch.

The Australian Signals Directorate warned on 28 September that attackers are gaining access through compromised keys, tokens, sessions, applications and third-party arrangements. It says connected agents can extend the impact into organisational data and systems.

For a small firm, our reading is straightforward: the person who approved the AI experiment should now be able to say who owns it, who can use it and who can switch it off. “The developer set it up” is not an access policy.

A budget warning is not a spending stop

ASD recommends tested limits that actually restrict use, alongside monitoring. The distinction matters when the bill is attached to an automated tool rather than an employee consciously choosing each purchase.

OpenAI’s current API spend-limit documentation provides a concrete example. Spend alerts notify you while traffic continues. Hard limits, configured at organisation or project level, cause affected requests to fail when tracked spending reaches the threshold. Enforcement is not instantaneous, so recorded usage can slightly overshoot.

A hard limit can also interrupt legitimate work. Our recommendation is to ask the supplier who built the integration to demonstrate both behaviours: what warns the account owner, and what stops the tool. Agree who investigates an unexpected spike before anybody simply raises the ceiling. These are API controls; do not assume a chatbot subscription has the same settings.

Check the permissions behind the key

An API key lets software authenticate its requests. ASD says a working stolen key can be used outside the legitimate application, while a stolen session can avoid a fresh MFA challenge. The agency recommends phishing-resistant MFA and securing credentials, rather than relying solely on the model developer’s defences.

OpenAI’s project documentation shows why a permission review should be specific. API keys can have full, restricted or read-only permissions. Service-account keys initially have read and write access to the project’s API resources, and those permissions can be changed. A supplier should be able to explain which permissions the job requires.

We would make that explanation part of handing over any small-business automation, alongside the billing contact and a short shutdown procedure. Pair it with stronger account sign-in, rather than assuming either passwords or spending controls can do the whole job.

If compromise is suspected, ASD advises revoking affected credentials and sessions, isolating compromised devices, preserving logs and fixing the cause before restoring access. A clean-looking usage graph is not a reason to ignore an unexplained login.

Checklist

• Assign an owner. Have the business owner record who controls each AI account and supplier integration.
• Review key permissions. Ask the integration developer to identify the access each key needs and remove permissions outside that job.
• Test spending controls. Have the account administrator distinguish alerts from enforced limits and document what legitimate work would stop.
• Write the response steps. Ask the IT provider to record how to revoke affected access, preserve logs and investigate before restoring the service.