AI Incident Response: Where Should Human Approval Sit?

An AI tool that summarises an alert might also recommend isolating a host or disabling a compromised account. 

Acting on that recommendation can disrupt critical systems, which makes human approval an important part of AI-assisted incident response. 

Security teams need clear rules for which actions require approval, who can authorise them, and what evidence must be reviewed before execution. 

In our recent study, eight of the 43 organisations studied in depth had explicit human approval gates, while 15 discussed autonomy or agentic behaviour. None described allowing AI to independently make high-consequence containment or eradication decisions. 

These findings begs the next question: how do you give AI room to accelerate investigations while maintaining control over consequential actions?

1. Decide Which Actions Require Human Approval

The level of approval should reflect what an action could change and the consequences of getting it wrong.

An AI-generated summary carries less operational risk than disabling a privileged account or isolating a production server.

Match Approval to the Risk of Each Action

Start by mapping the actions your AI tools can recommend or execute. Then define who has authority over each one. 

Define the Limits of Each Approval

The same action can carry different risks depending on the asset involved. Isolating an employee’s workstation may be manageable. But isolating a shared server could interrupt several business services.

Approval should therefore cover a specific action, target, and scope. Permission to isolate one endpoint should never automatically authorise isolation across every affected system.

If the scope or business impact changes, the team should reassess the decision before proceeding.

2. Build an Approval Process That Works

Once you know which actions need approval, the next step is making those decisions easy to review and enforce. 

Give Approvers the Evidence They Need

An analyst cannot make an informed decision from a generic request to “remediate the threat.” The approval request should explain exactly what the system intends to do.

For example, before approving endpoint isolation, the analyst should see:

• Target: The exact device or asset identifier.
• Evidence: Suspicious activity linked to the original telemetry.
• Business impact: The asset's role and any known dependencies.
• Proposed action: What will change and how it can be reversed.
• Authority: Who can approve the action and how long that approval remains valid.

This gives responders enough context to assess the recommendation without reconstructing the entire investigation.

Enforce Approval Outside the Model

The application should enforce approval before a response tool executes an action. OWASP’s Excessive Agency guidance recommends limiting model capabilities and using downstream authorisation controls for sensitive operations.

A practical workflow has three steps:

1. Recommendation: AI reviews permitted evidence and proposes an action.
2. Authorisation: An approved responder reviews, rejects, or escalates the proposal.
3. Execution: The application validates the approval, target, and permitted scope before calling the response tool.

Keep permissions limited to the task. An AI system preparing recommendations may need read access, while production changes should pass through a separate execution process.

The application should also reject requests that exceed the approved scope, even if the model produces a technically valid tool call. 

Record and Verify Every Action

Each approval should remain tied to the proposal reviewed. If an analyst approves isolating a workstation but further investigation identifies it as a critical jump host, that change requires another decision.

Record who approved the action, the supporting evidence, what the system executed, and then verify the result. 

A successful API request does not always mean the endpoint was isolated. Confirm the resulting state and that the correct asset was affected. 

Where execution fails or the outcome is uncertain, follow a defined retry or escalation procedure.

This gives your team a reliable audit trail and helps prevent an incorrect or incomplete action from going unnoticed. 

3. Keep Approval Working Under Pressure

Approval processes must work during overnight shifts, major incidents, and situations where critical systems are affected. A policy that depends on one unavailable decision-maker can create unnecessary delays.

Prepare for Urgent Decisions and Handoffs

Define how authority works before an incident occurs.

• Assign approval by role: Identify who can authorise each action, including deputies and on-call responders.
• Set escalation routes: Specify when decisions require incident command or a service owner.
• Handle expired requests: Escalate unanswered approvals rather than treating a timeout as permission.
• Allow limited automatic actions: Pre-authorise specific responses only under clearly defined and tested conditions.
• Preserve decisions across shifts: Make pending approvals, completed actions, and restrictions visible to incoming responders.

Also plan for system failures. If asset information is unavailable or a response integration fails, the workflow should make that limitation clear and follow the agreed procedure.

Test the Process With Realistic Scenarios

An approval gate needs to work when analysts are busy and the evidence is incomplete. Test it using scenarios that challenge both the person reviewing the recommendation and the controls enforcing their decision. 

Include cases where:

• The recommendation is correct: The analyst has enough evidence to approve containment.
• The evidence is incomplete: AI proposes an action without sufficient support.
• The business impact is high: A genuine threat affects a critical service.
• Approval is invalid: The request has expired, the target has changed, or the approver lacks authority.
• Execution fails: The response tool returns an error or an uncertain result.

Measure a few practical outcomes: 

Run these scenarios during realistic workloads and shift handoffs to identify delays or weaknesses.

Use the findings to improve approval rules, permissions, and escalation routes. Retest whenever you expand the system’s authority or change its response integrations.

Put Your Incident Response Decisions to the Test

Clear approval rules help your team act faster and avoid costly mistakes. But how well do those rules hold up when an incident is moving and every decision counts?

TryHackMe gives your security team a realistic environment to practise containment decisions, escalation, and coordination during an active incident.