AI Applications Flag Risky Actions for Approval
AI applications are configured so that a defined set of risky actions are held for human approval before they are executed.
Plain language
AI (artificial intelligence) applications are software systems that can decide and act on their own, such as agents that move money, change records, or send messages without a person clicking each step. This control means the organisation writes down which actions are too risky to leave to the machine, and configures the AI so that those actions stop and wait for a person to approve them before they happen. It keeps a human in the loop for the decisions that could do real damage if the AI gets them wrong.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
19 June 2026
E8 maturity levels
N/A
Guideline
Guidelines for system hardeningSection
User Application HardeningOfficial control statement
AI applications are configured to flag organisationally defined risky actions for human approval prior to their execution.
Why it matters
If this control is absent, an AI application can carry out a high-consequence action with no human check, for example autonomously transferring funds to an attacker-supplied account, mass-deleting production records, or sending external communications on the organisation's behalf, before anyone has the chance to catch the error or block it.
Operational notes
Maintain the list of organisationally defined risky actions as a living register and reduce it to enforceable rules inside each AI application rather than relying on a static document alone. Review and re-validate the risky-action list after every AI-related incident and whenever an AI application gains a new capability, integration, or tool that could perform a consequential action. Re-test the approval gates after each model or version update, because changes to the underlying model or its configuration can silently alter or bypass how actions are classified and routed for approval. Confirm that flagged actions genuinely halt and cannot proceed on timeout, default-allow, or approver inaction.
Implementation tips
- Compile the organisationally defined list of risky actions from incident history, threat modelling of each AI application's available tools and integrations, and subject-matter input, with measurable triggers such as a payment value threshold, deletion of more than N records, or any message sent outside the organisation.
- Configure each AI application to intercept the listed risky actions through guardrails, tool-permission settings, or agent action policies so the action pauses and is queued for human approval before it executes.
- Set the approval gate to fail closed: if no approver responds, the request times out, or approval is denied, the AI application must not execute the action under any default-allow or auto-proceed behaviour.
- Assign named approvers with the authority and context to approve or block each class of risky action, and bind specific action types to specific approver roles in the configuration.
- Enable logging that captures the proposed action, the approver, the timestamp, and the approve/reject outcome for every flagged action, and confirm execution is gated on a recorded approval.
- Re-validate every approval gate after each model or version update and after any new tool or integration is added, and update the risky-action register following each AI incident or capability change.
Audit / evidence tips
- Take a sample of the organisationally defined risky actions and trace each one into the live AI application configuration to confirm it is wired to a human-approval gate, not merely listed on paper.
- Trigger or simulate a defined risky action in a test environment and confirm the AI application halts execution and routes it for approval rather than completing it autonomously.
- Inspect the approval logs for flagged actions and confirm each records a named approver and decision, and that no logged risky action executed before approval was granted.
- Confirm that an unapproved, timed-out, or denied flagged action does not fall through to a default-allow state and remains blocked from executing.
- Review change records for the most recent model or version update and confirm the approval gates were re-validated afterwards and still fire for every defined risky action.
- Check that recent AI incidents or capability changes triggered a documented review and update of the risky-action register and its enforcement rules.
Cross-framework mappings
How ISM-2113 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| handshake Supports (3) expand_less | ||
| Annex A 5.15 | ISM-2113 includes a pre-execution human approval step when AI applications identify risky actions | |
| Annex A 8.2 | ISM-2113 requires AI applications to obtain human approval before executing risky actions | |
| Annex A 8.26 | ISM-2113 requires AI applications to flag organisationally defined risky actions for human approval prior to execution | |
| extension Depends on (2) expand_less | ||
| Annex A 8.9 | ISM-2113 mandates AI applications to flag risky actions for human approval before execution | |
| Annex A 8.32 | ISM-2113 requires AI applications to ensure human approval for defined risky actions prior to execution, depending on stable and controll... | |
ISO 42001
| Control | Notes | Details |
|---|---|---|
| handshake Supports (2) expand_less | ||
| Annex A 6.2.2 | ISM-2113 requires AI applications to seek human approval for defined risky actions pre-execution | |
| Annex A 6.2.4 | ISM-2113 requires AI applications to flag risky actions and obtain human approval prior to execution | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.