PENTESTY · EDITORIAL ANALYSIS · · 4 min read
AI in incident response: which actions should be automated?
Faster blocking helps only when the target and decision are correct. A practical approach to approving response automation with verifiable limits.
By Pentesty
A defense proposal is not evidence of preventive capability
CyberSec Brazil covered South Korea's discussion of AI for anticipating attacks. The official October 6, 2026 cabinet briefing confirms calls to review security across essential systems and private organizations. Those statements do not establish a system capable of stopping every attack. The practical enterprise question is how to approve specific interventions against observable acceptance criteria.
Define a narrow execution contract
Start with a bounded use case and laboratory accounts. Record the required signal, eligible resource, retry limit, accountable person and expected state after execution. Include conditions requiring the workflow to stop for review. This Pentesty proposal structures a workflow test; it does not describe an implementation by the South Korean government.
- Target: the action can reach only resources approved for that use case.
- Evidence: the decision identifies supporting events, including their timing and origin.
- Execution: the tool performs an allowed operation and records its actual outcome.
- Recovery: an authorized operator can restore the previous state or activate the agreed alternative.
Test false positives and partial failures first
Create synthetic events that resemble an attack but represent permitted activity. Check whether the workflow distinguishes a suspicion from a condition approved for intervention. A convincing summary may still identify the wrong account, environment or time window. Validate those fields independently before using them to select the affected resource.
Next, simulate tool failures. Was a session revoked even though the confirmation was lost? Did a tool deny the request while the model reported success? Require observation of the resulting state before closing the case. Retries should remain within the agreed limit so that attempted recovery does not increase the disruption.
Measure workflow outcomes rather than textual confidence
Accept changes using a separate evaluation set. Compare correct outcomes, inappropriate interventions, referrals and time to a useful decision. Also record how often recovery was necessary and whether the operator completed it. A confidence score generated by the model cannot replace those observed results or establish that a recommendation was authorized.
NIST SP 800-61 Rev. 3 incorporates incident response into risk management. In our editorial application of that principle, the service owner should understand accepted boundaries and suspension conditions. Changes to models, tools, event sources or permissions should trigger the relevant tests before execution authority is expanded to additional environments.
A security assessment can examine integration authorization and agreed access paths. The response exercise also needs the people who operate the service. Its objective is to demonstrate a bounded, recoverable intervention with evidence that supports challenging a decision and improving the workflow, rather than assuming that automation itself establishes effective protection.
Frequently asked questions
Can AI automatically block a suspicious account?
Policy and case impact should determine that choice. Require an approved target, sufficient evidence and a review or recovery path rather than giving the model unrestricted authority over available accounts.
Does a detailed explanation prove the action was correct?
No. Verify supporting events, target identity, authorization and the actual resulting state. Well-written text can still describe an incorrect conclusion or an action that never succeeded.
How can we test without affecting real users?
Use synthetic accounts, resources and events in an authorized environment. Include false positives and partial failures, with stopping conditions and acceptance criteria established before the exercise begins.
When should response automation be suspended?
Set triggers before activation, such as inappropriate interventions, missing evidence or failed recovery. An accountable person must be able to stop the workflow and take over the decision.
Sources and references
- Cyber Security Brazil: editorial news reference
- Presidency of South Korea: October 6 cabinet briefing
- NIST SP 800-61 Rev. 3: incident response
Original Pentesty analysis, published October 15, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.