Key takeaways
- Australia’s cyber security agency has warned that attackers are obtaining unauthorised access to organisational AI services through stolen API keys, authentication tokens, compromised sessions, vulnerable applications and third-party access.
- AI credentials can provide more than access to a model. Connected AI and agents may also be able to reach organisational data, invoke tools and interact with other business systems.
- New Zealand firms should bring AI accounts, API keys, service identities and agent permissions into their established identity, access and incident-response controls.
AI governance often focuses on what staff put into AI and whether its outputs can be trusted. A new Australian Government cyber security warning highlights another issue that deserves equal attention: who can access the AI itself.
On 28 September 2026, the Australian Signals Directorate warned that malicious cyber actors are obtaining unauthorised access to organisations’ AI services. The agency identified compromised API keys, stolen authentication tokens, hijacked user sessions, vulnerable applications and third-party access arrangements as routes into these systems.
For New Zealand professional services firms, this moves AI credential security from a technical detail into a governance issue. As AI becomes connected to client information, document systems and business applications, a compromised AI identity may provide an attacker with capabilities that extend well beyond generating text.
AI access is becoming a valuable target
Many organisations now have several ways of accessing AI. Staff may sign into enterprise AI platforms through corporate accounts, internal applications may call models using API keys, and AI agents may have service identities that allow them to interact with other systems. Each creates an identity that needs to be protected.
The Australian guidance says organisations should treat access to advanced AI services as a security-sensitive asset. It warns that stolen access can be used to generate harmful material, consume model capabilities and credits, interfere with legitimate work or potentially reach systems connected to the AI service. That last point becomes increasingly important as organisations adopt agents.
A conventional AI application may only receive a prompt and return an answer. An agent may have permission to search a document repository, query databases, use business applications, invoke tools or communicate with other agents. Compromising the identity behind that agent could therefore expose more than the AI service itself.
An API key is effectively a credential
API keys are easy to overlook because they often sit behind an application rather than being typed in by a person. In practice, they can function much like passwords. An application presents the key to an AI provider to prove that it is authorised to use a service. If an attacker obtains a valid key, they may be able to make requests as though they were the legitimate application.
The Australian Signals Directorate identifies several ways these credentials can be exposed, including source-code repositories, application configuration files and browser extensions. It also warns that vulnerable internet-facing agent dashboards can expose credentials used to access model providers.
This creates a straightforward governance question: does your organisation know where its AI credentials are? If the answer requires asking individual developers, examining source code or checking multiple SaaS administration consoles, the organisation may not yet have adequate visibility.
AI identities need owners
One of the most useful recommendations in the Australian guidance is also one of the simplest: maintain an inventory of AI accounts, service identities and credentials and assign an accountable owner to each. That is a governance control as much as a cyber security control.
An inventory makes it possible to answer basic questions. Which AI services does the organisation use? Which applications have API access? Which agents have their own identities? Who is responsible for each credential? What permissions does it provide? When was it last reviewed? This also helps address the problem of abandoned AI experiments.
A developer may create an API key for a pilot. A team may test an agent and then move to another platform. A consultant may receive temporary access during implementation. Unless those credentials are actively managed, access can survive long after the business purpose that justified it has disappeared.
Least privilege matters more with agents
The Australian guidance stresses that permission to use an AI model is different from permission to administer an account, create credentials or access stored files. Those privileges should be assessed separately. That distinction is particularly useful for New Zealand firms adopting agentic AI.
An agent that needs to read documents does not necessarily need permission to modify them. An AI system drafting an email does not automatically need authority to send it. An application that calls a model does not necessarily need administrative access to the organisation’s AI environment. The principle is familiar: provide only the access required to perform the approved task.
New Zealand’s NCSC has already endorsed this approach in joint international guidance on agentic AI. That guidance notes that agentic systems may contain sensitive organisational information and secrets such as API keys for integrated tools and services, making them attractive targets.
As agents gain capabilities, least privilege becomes one of the practical mechanisms for preventing an AI compromise from spreading into the wider organisation.
MFA does not solve every credential problem
Multi-factor authentication remains important, and the Australian guidance recommends phishing-resistant MFA for AI accounts. But MFA does not protect every form of AI access.
A stolen browser session may allow an attacker to act as an already authenticated user without completing another MFA challenge. An exposed API key may be usable directly by an attacker. A compromised supplier may already hold delegated access that the organisation considers legitimate. This is why AI security needs several layers.
Credentials should be stored in approved secrets-management systems rather than source code, documents, logs or prompts. Access should be monitored, permissions reviewed and unnecessary credentials removed. Suppliers should receive limited and auditable access rather than broad standing permissions.
Spending limits are also security controls
AI introduces another unusual consequence of credential theft: direct consumption costs. An attacker using a stolen model credential may generate significant API charges even if they never access sensitive organisational information.
The Australian guidance recommends tested spending, rate and consumption limits that actually enforce restrictions rather than simply generating alerts. That distinction matters. An email warning that an AI account has suddenly consumed thousands of dollars of services is useful, but a predetermined control that limits what the compromised account can consume may be considerably more effective.
For firms experimenting with multiple AI services, financial controls and cyber security controls are beginning to overlap.
Logging needs to show what happened
Organisations also need enough logging to investigate compromised AI access.
The Australian guidance recommends monitoring model access, credential creation, permission changes and unusual usage patterns, while protecting audit logs from tampering.
For professional services firms, useful logs may need to go further. Where an AI agent can interact with client information or business systems, an investigation may need to determine which identity was used, what the AI accessed, what tools it invoked and what actions followed.
This supports cyber incident response, but it may also be important for privacy investigations, client notifications and professional accountability.
What this means for your organisation
Create an AI access inventory. Record AI user accounts, API keys, service identities, agents and delegated third-party access. Assign a named owner to each.
Find unmanaged credentials. Check development environments, configuration files, code repositories and legacy pilots for AI credentials that may have been created outside normal identity-management processes.
Use proper secrets management. Do not store API keys in source code, shared documents, prompts or ordinary configuration files where they can be unnecessarily exposed.
Apply least privilege. Separate permission to use a model from administrative, data, tool and agent permissions. Give each identity only what it needs.
Protect interactive accounts. Use phishing-resistant MFA where supported, managed devices and controls capable of detecting suspicious sessions.
Control suppliers. Review the AI access held by consultants, developers and other third parties. Make that access limited, attributable and capable of being revoked quickly.
Set enforceable usage limits. Apply appropriate rate, spending and consumption controls to API and model access rather than relying solely on alerts.
Prepare for credential compromise. Incident-response procedures should include revoking AI API keys, tokens and sessions, isolating affected devices, preserving logs and checking connected systems.
AI governance now includes identity governance
AI is increasingly becoming part of an organisation’s operating environment rather than a standalone productivity tool. That changes what needs to be governed. Policies about acceptable AI use and information handling remain important, but organisations also need control over the identities that allow people, applications and agents to access AI services.
For New Zealand professional services firms, much of the answer already exists in established cyber security practice: inventory assets, assign ownership, protect credentials, restrict privileges, monitor activity and revoke access quickly when something goes wrong. The difference is that AI accounts, API keys and agent identities now need to be brought inside those controls.
