What does the ASD Essential Eight require for AI systems?
The ASD Essential Eight applies to AI the same way it applies to any other software or system: AI models, pipelines, inference endpoints and AI-enabled SaaS must be brought inside the eight mitigation strategies - application control, patching, macro settings, user application hardening, restricting administrative privileges, patching operating systems, multi-factor authentication and regular backups - and assessed against the Maturity Model. AI is in scope; it is not a special case.
The Essential Eight is the Australian Signals Directorate's (ASD) prioritised baseline of eight mitigation strategies, drawn from its broader Strategies to Mitigate Cyber Security Incidents. It is assessed against a four-tier Essential Eight Maturity Model, first published in June 2017 and most recently hardened in November 2023. It is mandatory for non-corporate Commonwealth entities and is the de facto cyber baseline for Australian enterprise and critical infrastructure.
The strategic problem for security leaders in 2026 is that AI does not sit neatly inside existing controls. A generative AI tool adopted on a corporate card bypasses application control. An unpatched open-source inference server is an unpatched application. An AI admin console without multi-factor authentication is an unprotected privileged account. ASD's own AI guidance is explicit that AI must be secured alongside, not outside, the Essential Eight - and ASD now frames the baseline as a defence against AI-accelerated attacks. In its Annual Cyber Threat Report 2024-25, ASD assessed that the prevalence of AI "almost certainly enables malicious cyber actors to execute attacks on a larger scale and at a faster rate".
How do the eight mitigation strategies map onto AI?
Each of the eight strategies has a concrete AI interpretation. Treating AI as out-of-scope is the single most common gap, because the systems are new but the control objectives are unchanged.
Application control
Only approved AI applications, models, agents and browser extensions should be allowed to execute. This is precisely where shadow AI defeats the control: staff adopt generative AI tools and copilots faster than security teams can approve them, and unmanaged AI desktop clients, CLI tools and browser plug-ins run code outside any allow-list. Application control over AI tools depends on first knowing what AI is in use.
Patch applications and patch operating systems
AI software is software. Inference servers, vector databases, model-serving frameworks, ML libraries and AI gateways must be patched on the same risk-driven cadence the Maturity Model requires for any internet-facing or productivity application, and the operating systems hosting them must be patched in step.
Configure Microsoft Office macro settings and user application hardening
AI features now ship inside the Office suite, browsers and PDF readers. Hardening means controlling AI assistants embedded in productivity applications, disabling unneeded AI integrations, and constraining the browser surface where most shadow AI access actually happens.
Restrict administrative privileges and multi-factor authentication
AI admin consoles, model registries, training pipelines, API key vaults and agent orchestration platforms are high-value privileged surfaces. They require restricted, justified administrative access and phishing-resistant MFA - identical to any other privileged system, but frequently overlooked because the platform is procured as SaaS.
Regular backups
Backups must extend to AI configuration, system prompts, guardrail and policy definitions, fine-tuning datasets and the audit record - so an AI control plane can be restored to a known-good, tested state after compromise or corruption.
What do Maturity Levels ML0 to ML3 mean for AI deployments?
The Essential Eight Maturity Model defines four levels (Maturity Level Zero to Maturity Level Three). With the exception of ML0, each level is calibrated to defend against an increasing level of adversary tradecraft and targeting, and organisations are expected to reach the same level across all eight strategies before progressing.
- Maturity Level Zero (ML0): weaknesses in the organisation's overall cyber security posture that, when exploited, could compromise confidentiality, integrity or availability. Unmanaged shadow AI and unpatched AI tooling sit here.
- Maturity Level One (ML1): defends against adversaries using commodity, widely available tradecraft - publicly known exploits and stolen or guessed credentials. ASD notes ML1 may suit small to medium enterprises.
- Maturity Level Two (ML2): defends against more adaptive actors who invest in evading detection and exploiting weaknesses such as older software or inadequate logging. ASD notes ML2 may suit large enterprises, and it is the mandatory minimum for non-corporate Commonwealth entities.
- Maturity Level Three (ML3): defends against actors willing to invest more time in a target and in tooling. ASD notes ML3 may suit critical infrastructure providers and organisations in high-threat environments.
For AI specifically, the level you target dictates rigour: ML1 might mean basic allow-listing of approved AI tools; ML2 adds adaptive controls, comprehensive logging of AI use, and restriction of AI admin access; ML3 demands the tightest control over model supply chains, inference endpoints and privileged AI operations. Reaching parity is hard even without AI - according to the Commonwealth Cyber Security Posture in 2025, only about 22% of Commonwealth entities reached ML2 across all eight strategies, up from 15% in 2024 but still below the 25% recorded in 2023 before ASD hardened ML2 in November 2023.
Why does shadow AI break application control - and how do you fix it?
Shadow AI breaks application control because you cannot allow-list, patch, harden or restrict a tool you do not know exists. Unsanctioned generative AI services, browser-based copilots and personal API keys execute outside any approved-software boundary, which by definition is a Maturity Level Zero condition for the application-control, hardening and privilege strategies.
The fix is sequential and unavoidable. You cannot control what you have not discovered, so the first move is a continuous inventory of AI usage across the organisation - sanctioned and unsanctioned, SaaS and self-hosted, human and agentic. From that inventory you can define an approved-AI allow-list, route access through a controlled gateway, and bring the remaining strategies (patching, MFA, admin restriction, backups) to bear on the tools that survive review.
This is where a dedicated control layer matters. ASD's Engaging with Artificial Intelligence guidance, published in January 2024 with international partners, recommends applying its advice alongside the Essential Eight, knowing the constraints of your AI systems, and training staff to use them securely. Discovery, allow-listing and access control are the operational mechanics that make that recommendation real.
What does ASD say about securing AI, and is it mandatory?
ASD has published dedicated AI security guidance that sits beside the Essential Eight rather than replacing it. The Essential Eight itself remains mandatory only for non-corporate Commonwealth entities; the AI-specific publications are guidance, not regulation - but they are the authoritative statement of how ASD expects AI to be secured, and they explicitly reference the Essential Eight.
- Mandatory baseline: Under the Department of Home Affairs' Protective Security Policy Framework (PSPF Policy 10), non-corporate Commonwealth entities have been required to implement all eight strategies to at least Maturity Level Two since 1 July 2022, and to consider whether their threat environment warrants ML3.
- De facto baseline: For Australian enterprise, critical infrastructure and state agencies, the Essential Eight is widely adopted as the expected standard - frequently written into contracts, cyber insurance and board risk appetites even where it is not legally compulsory.
- AI guidance: ASD's Engaging with Artificial Intelligence (January 2024) and Deploying AI Systems Securely (April 2024), both co-sealed with Five Eyes and partner agencies, set out secure-by-design expectations for AI, and a 2025 publication on AI data security extends this to protecting AI training and inference data.
The practical reading for a CISO or government security lead is that AI in scope of the Essential Eight is not optional interpretation - it is the only defensible interpretation. If your Essential Eight assessment does not enumerate AI tools, models, pipelines and consoles, your assessment is incomplete.
How does Areebi help bring AI inside the Essential Eight?
Areebi is a Secure AI Control Plane built for Australian regulated mid-market and enterprise. It is designed to make AI systems governable against the same control objectives the Essential Eight enforces - by giving security teams discovery, application-level control, privileged-access enforcement and a restorable audit record for AI, deployed where your data must stay.
Areebi is model-agnostic and privately deployable on Docker, Kubernetes, on-premises or private cloud, so AI data and the control plane can remain in Australia - relevant for sovereignty-sensitive workloads and Commonwealth, critical infrastructure and state contexts. In honest terms: Areebi is pre-launch, in stealth and not yet SOC 2 certified, with SOC 2 readiness in progress. It is a control layer that helps you operationalise the AI-relevant parts of the Essential Eight; it is not a substitute for implementing the full baseline, and it does not assess or certify your maturity level.
- Shadow-AI discovery and inventory establishes the AI asset list that application control depends on.
- A policy engine and guardrails enforce which AI tools, models and actions are approved - the practical expression of application control over AI.
- Access control supports restricting administrative privileges and applying authentication requirements to AI consoles and gateways.
- Real-time DLP constrains what sensitive data can flow into and out of AI systems.
- Immutable audit logging provides the comprehensive, tamper-evident record ML2 and ML3 expect, and a configuration baseline you can back up and restore.
Explore the platform, the policy engine and audit logging, or run a structured AI governance assessment.
What are the operational steps to put AI under the Essential Eight?
Bringing AI inside the Essential Eight is a sequence, not a single project. The order matters because discovery gates everything downstream - you cannot allow-list, patch or restrict what you have not found.
- Discover and inventory all AI. Build a continuous register of AI tools, models, pipelines, inference endpoints, agents and AI-enabled SaaS - sanctioned and shadow.
- Set your target maturity level. Decide on ML1, ML2 or ML3 per your obligations and threat environment, and plan to reach it across all eight strategies, not just the convenient ones.
- Apply application control to AI. Define an approved-AI allow-list and route access through a controlled gateway; block or quarantine unsanctioned tools.
- Patch AI software and its hosts. Bring inference servers, AI libraries, vector stores and underlying operating systems into your vulnerability and patch programme.
- Lock down AI admin surfaces. Restrict administrative privileges and enforce phishing-resistant MFA on AI consoles, model registries and key vaults.
- Harden AI in productivity tools. Control embedded AI assistants, macro and browser settings where AI features execute.
- Back up AI configuration and audit data. Include prompts, guardrails, policy definitions and logs in tested, restorable backups.
- Assess, evidence and re-assess. Measure maturity across all eight strategies including AI, retain evidence, and re-test as your AI estate changes.
For the broader Australian picture, see our guides to Australia's AI rules in 2026, Australia AI governance and the Privacy Act, APRA CPS 234 and AI for financial services, and the Privacy Act automated decision-making transparency rules.