Evinact Associate Baden Hughes looks at the recent addition of AI security controls in Australia’s Information Security Manual (ISM) and suggests what’s missing and what might be coming next.
Technology generally moves quickly, and regulation and governance often trails adoption and implementation, and tends to look somewhat reactionary. Nevertheless, it can be informative to consider the pace and direction of development of standards in response to practice and experience, and to ask whether the gaps are getting smaller or larger.
Over the last couple of years, AI in particular has moved so much faster that the distance between capability and (effective) control are growing as the frontier expands.
There are a solid set of international standards and frameworks for AI security, including ISO 27090, ISO 42001, NIST AI RMF, CSA STAR for AI and AIUC-1 as well as regional and national instruments.
While these are all AI-specific, none of these have the local applicability and impact of Australia’s Information Security Manual (ISM) — the foundation standard for public sector security, including cybersecurity. ISM applies from Defence through all layers of Commonwealth agencies, extends into regulated industries that have critical infrastructure or supply chain relationships and is adopted as a reference for state agencies. It’s the ‘big dog’ locally, regardless of international developments.
Getting started
The first AI-specific security controls entered the ISM in June 2024:
- ISM-1923: “A new control was added recommending that the OWASP Top 10 for Large Language Model Applications be mitigated in the development of large language model applications.”
- ISM-1924: “A new control was added recommending that large language model applications evaluate the sentence perplexity of user prompts to detect and mitigate adversarial suffixes designed to assist in the generation of sensitive or harmful content.”
That was a good start (although arguably a bit late given that a lot of “pre-genAI” technology has been around for 10+ years, and the availability of ChatGPT in November 2022, and Claude in March 2023 in forms which accelerated mass market adoption). But June 2024 seems like a very long time ago when considering the pace of AI development, and collective learnings about what can be achieved now and also go wrong with this class of technologies.
More recent changes
The full list of AI security-related controls introduced or updated between September 2025 and September 2026 is included in the appendix at the end of this article.
In September 2025, ASD strengthened its existing guidance on prompt injection, broadening the focus from adversarial suffixes to other malicious inputs intended to manipulate the behaviour of generative AI applications.
The December 2025 update introduced a much wider range of controls. These addressed the integrity of AI models and training data, the monitoring of model performance, resource consumption and rate limiting, access permissions and sensitive data exposure. Taken together, they reflected growing recognition of the risks associated with both the development and operation of AI applications.
The March and June 2026 updates introduced additional controls relating to how organisational data is used by AI models, the secure deletion of prompts and outputs, AI-specific documentation and the exposure of model confidence scores.
Most recently, September 2026 saw the introduction of four controls specifically addressing agentic AI. These focus on restricting the tools and permissions available to AI agents, ensuring appropriate authorisation, treating externally retrieved content as untrusted and maintaining logs of agent activity.
Just from this quick summary, we can see the ISM storyline with AI security controls is changing over time.
Right at the beginning, ISM started with applying external standards to prevent weaknesses in AI-based applications and prompt defenses against malicious input. But in the last 12 months, preventing interferences with an AI tool’s function has been stepped up (prompt injection, model poisoning); avoiding the negative impacts of what generally available and capable AI subscriptions and access models can have (unbounded consumption); addressing the broader question of when AI interactions, decisions and data needs to be preserved (data retention); dealing with undesirable or unlawful outputs (sensitive data and other output management); better practices for in-house AI development (secure development); and most recently further work on controlling what AI tools can access and do (excessive agency).
Where AI fits — according to ASD so far
What’s perhaps more interesting is that ISM-wise, ASD has placed all of these recent changes in the “Guidelines for Software Development” chapter and specifically the “Artificial intelligence application development” section. (In fact, if you search the whole text of the ISM for “artificial intelligence,” there are very few mentions anywhere else, and those that occur are informative rather than actual controls.)
AI security concerns are by no means restricted to software development, and apply far more broadly across the technology landscape — practically every IT vendor you buy from now, regardless of where they fit in the stack, embeds some form of AI. There are important implications: like access control and data protection, AI security is a systemic concern — even if it’s not explicitly mentioned in every ISM chapter, it needs to be considered with regard to risk management in every control domain and at every technology layer.
(Despite the limited treatment in Australia’s ISM, I’d still rather be dealing with Australia’s emerging control set and quarterly updates on AI security than be in New Zealand — their ISM is updated every 18-24 months, and is still coming to practical terms with cloud despite a Cabinet mandate in 2012, and doesn’t yet even mention AI as a problem set.)
So where next?
It seems very likely that the next update(s) of the Australian ISM will introduce agentic AI controls on top of the existing set of AI security controls, and probably extend a number of other ISM topic areas with AI and agentic AI-specific edits.
ASD (along with sister agencies across the Five Eyes) has jointly developed and published a guidance document specifically addressing agentic AI — practically, it’s easier and faster to generate this kind of content than it is to change the ISM.
Recent events like OpenAI’s “original” HuggingFace agent-hack, Anthropic’s acknowledgement that its Claude agents have also been jumping their fences, and the even more local examples of the OpenAI Medicare agent-hack and the NPWS agent-hack suggest agentic AI is absolutely on ASD’s radar (although there is an argument that if existing ISM controls were applied better by the targeted organisations at least some of these incidents could have been averted, and the cynic would probably suggest the pending IPO cycle for frontier AI providers and countering the threat of government regulation might have something to do with the amount of airtime these “achievements” have gotten).
There are likely some less sexy changes coming too.
For my money, there isn’t enough emphasis on the way AI enters organisations via purchased products or via delivery contracts. There is a quick nod in this direction in the Guidelines for procurement and outsourcing chapter of ISM (Managed services and cloud services) via the cheap comment “An artificial intelligence (AI) application or service may constitute a managed service, an outsourced cloud service, both or neither, depending on how it is deployed and who manages it, regardless of whether it uses a closed source, open source or open weight AI model.” but this seems to be an editorial shortcut in the hope that buyers join the dots and do the right thing. Perhaps a look aside at what the DTA is doing with their AI procurement support might be a place to start.
There is no mention yet of AI-powered or augmented/enhanced functionality in ISM chapters, sections and topics for system monitoring, information security event detection, response management, or remediation-type applications. Since the current solution landscape (regardless of the vendor or the technology stack level) is dominated by AI-augmented, if not AI-native, capabilities in these areas, it feels like an important oversight waiting to be addressed. That requires a bigger commitment in the ISM than putting most AI things into the “Software Development/AI Application Development” bucket.
Over the last 2 years, the ISM has made meaningful progress in addressing AI security. But they’re not done — risks continue to emerge, and new responses will be required. If you’d like to discuss how emerging AI security and other ISM controls apply to your organisation, or how other AI security standards and frameworks can support your approach to AI governance, privacy and security or AI assurance, speak to Evinact.
Appendix: AI-specific controls introduced or updated in the ISM, September 2025 – September 2026
The following table reproduces the control descriptions and categories provided in the source article, organised by quarterly ISM update.
September 2025
| ISM Control ID | Control Text | Topic |
| ISM-1924 | Generative AI applications evaluate user prompts to detect and mitigate adversarial inputs or suffixes designed to elicit unintended behaviour or assist in the generation of sensitive or harmful content. | Prompt injection |
December 2025
| ISM Control ID | Control Text | Topic |
| ISM-2086 | The source and integrity of AI models, structures and weights are verified. | Artificial intelligence model poisoning |
| ISM-2087 | The source and integrity of training data for AI models is verified. | Artificial intelligence model poisoning |
| ISM-2088 | Data validation and verification techniques are used to ensure the reliability and accuracy of training data used by AI models. | Artificial intelligence model poisoning |
| ISM-2089 | AI model performance metrics are monitored and anomalies are investigated. | Unbounded consumption |
| ISM-2090 | Rate limiting is applied to inference queries for AI models. | Unbounded consumption |
| ISM-2091 | Resource limits are enforced for AI models. | Unbounded consumption |
| ISM-2072 | AI models are stored in a non-executable file format that does not allow arbitrary code execution. | Secure artificial intelligence application development |
| ISM-2092 | Access control policies are implemented to enforce fine-grained permissions for AI applications. | Excessive agency |
| ISM-2093 | Role-based access controls are implemented for AI applications to restrict access to sensitive data. | Excessive agency |
| ISM-2094 | Content filtering is implemented by AI applications to detect and block sensitive data exposure and improper output. | Sensitive data exposure and improper output |
March 2026
| ISM Control ID | Control Text | Topic |
| ISM-2103 | Organisational data generated, collected or processed by AI applications is not used for training, fine-tuning or improving AI models unless informed and explicit consent has been obtained from data owners in advance. | Data collection, retention and use |
June 2026
| ISM Control ID | Control Text | Topic |
| ISM-2123 | All prompts and outputs associated with chat sessions are securely deleted when chat sessions are removed from AI applications. | Data collection, retention and use |
| ISM-2084 | AI-specific documentation, including AI model cards and AI system cards (or equivalent artefacts), is used to document AI model characteristics, system architectures, use cases and security risks. | Secure artificial intelligence application development |
| ISM-2085 | The exposure of exact AI model confidence scores in API outputs or user interfaces is prevented. | Secure artificial intelligence application development |
September 2026
| ISM Control ID | Control Text | Topic |
| ISM-2156 | Agentic AI applications are restricted to the minimum set of tools, functions and permissions required for their intended purpose. | Excessive agency |
| ISM-2157 | Tools invoked by agentic AI applications are subject to both the access controls of the invoking user and agent-specific, task-scoped authorisation, with effective permissions limited to the minimum permitted by both. | Excessive agency |
| ISM-2158 | External content retrieved by agentic AI applications is treated as untrusted data throughout processing, is clearly delimited from system instructions, is subject to validation and sanitisation measures applied to other untrusted input, remains untrusted following such processing, and is prevented from modifying or overriding system instructions, security policies, access controls, tool permissions or human approval requirements. | Excessive agency |
| ISM-2159 | All tool invocations, external requests and outputs generated by agentic AI applications are centrally logged with sufficient detail to support cyber security incident investigations. | Excessive agency |
