AI Capability Maturity Assessment · Part II. The eight domains
Domain 5 · Practice layerPlatform, architecture and security
In this chapter
Covers where and how AI runs: the approved platform, AI-specific security controls, the approved tool and model list, third-party and embedded AI, and the ability to observe, halt and roll back AI systems.
What this domain covers
Covers where and how AI runs: the approved platform, AI-specific security controls, the approved tool and model list, third-party and embedded AI, and the ability to observe, halt and roll back AI systems.
A secure, assessed platform is what allows sensitive work to use AI at all. AI introduces attack paths that ordinary software controls do not address, such as prompt injection, poisoned data and over-permissioned agents. Vendor AI arrives inside products already in use. And an AI system that cannot be observed, stopped and reversed is not ready for consequential work.
Initiatives for this domain are run through the Platform and security playbook.
The domain at each level
A summary of what the domain looks like at each level. Each criterion below has its own descriptors and pass tests: score the criteria, not this summary. The domain score is calculated from them (see domain aggregation).
| Level | What it looks like |
|---|---|
| 1Initial | AI runs wherever teams set it up, including personal accounts and unapproved services. There are no AI-specific security controls. Vendor AI features are enabled without review. Nobody monitors AI behaviour, and halting a system means turning off the whole application. |
| 2Repeatable | An enterprise assistant is approved, but other AI is built ad hoc. Vendor controls are relied on without mapping AI threats. The approved tool list is not published. Uptime is monitored but behaviour is not, and halt procedures are undocumented. |
| 3Defined | In-scope AI runs on an assessed reference architecture with documented residency. AI threats are mapped to implemented controls, and AI applications are security tested before release. A published approved tool and model list states uses and ceilings. Vendor AI is assessed and contracted with AI clauses. Each system is centrally logged, monitored for behaviour and has a documented halt and rollback with named authority. |
| 4Managed | Guardrails are enforced as code. AI controls are monitored and adversarially tested for higher-tier systems. Unapproved AI use is detected and followed up. Vendors notify model changes under contract. Halt and rollback are rehearsed with time to halt measured, and agents have their own identities with least privilege. |
| 5Optimising | The platform is a governed shared service with self-service onboarding for approved patterns. Routing selects approved models by task and sensitivity. Containment is partly automated, resilience and provider exit are tested, and AI security findings are shared with partners. |
Risks when it is weak
- Data leakage to unapproved or offshore AI services
- Compromise through prompt injection or over-permissioned agents
- Vendor model changes that alter behaviour without notice
- No way to stop a misbehaving system quickly
- Platform gaps that block valuable use cases or push them into shadow IT
The five criteria
| No. | Criterion | Importance | Scope |
|---|---|---|---|
| 5.1 | Assessed AI platform | Core | Enterprise-level |
| 5.2 | AI security controls | Core | Enterprise-level |
| 5.3 | Approved tools and model access | Foundation | Enterprise arrangement, applied locally |
| 5.4 | Third-party and embedded AI | Core | Enterprise arrangement, applied locally |
| 5.5 | Observability, halt and rollback | Core | Local practice |
Criterion 5.1
Assessed AI platform
AI workloads run on approved platforms whose security, hosting and data residency have been assessed, built from a reference architecture that new use cases reuse.
Why it matters
An assessed platform is what lets sensitive work use AI at all. Without one, each team solves hosting, identity, logging and residency on its own, and some do not solve them at all.
The five levels
| Level | What it looks like | To score this level |
|---|---|---|
| 1Initial | AI runs wherever teams set it up: personal accounts, unmanaged cloud subscriptions and vendor sandboxes. | The starting point: no test. |
| 2Repeatable | An enterprise AI service or assistant is provisioned, but other AI workloads are built ad hoc, and the security assessment covers the cloud tenancy rather than the AI services within it. | At least one enterprise AI service is provisioned under central management. |
| 3Defined | A documented AI reference architecture (landing zone, identity, network, logging, model access) has been assessed and approved. In-scope AI workloads run on it, and hosting and data residency are documented for each AI service. | An approved reference architecture with its security assessment, an inventory showing in-scope AI workloads on the platform, and documented residency for each AI service. |
| 4Managed | Platform guardrails are enforced as code (policy definitions, network controls, logging on by default), deviations are detected, and the platform has an operating owner, a capacity plan and service levels. | Policy-as-code configuration, a deviation report from the last quarter, and documented service levels with an operating owner. |
| 5Optimising | The platform is a governed shared service with self-service onboarding for approved patterns, and resilience and sovereignty are proven under test, including an exercised provider exit plan. | A self-service onboarding record for an approved pattern, and an exercised failover or provider exit test. |
Evidence to request
Documents
- AI reference architecture
- Security assessment of the AI platform and services
- Residency register for AI services
- Platform service levels
Records of it operating
- Deviation reports
- Onboarding records for new use cases
- Failover or exit test records
In systems
- Policy-as-code definitions
- Network and logging configuration for AI services
In the evidence request: ER-5-01.
Interview probes
- CIO or CTOWhere do your AI workloads run today, and which of them are outside the approved platform?
- CISO or security leadWhich assessment covers the AI services specifically, not just the cloud tenancy they sit in?
- Engineering or architecture leadHow long does it take a new use case to get onto the platform, and what does it inherit?
Red flags
- AI services switched on in a production tenancy without assessment
- Model calls processed offshore without anyone knowing
- The platform has no operating owner
Standards crosswalk
- ISO/IEC 42001
- Annex A.4
- EU AI Act
- Article 15
- NIST AI RMF
- MANAGE 2
Government and organisation editions
Australian Government edition
AI workloads handling government information should run on services with a current IRAP assessment at the right classification, in facilities consistent with the Hosting Certification Framework, with ISM controls applied. ASD’s Deploying AI Systems Securely sets out the deployment environment expected for AI.
References
Organisation edition
ISO/IEC 42001 requires the resources for AI systems, including tooling and computing, to be identified and documented. APRA-regulated entities must meet information security requirements for platforms holding their information assets.
References
In Governing Intelligence
In the AI governance assessment: Our AI workloads run in a hardened, assessed landing zone.
Initiatives that lift it
Criterion 5.2
AI security controls
AI-specific security controls are implemented and evidenced: an AI usage policy, model and supply-chain provenance, protection against prompt injection and data exfiltration, treatment of retrieved content as untrusted, content filtering, least-privilege access for agents, and security testing of AI applications.
Why it matters
AI introduces attack paths that ordinary controls miss. An agent that reads a poisoned document can be instructed to exfiltrate data; an over-permissioned agent turns one injection into a breach. These threats must be mapped to controls and tested.
The five levels
| Level | What it looks like | To score this level |
|---|---|---|
| 1Initial | Security treats AI as ordinary software. AI-specific threats such as prompt injection, and controls for them, are not considered. | The starting point: no test. |
| 2Repeatable | Some AI controls exist, such as vendor content filters, but there is no mapping of AI threats to controls and no AI-specific security testing. | At least one AI-specific control (for example a content filter or usage policy) can be shown. |
| 3Defined | AI threats (prompt injection, data poisoning, model theft, insecure output handling, excessive agency) are mapped to controls for in-scope systems. The controls are implemented and evidenced, and AI applications are security tested before release. | An AI threat model and control mapping for in-scope systems, and a pre-release security test report for each in-scope AI application released in the last 12 months. |
| 4Managed | Controls are monitored in operation (for example detection of injection attempts and unusual agent actions). Adversarial or red-team testing is done for higher-tier systems, and the control mapping is refreshed with each release of the governing control framework. | Detection rules for AI-specific attacks in operation, a red-team or adversarial test report for each high-tier system, and a control mapping refreshed since the last framework release. |
| 5Optimising | Security testing of AI is continuous and partly automated. Threat intelligence on AI attacks updates controls, and the organisation contributes findings to sector or government partners. | Automated AI security testing in the release pipeline, and a documented contribution of findings to a sector or government partner. |
Evidence to request
Documents
- AI usage policy
- AI threat model
- Control mapping to the governing framework
Records of it operating
- Pre-release AI security test reports
- Red-team or adversarial test reports
- Mapping refresh records
In systems
- Detection rules for AI-specific attacks
- Agent permission configuration
In the evidence request: ER-5-02.
Interview probes
- CISO or security leadWhich AI-specific threats have you tested for, and what did you find?
- Engineering or architecture leadHow do your agents handle instructions embedded in documents, emails or web pages they read?
- CIO or CTOWhen the control framework changes, who updates the AI control mapping, and when was it last done?
Red flags
- Reliance on vendor assurances alone
- No prompt-injection testing for agents that have tools
- No AI usage policy
Standards crosswalk
- ISO/IEC 42001
- Annex A.6
- EU AI Act
- Article 15
- NIST AI RMF
- MEASURE 2
Government and organisation editions
Australian Government edition
The ISM has carried AI controls since June 2024 and expanded them in December 2025 (including a general-purpose AI usage policy and AI development controls), March 2026, June 2026 and September 2026. The September 2026 release added controls for agentic AI, including least-privilege tools and permissions, task-scoped authorisation, treating retrieved content as untrusted and central logging. ASD’s Careful Adoption of Agentic AI Services (May 2026) is the companion guidance. PSPF Direction 002-2026 responds to AI-enabled cyber threats by requiring a legacy technology stocktake and risk management plan by 31 March 2027.
References
Organisation edition
The NIST Generative AI Profile describes information security risks specific to generative AI. High-risk AI systems in the EU must be resilient against attempts to alter their use or outputs. ASD’s AI security publications are written for organisations generally, not only government.
References
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1Information security risk
- Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1MEASURE function
- ISO/IEC 42001:2023 Information technology - Artificial intelligence - Management systemAnnex A.6
- Deploying AI systems securely
- Careful adoption of agentic AI services
- Regulation (EU) 2024/1689 (Artificial Intelligence Act), as amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI)Article 15, high-risk systems
- Prudential Standard CPS 234 Information SecurityFor APRA-regulated entities
In Governing Intelligence
In the AI governance assessment: Our AI workloads run in a hardened, assessed landing zone.
Initiatives that lift it
Criterion 5.3
Approved tools and model access
A published list of approved AI tools and models states what each may be used for and at what sensitivity, access is provisioned through it, and use of AI outside the list is detected and followed up.
Why it matters
Staff will use AI whether or not it is approved. A published list of good-enough approved tools is the most effective control against shadow AI, and detection tells the organisation whether the list is working.
The five levels
| Level | What it looks like | To score this level |
|---|---|---|
| 1Initial | There is no approved list. Staff use whatever AI tools they find, including personal accounts, for work. | The starting point: no test. |
| 2Repeatable | One or two tools are approved, but the list is not published or does not state permitted uses and ceilings. Unapproved tools are blocked inconsistently or not at all. | At least one AI tool is formally approved for work use. |
| 3Defined | A published approved tool and model list states permitted uses and the sensitivity ceiling for each. Requests for new tools go through a defined assessment, and access is provisioned through identity groups. | A published list stating uses and ceiling per tool, a documented request and assessment process, and group-based access provisioning. |
| 4Managed | Use of unapproved AI services is detected (network, browser, expense and software-as-a-service discovery) and followed up. The list is reviewed at least quarterly, and provider model changes are tracked and assessed. | A detection report with follow-up actions from the last quarter, a quarterly list review record, and a log of provider model changes assessed. |
| 5Optimising | Routing chooses among approved models by task, sensitivity and cost. Approvals and retirements of tools follow usage and evaluation evidence, and staff demand is met quickly enough that shadow use is rare and measured. | Model routing configuration, and a tool approval or retirement decision citing usage and evaluation evidence. |
Evidence to request
Documents
- Approved AI tool and model list with permitted uses and ceilings
- New tool request and assessment process
Records of it operating
- Unapproved AI use detection reports and follow-up
- Quarterly list reviews
- Provider model change log
In systems
- Identity groups for AI tool access
- Network or browser controls for AI services
In the evidence request: ER-5-03.
Interview probes
- Frontline staffWhich AI tools are you allowed to use for work, and have you used others?
- CISO or security leadHow do you detect use of AI services that are not on the approved list?
- CIO or CTOHow long does a request for a new AI tool take from start to finish?
Staff survey items: S06 I know which AI tools I am allowed to use for work.
; S07 The approved AI tools meet my needs well enough that I do not need other tools.
; S08 In the last three months I have used an AI tool for work that I was not sure was approved.
Red flags
- The staff survey shows widespread use of unapproved tools
- Approval of a new tool takes months, so staff work around it
- The list exists but only the security team can see it
Standards crosswalk
- ISO/IEC 42001
- Annex A.2Annex A.9
- EU AI Act
- Article 26
- NIST AI RMF
- GOVERN 6
Government and organisation editions
Australian Government edition
The APS AI Plan provides GovAI, a government-hosted AI platform, and its GovAI Chat assistant. The ISM requires a general-purpose AI usage policy (December 2025) and, since March 2026, that personal devices do not grant access to unapproved AI agents. PSPF directions can prohibit specific AI products, as Direction 001-2025 did for DeepSeek, and Direction 004-2025 introduced a Commonwealth Technology Standard.
References
- AI Plan for the Australian Public Service 2025GovAI and GovAI Chat
- Information Security ManualAI usage policy; unapproved AI agents on personal devices
- PSPF Direction 001-2025 on DeepSeek Products, Applications and Web Services
- PSPF Direction 004-2025 on Commonwealth Technology Management
Organisation edition
ISO/IEC 42001 requires an AI policy and controls on the intended use of AI systems. The OAIC’s guidance on commercially available AI products sets out the privacy checks to make before approving a tool.
References
In Governing Intelligence
Initiatives that lift it
Criterion 5.4
Third-party and embedded AI
AI supplied by vendors, including features switched on inside existing products, is assessed before use, contracts carry AI-specific terms, and third-party AI is contained within agreed boundaries.
Why it matters
Much of an organisation’s AI arrives inside software it already licenses. Without disclosure terms and an assessment before enablement, AI starts processing organisational data under contracts written before AI existed.
The five levels
| Level | What it looks like | To score this level |
|---|---|---|
| 1Initial | Vendor AI is adopted without any review, and AI features arrive inside existing products unnoticed and are used by default. | The starting point: no test. |
| 2Repeatable | Procurement asks about AI for new purchases, but existing contracts lack AI terms and embedded features are not tracked. | Procurement documents for at least one recent purchase ask about AI. |
| 3Defined | An AI assurance checklist is applied to new procurements and renewals. Standard contract clauses cover data use (including no training on organisational data without consent), disclosure of AI features and model changes, security, audit rights and exit, and embedded features are assessed before they are enabled. | The checklist and standard clauses, applied to at least three recent procurements or renewals, and assessment records for embedded features enabled in the last 12 months. |
| 4Managed | Vendor AI is monitored in operation (data flows, feature changes, incidents). Vendors notify model changes under contract and the notifications are acted on, and high-risk suppliers are reassessed annually. | Vendor model-change notifications with the action taken, and annual reassessment records for high-risk suppliers. |
| 5Optimising | Assurance flows both ways along the supply chain: the organisation states its assurance expectations and receives structured evidence, and vendor AI performance and incidents inform renewal decisions. | A renewal decision that cites vendor AI performance or incident evidence. |
Evidence to request
Documents
- AI procurement and assurance checklist
- Standard AI contract clauses
Records of it operating
- Completed checklists for recent procurements
- Embedded feature assessments
- Vendor change notifications and actions
- Supplier reassessments
In systems
- Configuration limiting what third-party tools and connectors can reach
In the evidence request: ER-5-04.
Interview probes
- CIO or CTOWhich of your ten largest software vendors switched on AI features in the last year, and how did you find out?
- Legal, privacy and records leadDo your contracts stop vendors training their models on your data?
- CISO or security leadHow are agents, plugins or tools from external providers limited in what they can reach?
Red flags
- AI features enabled by default in licensed software with nobody deciding
- No contract clause on training with organisational data
- External tool connections (plugins, MCP servers, connectors) added without review
Standards crosswalk
- ISO/IEC 42001
- Annex A.10
- EU AI Act
- Article 25Article 26
- NIST AI RMF
- GOVERN 6MANAGE 3
Government and organisation editions
Australian Government edition
Policy v2.0 is supported by DTA guidance on AI procurement, and procurement is one of the five cornerstones of the assurance framework. Since March 2026 the ISM has required that organisational data is not used to train AI without consent.
References
- Guidance on AI procurement in government
- Policy for the responsible use of AI in government, version 2.0Procurement and assurance
- National framework for the assurance of artificial intelligence in governmentCornerstone: procurement
- Information Security ManualNo training on organisational data without consent (March 2026)
Organisation edition
ISO/IEC 42001 sets controls for third-party and customer relationships. APRA-regulated entities must manage material service providers under CPS 230, including AI services they rely on. The EU AI Act allocates responsibilities along the AI value chain.
References
- ISO/IEC 42001:2023 Information technology - Artificial intelligence - Management systemAnnex A.10
- Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1GOVERN 6
- Voluntary AI Safety StandardGuardrail 8
- Prudential Standard CPS 230 Operational Risk ManagementMaterial service providers, for APRA-regulated entities
- Regulation (EU) 2024/1689 (Artificial Intelligence Act), as amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI)Article 25 value chain
In Governing Intelligence
In the AI governance assessment: Third-party AI tools run in contained enclaves with no uncontrolled egress.
Initiatives that lift it
Criterion 5.5
Observability, halt and rollback
AI systems in operation are observable (central logging, quality, drift and override monitoring), agents act under their own identities, and each in-scope system has a tested way to halt it and roll back.
Why it matters
An AI system that cannot be seen, stopped and reversed is not ready for consequential work. The kill switch and rollback must be rehearsed, not assumed, and agent actions must be attributable to the agent that took them.
The five levels
| Level | What it looks like | To score this level |
|---|---|---|
| 1Initial | AI behaviour in production is not monitored. Stopping a system means switching off the whole application or calling the vendor. | The starting point: no test. |
| 2Repeatable | Technical uptime is monitored, but AI behaviour (output quality, drift, overrides) is not, and halt procedures are undocumented. | Uptime or error monitoring exists for at least one AI system. |
| 3Defined | In-scope systems send logs to a central platform. Behaviour measures (quality samples, drift indicators, override rates, cost) are defined and monitored, and each system has a documented halt and rollback procedure with named authority. | Central logging evidence for each in-scope system, defined behaviour measures, and a documented halt and rollback procedure naming who may invoke it. |
| 4Managed | Halt and rollback have been rehearsed for high-tier systems in the last 12 months with time to halt measured. Alerts on behaviour thresholds trigger defined responses, and agents have unique identities so their actions are attributable. | A rehearsal record for each high-tier system in the last 12 months with time to halt, an alert-response record, and evidence that each agent acts under its own identity. |
| 5Optimising | Monitoring uses leading indicators of drift and failure, containment applies automatically when thresholds are breached, and rehearsal results improve the design of new systems. | Automated containment configuration, and a design change traced to a rehearsal finding. |
Evidence to request
Documents
- Behaviour measures and thresholds per system
- Halt and rollback procedures
Records of it operating
- Rehearsal records with times
- Alert-response records
- Override and drift reports
In systems
- Central logging configuration
- Monitoring dashboards
- Agent identity and permission records
- Kill switch configuration
In the evidence request: ER-5-05.
Interview probes
- Engineering or architecture leadHow would you stop this agent mid-task, and what would happen to work already in progress?
- CISO or security leadCan you show every action an agent took last week, attributed to that agent rather than to a shared account?
- Use-case owner or business leadWhat tells you the system is still behaving as intended?
Red flags
- The kill switch exists only in theory
- Agents run under shared service accounts or a person’s credentials
- Override rates are not monitored
Standards crosswalk
- ISO/IEC 42001
- Clause 9.1Annex A.6
- EU AI Act
- Article 14Article 72
- NIST AI RMF
- MANAGE 2MANAGE 4
Government and organisation editions
Australian Government edition
The ISM’s September 2026 release requires a unique identity for each AI agent, an AI agent register and central logging for agentic AI applications. ASD’s agentic AI guidance stresses the ability to monitor and interrupt agents.
References
- Information Security ManualAgent identity, agent register and central logging (September 2026)
- Careful adoption of agentic AI services
- Technical standard for government’s use of artificial intelligence (AI technical standard), with the Agentic AI addendum
Organisation edition
The NIST AI RMF expects mechanisms to supersede, disengage or deactivate AI systems that perform outside their intended use, and post-deployment monitoring plans. Human oversight of high-risk systems in the EU includes the ability to interrupt the system through a stop procedure.
References
- Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1MANAGE 2 and MANAGE 4
- ISO/IEC 42001:2023 Information technology - Artificial intelligence - Management systemClause 9.1; Annex A.6
- Guidance for AI AdoptionMaintain human control; test and monitor
- Voluntary AI Safety StandardGuardrail 5
- Regulation (EU) 2024/1689 (Artificial Intelligence Act), as amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI)Article 14 human oversight; Article 72 post-market monitoring
In Governing Intelligence
- 10.4Operating safely: monitoring, drift and the kill switch
- 9.2Five runtime controls for governing AI
In the AI governance assessment: Runtime controls operate, and the kill switch has been rehearsed.
Initiatives that lift it
In Governing Intelligence
The framework chapters that describe the practice this domain measures, and the governance assessment questions that test it at a higher level.
- 7.4The secure, sovereign foundation
- 13.3Govern the everyday assistants
- 13.4Buy AI well
- Appendix DThird-party and proprietary-AI-tool assurance checklist
In the AI governance assessment: Our AI workloads run in a hardened, assessed landing zone.
Third-party AI tools run in contained enclaves with no uncontrolled egress.
Runtime controls operate, and the kill switch has been rehearsed.
This assessment is not legal advice and is not a certification. Obligations and dates were checked against official sources on 15 October 2026; confirm them against the source instruments, which can change.