Skip to content
System hardening
ASD ISMISM-2113

ASD ISM 2113 Configuring AI applications to require human approval before high-impact actions

What it says

AI applications are configured to require human approval before executing sensitive or high-impact actions.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

AI applications must be set up so a person signs off before the AI carries out any sensitive or high-impact action, keeping a human in the loop for consequential decisions.

Many AI applications no longer just answer questions. They can send emails, change records, run scripts, approve transactions, delete data or call other systems on the organisation's behalf. This control says that where an action is sensitive or high-impact, the AI application must be configured so that it stops and waits for a human to approve before the action is executed. The point is that the AI itself should not be the last decision-maker for actions that are hard to undo or that carry real consequences. AI models can misread instructions, be manipulated through malicious prompts, act on incorrect data or simply make confident mistakes. If the application is allowed to carry out consequential actions automatically, a single bad output becomes a real-world event before anyone notices. Requiring human approval at that point puts a checkpoint between the AI's proposal and the outcome, so a person can confirm the action is correct, intended and safe. This is a configuration requirement on the AI application, not just a policy statement. The application must be technically set up so that the sensitive or high-impact action cannot proceed until a human has approved it.

Why it matters

Without a human approval step, an AI application can execute sensitive or high-impact actions on its own, including actions triggered by mistaken reasoning, bad input data or prompt injection by an attacker. The result can be data being sent to the wrong recipient, records or systems being changed or deleted, unauthorised transactions or communications being issued, and damage that is only discovered after the fact and may be difficult to reverse. The organisation loses the ability to catch errors before they cause harm and may be unable to demonstrate that a person was accountable for the action.

How to implement

  1. The AI application owner, with the security team, lists every action the AI application can execute (for example sending messages, modifying or deleting data, executing code, making payments, changing configurations or calling external systems) and classifies each as sensitive or high-impact or not, recording the rationale.

  2. The application administrator configures the AI application, agent framework or orchestration platform so that every action classified as sensitive or high-impact is routed to a human approval step and cannot execute until approval is granted, using the platform's built-in approval, confirmation or human-in-the-loop features where available.

  3. The application owner assigns named approvers or approver roles for each category of action, and the administrator configures the application so that only those approvers can grant approval and the AI application cannot approve its own actions.

  4. The development team designs the approval prompt to present the proposed action in full (target system, data involved, parameters and the AI's stated reason) so the approver can make an informed decision, and sets a default of deny or expire if no approval is received within a defined period.

  5. The administrator enables logging of every approval request and decision (action details, requester, approver, timestamp and outcome), and the application owner adds the approval configuration to change control so that new AI capabilities or configuration changes cannot bypass the human approval requirement without review.

Keep it running

Day to day, this control lives in the configuration of each AI application and in the approval workflow that sits around it. Teams operating AI applications need a clear, maintained list of which actions count as sensitive or high-impact for that application, and the application must be configured so those actions are held for approval rather than executed automatically.

Approvers need enough context to make a real decision, so the approval prompt should show what the AI intends to do, on what data or system, and why. Approvals should be recorded so there is a trail of who approved what and when. Approval queues need to be monitored so that pending actions are not left to time out or, worse, be routinely rubber-stamped because of volume.

When an AI application is updated, given new tools or integrations, or has its permissions expanded, the set of actions it can perform changes, so the approval configuration should be reviewed at the same time. Configuration changes that would bypass or weaken the approval requirement should go through change control.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the inventory of actions each AI application can perform and which of those are classified as sensitive or high-impact.

    Look at

    Check that the inventory covers all the tools, integrations and permissions the AI application actually has, and that the classification has a documented rationale.

    Good evidence

    A complete, current list where every consequential action the AI can take has been considered and the sensitive or high-impact ones are clearly identified.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask to see the AI application's configuration for approval gating, or the platform settings that control human-in-the-loop behaviour.

    Look at

    Confirm that each sensitive or high-impact action is technically configured to pause for human approval, rather than relying on policy or user instructions alone.

    Good evidence

    Configuration screens or files that show the approval requirement is enforced by the application and cannot be executed automatically.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for a demonstration or test where the AI application attempts a sensitive or high-impact action.

    Look at

    Observe whether the action is held pending approval, what information the approver sees, and what happens if approval is refused or not given.

    Good evidence

    The action does not execute until a human approves it, the approver sees enough detail to decide, and refusal or timeout results in the action not being carried out.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for the approval logs for a recent period.

    Look at

    Check that each sensitive or high-impact action has a matching approval record showing who approved it and when, and look for any such actions executed without an approval entry.

    Good evidence

    Every sensitive or high-impact action executed by the AI application is traceable to a human approval decision by an authorised approver.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask who is authorised to approve AI actions and how changes to the approval configuration are controlled.

    Look at

    Check that approvers are defined people or roles, that the AI application cannot approve its own actions, and that configuration changes affecting the approval requirement go through change control.

    Good evidence

    Named approvers, no self-approval path for the AI, and change records showing the approval configuration is protected from casual or unreviewed changes.

Mappings

Closest match in ISO/IEC 27001: A.8.26, Defining security requirements for applications, which this control partially meets.

ISO 27001

ISO/IEC 27001: 2 mappings

  • A.8.26Defining security requirements for applicationsPartially meets
  • A.8.2Management of privileged access rightsSupports

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.