The June 2026 edition of Australia’s Information Security Manual represents a quiet but important shift in how artificial intelligence is treated within cyber security.
AI is no longer viewed only as a technology that introduces new risks and therefore needs to be secured. The ISM increasingly treats AI in three distinct roles:
- A system requiring protection.
- A participant in software development.
- A capability organisations should use to strengthen cyber defence.
This is not a complete transformation of the ISM’s approach to AI. Many important AI-specific controls were introduced in earlier releases. However, the June edition moves the guidance from primarily governing and protecting AI towards operationalising it across development, testing and security assurance.
AI as a cyber-defence capability
Three new controls are particularly notable:
- ISM-2117 requires suitable AI models to augment the detection of cyber security events and the identification of cyber security incidents.
- ISM-2119 requires suitable AI models to augment vulnerability assessments and penetration tests.
- ISM-2122 extends this expectation to software security testing.
The language matters. These controls do not say that organisations should investigate AI, consider it where appropriate or conduct a trial. They state that suitable AI models “are used” to augment these security activities.
This positions AI as an expected cyber-defence capability and not just an emerging technology that security teams may choose to explore.
The word “augment” is important. The ISM does not suggest replacing cyber security professionals, penetration testers or software security specialists. The intended model appears to position appropriately selected AI expanding the reach, speed and analytical capacity of qualified personnel.
That immediately creates a new assurance question: What makes an AI model “suitable”?
Organisations will need to consider the model’s technical capability, data handling, deployment environment, provenance, access controls, explainability, human oversight and performance under realistic conditions. Simply adopting an AI-enabled security product will not necessarily demonstrate that the control has been implemented effectively.
AI as a software developer
Potentially the most consequential June change is found in the scope of the software development guidance.
The ISM now explicitly states that its software development controls apply to human, AI-assisted, AI-powered and AI-driven development activities. It goes further by stating that references to “software developers” apply to both humans and AI.
This effectively brings AI coding assistants and increasingly autonomous development agents inside the secure software development lifecycle.
Requirements relating to authoritative source repositories, secure design decisions, threat modelling, secrets detection, software artefact scanning, security testing, supply-chain integrity and traceability can no longer be treated as applying only to human-written software.
Another new control, ISM-2121, states that software developers lacking sufficient cyber security knowledge and skills for their projects or tasks are not used.
Because the guidance now defines developers as including AI, a reasonable interpretation is that organisations must consider whether an AI development tool is sufficiently capable, controlled and appropriate for the work it is performing.
This is more demanding than having an approved list of AI tools. It suggests a need to assess AI development capabilities against the risk and complexity of the task, define where human review is mandatory, preserve traceability and continuously evaluate the security of generated code.
It also raises questions that future guidance may need to address. How should the security competence of an AI coding agent be assessed? Can human review compensate for weaknesses in the model? What evidence would demonstrate that AI-generated software has been adequately assured?
The ISM does not yet answer these questions, but it clearly brings them into scope.
AI as a system requiring protection
June also introduces ISM-2123, requiring prompts and outputs associated with a chat session to be securely deleted when that session is removed from an AI application.
This adds an explicit data lifecycle requirement covering information that can easily be overlooked when organisations assess AI platforms.
Prompts and outputs may contain sensitive operational information, personal information, security details or intellectual property. Deleting a visible chat session is not necessarily equivalent to deleting all associated data from application stores, logs, indexes, backups or supporting services.
Implementing this control will therefore require clarity about where conversational data is stored, what deletion technically means, what evidence is available and how security requirements interact with recordkeeping, legal and operational obligations.
The progression across recent ISM releases
The June changes are best understood as part of a continuing evolution.
Earlier releases introduced relatively narrow controls addressing AI application security, including prompt injection mitigation and storing models in formats that do not permit arbitrary code execution.
The December 2025 edition substantially expanded the AI control set. It introduced requirements covering general purpose AI usage policies, model and system cards, model and training data integrity, data validation, performance monitoring, rate limiting, resource limits, fine grained permissions, role based access and output filtering.
March 2026 strengthened governance and data control. It introduced executive AI accountability through GOV-08, requiring boards or executive committees to ensure AI is secure, controllable, human-supervised and used ethically and accountably.
March also added ISM-2103, preventing organisational data from being used to train, fine tune or improve AI models without informed and explicit consent from data owners.
June takes that a step forward. It embeds AI more deeply into mainstream cyber security operations and secure software development.
The direction is becoming clear
The question is no longer simply: How do we secure AI?
It is now also: How do we govern AI-generated work, assure AI-enabled development and responsibly use AI to improve cyber defence?
Beyond the Essential Eight
In an earlier article I explored why the Essential Eight remains an important baseline but cannot address the full range of risks introduced by modern AI systems.
The evolution of the ISM reinforces that distinction.
The new AI controls are marked as not applicable to the Essential Eight maturity model. That does not diminish the value of the Essential Eight. It demonstrates why organisations need to understand it as part of a broader, risk-based security framework rather than as a complete cyber security strategy.
AI affects software development, data governance, identity and access, supply chains, assurance, monitoring and executive accountability. Those concerns cannot be addressed by simply adding another mitigation strategy to the Essential Eight.
What organisations should do now
The immediate response should not be to create another isolated AI checklist.
Organisations should instead revisit existing security capabilities with AI explicitly inside the system boundary:
- Update secure-development policies to cover AI-generated code and autonomous development agents
- Define how AI models are assessed as suitable for defensive security activities
- incorporate AI into threat detection, security testing and vulnerability-assessment strategies
- Establish clear human oversight and escalation requirements
- Map the storage, retention and deletion of prompts and outputs
- Ensure AI risks and control effectiveness are visible to accountable executives
- Identify where current assurance methods are insufficient for AI-enabled systems.
The June ISM does not provide a complete AI governance or assurance framework, nor is that its purpose. The ISM remains cyber focused and risk based, and its controls must be selected and tailored according to each organisation’s systems, operating environment and risk tolerance.
What it does provide is a strong signal
AI is moving from the edge of cyber security guidance into its mainstream. Organisations are now expected not only to protect AI, but also to govern the work it produces and understand how it can responsibly strengthen cyber defence.
That is a significant and necessary evolution.
How is your organisation determining whether an AI model is “suitable” for cyber defence and what evidence would give you confidence in that assessment?
Ghaith Kayed has 20 years of experience delivering AI, IoT, and analytics programs across Australia, New Zealand, UK and the USA. Article originally published here.