On Earned Autonomy: When Should Machines Defend Networks Without Asking?
Machines attack at machine speed. Humans defend at human speed. This asymmetry is structural, and it's widening.
The full paper is pending publication. We'll link it here once it's live.
The Problem
The components for autonomous network defence exist. Kernel-level packet processing via XDP and eBPF can act in microseconds. Machine learning can classify threats. Behavioural analysis can detect anomalies. Cloud providers like Cloudflare already run autonomous DDoS mitigation at scale.
But outside nation states and big tech? Almost nobody deploys autonomous defence against novel threats. The technology exists. The governance doesn't.
And for good reason. Autonomous systems that can block traffic can also block legitimate traffic. A false positive isn't an alert to triage later--it's an outage. At kernel speed, across an entire network, mistakes compound fast.
So operators keep humans in the loop. They accept the latency cost. They hope the attacks they face are slow enough to catch.
For known threats with signatures and playbooks, this works. For zero-days, behavioural anomalies, and novel abuse patterns? The attack completes before the approval chain engages.
Earned Autonomy
The paper proposes a framework we call earned autonomy: authority granted to machines not by vendor assertion or static policy, but by demonstrated competence on real traffic in the actual environment.
The core idea is simple: before a system is permitted to act, it must prove--through rehearsal on live traffic--that its judgment can be trusted. Not in a lab. Not on synthetic data. On the network it will defend.
Seven components:
- Bounded Scope - Authority per abuse class, not blanket permission
- Rehearsal on Reality - Shadow mode on live traffic before enforcement
- Counterfactual Record - Log what would have happened
- Human Review - Evaluate the record, not every decision
- Explicit Threshold - No enforcement without meeting defined accuracy
- Continuous Validation - Authority revoked if performance degrades
- Reversibility and Audit - Every action logged and explained
This isn't trust by assertion. It's trust by evidence.
IBSR and Guard
We've built a reference implementation. IBSR (Inline Block Simulation Report) learns behavioural patterns at microsecond resolution and produces judgment--what should be blocked and why. Guard executes blocking at kernel level via XDP.
The separation matters. IBSR can run indefinitely without Guard, building evidence, producing counterfactual records, letting humans evaluate its judgment. Only when IBSR demonstrates competence does Guard receive permission to act.
Here's the thing that makes us most confident in this approach: IBSR already refuses to grant itself authority.
In live testing, IBSR detected a clear SYN flood--2,400+ SYN packets per second from a single source against port 80. It calculated the counterfactual: blocking would have dropped 89% of the attack traffic. But its readiness judgment?
"This abuse class IS NOT safe for autonomous enforcement."
Why? The false positive bound was 100%, exceeding the 5% threshold. The system correctly identified that it hadn't yet built enough confidence to distinguish this pattern from legitimate traffic in this environment.
The machine said "don't trust me yet." That's earned autonomy working as designed.
The Uncomfortable Inversion
The paper addresses something we don't talk about enough: at some point, keeping humans in the loop stops being a safeguard and starts being a guarantee of harm.
If the counterfactual record shows that autonomous action would have stopped attacks that human-gated response missed—consistently, measurably—then withholding authority has a cost. That cost is the attacks that succeeded while waiting for approval.
This doesn't mean autonomous action is always correct. It means there exists a class of threats, in certain environments, where evidence will show that machines outperform human-gated response. For that class, the burden of proof inverts.
Read the Paper
The full paper covers:
- The latency threshold and zero-day window
- Why responsible operators currently block autonomous defence
- The seven-component framework in detail
- A worked vignette: Heartbleed detection before disclosure
- Failure modes and adversarial considerations
- The long arc: what happens when offence also learns
Paper pending publication. Link coming soon.
What's Next
Earned autonomy is the governance framework. IBSR and Guard are the implementation. We're continuing development as part of our work on inline network security--building systems that can act at machine speed while remaining accountable to human governance.
If you're working on similar problems, or if you're an operator wrestling with the question of when to let machines act, we'd like to hear from you.
This research is part of NullRabbit's work on high-performance network security.
Related Posts
Validating Inline Enforcement with XDP: IBSR and the Path to Earned Autonomy
Inline enforcement operates at machine speed, but trust cannot. IBSR is a validation step: using XDP to observe real traffic, simulate enforcement, and generate evidence before any blocking is enabled.
Earned Autonomy: A Governance Framework for Autonomous Network Defence
Autonomous mitigations already act at machine speed - but we still have no legitimate framework for granting them authority over novel threats.
Earned Autonomy: The Paper
Machines attack at machine speed. Humans defend at human speed. The technology to close this gap exists - the governance doesn't. A framework for when machines should be permitted to act without human approval.
