Attack mitigation is the point at which a security system can cause operational damage. Blocking a host, isolating a segment or rotating credentials may be exactly right, but the same action can interrupt a critical service when the hypothesis is wrong.
LLMs can help compare response options, provided that the action space is constrained outside the model.
1. Separate evidence, recommendation and action
An incident record should distinguish three objects:
- Evidence: observations and their provenance.
- Recommendation: a proposed response with assumptions and expected effects.
- Action: a policy-approved operation performed by a separate control plane.
Conflating these objects makes it impossible to tell whether a bad outcome came from detection, reasoning or execution.
2. A bounded mitigation proposal
For each candidate action , ask the model to return:
If the formula does not fit, focus it and use the left and right arrows, or scroll horizontally.The proposal is incomplete if it lacks a scope or a recovery path. A recommendation to “block the attacker” is not operationally meaningful without identifying the asset, duration and validation step.
3. Playbooks as the authority boundary
The LLM should select or fill parameters for approved playbooks rather than invent commands. A policy engine can reject actions that exceed the asset's criticality, the user's authority or the allowed blast radius.
This also limits prompt injection. Untrusted text may influence the explanation, but it cannot grant the model a new permission.
4. Feedback after mitigation
The system should record whether the action reduced the signal, created a side effect, required rollback or revealed a different root cause. This feedback improves the next investigation, but it should be reviewed before it becomes training data.
Useful fields include:
- evidence identifiers,
- chosen playbook and parameters,
- approval identity,
- observed post-action state,
- rollback or expiry event,
- analyst correction.
5. A realistic first use case
Begin with read-only comparison of two or three approved options. Ask the model to state why one option is better, what evidence is missing and what would falsify the recommendation. Only then consider low-risk automation with a short expiry and automatic rollback.
The purpose of LLM support is not to remove the responder from the loop. It is to make the trade-off between speed, evidence and operational risk easier to inspect.
From a recommendation to a verifiable transaction
As a design example, consider approved temporary isolation of a laboratory machine. The proposal identifies the asset using a stable identifier, the playbook and its version, supporting evidence and expected before/after states. It also records the owner and expiration. It must not depend on the model remembering an earlier instruction.
Before execution, the controller checks permissions and preconditions again. State may have changed since approval: the asset may have been replaced, the alert closed or the policy updated. This time-of-check versus time-of-use problem requires execution-time validation, not merely plan-generation checks.
Idempotency, expiry and compensation
A network retry must not duplicate an action. Assign an operation identifier and check whether it has already been applied. If an action has no exact inverse, document a compensating action and its limitations; revoking a token does not safely restore the same secret.
Evaluate this workflow using laboratory failures: a missing tool response, timeout after applying a change or permission revoked before execution. Measure duplicate actions, out-of-scope changes and failed recoveries. These differ from an incorrect explanation.
NIST SP 800-61 Rev. 3 provides an incident-response framework. OWASP's excessive agency guidance describes risks from excessive functionality, permissions and autonomy. The transaction patterns above are an engineering proposal for applying these concerns to a concrete workflow.
Bounded autonomous cyberdefense develops the control loop, and agent prompt-injection tests cover manipulated inputs.
