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:
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.
This note is an original synthesis of evidence-first mitigation design.
