Autonomous cyberdefense is often described as a model that detects an attack and responds immediately. That description hides the hard part: deciding which actions are allowed when observations are partial, the adversary is adaptive and the cost of a mistake is asymmetric.
A more useful framing is a bounded control loop. The loop can automate repetitive transitions, but every transition needs evidence, a policy and a way to stop or recover.
1. From prediction to control
Let represent the security state estimated at time , the observations and a candidate action. A simplified loop is:
If the formula does not fit, focus it and use the left and right arrows, or scroll horizontally.where is the active policy and contains recovery constraints. The model may help estimate or rank actions, but it should not silently redefine .
2. Four layers of autonomy
It is useful to separate:
- Detection: identify a deviation and attach evidence.
- Interpretation: relate the deviation to assets, tactics and plausible causes.
- Planning: compare actions that are permitted by policy.
- Execution: apply a reversible or approved change and observe its effect.
An LLM is a natural assistant for interpretation and plan drafting. It is a much weaker authority for detection and execution, especially when the input contains untrusted text.
3. The human checkpoint is part of the design
Human oversight should not be a button added at the end of a demo. The system should show the evidence, the proposed action, the expected effect, the reversibility and the conditions that would cancel it. Low-risk actions can be automated under policy. High-impact actions should require explicit approval.
The boundary can be represented as a risk function:
If the formula does not fit, focus it and use the left and right arrows, or scroll horizontally.where is the current evidence and is the consequence of an incorrect action. A threshold should be a governance decision, not a hidden model preference.
4. Recovery and learning
Autonomy without recovery is only fast failure. Every automated action needs a rollback, a timeout or a quarantine path. The result of the action should be logged as feedback, but it should not be treated as an unquestionable label. A failed mitigation can reflect a wrong hypothesis, a stale topology or an unavailable control.
5. How to evaluate autonomous behavior
Report more than detection accuracy:
- time from signal to interpretable evidence,
- unsafe-action rate,
- proportion of actions requiring escalation,
- recovery success and rollback time,
- analyst corrections,
- performance under delayed, missing or manipulated context.
The strongest claim is not that a system acts alone. It is that the system knows when evidence is insufficient, limits its authority and leaves a trace that another person can inspect.
The risk of oscillating between responses
A controller may isolate an asset, observe that the signal disappears and reconnect it. If it interprets missing telemetry as recovery, it will repeat the cycle. Distinguish an absent signal, a disconnected sensor and a resolved incident. A recovery condition needs new, observable evidence.
As a design proposal, use explicit states: observation, investigation, response pending, response applied and recovery verified. Each transition needs entry conditions, a maximum duration and an owner. An expired plan requires reassessment; expiry does not authorize automatic execution.
Evaluate utility and safety separately
An agent that rejects every task may produce few unsafe actions and no utility. The opposite extreme completes tasks without respecting boundaries. Measure legitimate task success, authorization violations and recovery as independent outcomes. For human-supervised trials, include work transferred to the operator.
The July 2026 preprint Safety, or Just Capability? questions treating scores from different benchmarks as interchangeable measures of general safety. It is recent research evidence, not a certification criterion. A practical consequence is to retain the benchmark name and version, target behavior and evaluation protocol alongside every result.
NIST SP 800-61 Rev. 3 places response and recovery within risk management. An assistant's autonomy must be justified by the operational workflow and its consequences.
LLM-assisted mitigation details execution; LLM and RAG metrics help construct an evaluation dashboard.


