AUTONOMOUS DEFENCE FOR BLOCKCHAIN VALIDATORS
Earn autonomy before you exercise it.
Validators face downtime, slashing, and exploitable services their teams don't know exist. The failure is not capability - it's the gap between detection and legitimate action when seconds matter.
Biological immune systems don't ask permission to act - they earn the right through evolutionary rehearsal. Digital infrastructure needs an equivalent.
Shadow-mode deploys in observation only. No enforcement, no risk.
From our scanning research
40% of validators have exploitable services their teams don't know exist.
Based on external enumeration across major proof-of-stake networks. No credentials, no agents - just what an attacker sees from the outside.
The Asymmetry
Autonomous defence already exists. The unsolved problem is legitimacy under adversarial latency.
Reconnaissance, exploitation, and lateral movement operate at millisecond-to-minute timescales.
Review chains, escalation paths, and approval workflows operate at minute-to-hour timescales.
Pre-authorised playbooks work only for threats that have already been classified.
This is a governance gap, not a tooling gap. The question is not whether machines can act fast enough - it's whether they have the legitimacy to act at all.
Published Research
On Earned Autonomy: Delegating Network-Lethal Authority to Machines
Simon Morley, January 2026
The paper argues that the central barrier to autonomous defence is a governance gap, not a capability gap. It introduces earned autonomy as a framework for closing it - machines prove judgment in observation before they are granted authority to act.
Read the paperEarned Autonomy
The solution is not faster automation. It's a framework where autonomy is earned through evidence, granted by humans, and continuously validated.
Bounded authority
Autonomy is granted per abuse class, not as a blanket permission.
Rehearsal on live traffic
Shadow mode runs on real traffic without enforcement. No risk.
Counterfactual record
Every judgment is logged: what would have been blocked, and why.
Explicit human review
Operators review the evidence. This is the legitimising act.
Threshold-based grant
Authority is granted only when evidence meets operator-defined thresholds.
Continuous validation
Granted authority is continuously verified against live outcomes.
Reversibility
All enforcement is auditable and revocable. Nothing is permanent.
Human review is the legitimising act - not a checkbox. The system does not assume trust. It earns it.
IBSR & Guard - The Paired System
Two distinct roles. IBSR produces judgment. Guard executes enforcement. Neither operates alone.
IBSR - Judgment
- •Observes live traffic patterns and learns behavioural baselines.
- •Produces counterfactual records: what would have been blocked, and why.
- •Runs in shadow mode on real traffic without any enforcement risk.
- •Provides evidence for operator review and threshold definition.
IBSR never enforces.
Guard - Execution
- •Kernel-level enforcement via XDP/eBPF at wire speed.
- •Acts only on judgments that have been explicitly authorised by operators.
- •Enforcement is scoped, reversible, and continuously monitored.
- •Fail-open architecture ensures uptime is never compromised.
Guard never decides.
IBSR does not act. Guard does not decide.
IBSR without Guard is incomplete. Guard without IBSR is reckless.
What This Looks Like
Scenario: Zero-day before disclosure
Illustrative reconstruction based on the Heartbleed vulnerability (CVE-2014-0160). Not empirical.
Setup
April 2014. Your OpenSSL cluster is live. No patch exists. No signature exists. The vulnerability has been in the wild for two years.
Detection
IBSR observes anomalous TLS heartbeat requests - tiny payloads triggering 64KB responses. No signature match. Behavioural anomaly only.
Judgment
91.3% confidence this constitutes data exfiltration. IBSR recommends blocking the anomalous heartbeat pattern.
Action
Guard checks its authority scope. Heartbeat anomaly blocking is within granted bounds. Block engages. Exfiltration stops.
Resolution
Three weeks later, Heartbleed (CVE-2014-0160) is publicly disclosed. The attack was already stopped.
The Operator Path
A serious operational process. Not a sales funnel.
Discuss shadow-mode deployment
Scope and constraints are reviewed together. No enforcement, no risk. Deployment follows operator sign-off.
IBSR produces a counterfactual record
Evidence for a specific, bounded abuse class. You see exactly what would have been blocked, and why.
Operator reviews, defines thresholds, grants authority
This is the legitimising step. Authority is explicitly granted - not assumed. You define the boundaries.
Enable Guard
Enforcement is scoped, reversible, and continuously validated. Guard acts only on what you have authorised.
Authority is granted, not assumed. If the evidence doesn't support action, Guard stays dormant. The system waits for legitimacy.
The Uncomfortable Inversion
At some point, the evidence will show that not acting causes more harm than acting.
The counterfactual record makes this trade-off explicit. It allows operators to justify enforcement before the system is granted authority to act. You see the cost of inaction in hard numbers.
This is uncomfortable - and necessary.
This differentiates earned autonomy from "trust us" vendors. We don't ask for faith. We provide evidence, and you decide when the evidence is sufficient.
Where This Breaks
Adversarial drift
Attackers adapt to detection. Any behavioural model creates selection pressure for adversaries to evolve. IBSR retrains continuously against live traffic and injects synthetic adversarial patterns to stress-test its own baselines.
Baseline poisoning
If an attacker is already present during the learning phase, the baseline itself is compromised. IBSR treats initial observation periods as untrusted and cross-validates against known-good traffic patterns.
Cascading failure
A wrong judgment at kernel speed is a self-inflicted outage. Guard enforces rate limits on its own actions and requires escalating confidence thresholds for increasingly disruptive responses.
Scope creep
Pressure to extend authority beyond what the evidence supports. Every grant of authority is bounded, versioned, and auditable. Expansion requires a new evidence cycle.
The question is not whether the system will sometimes be wrong. It will. The question is whether it will be wrong less often, and less catastrophically, than the alternative.
Who's Building This
Simon Morley, Founder
- >20+ years offensive security and infrastructure engineering
- >Background adjacent to UK government cyber operations
- >Published researcher (DOI)
Start with evidence
Deploy IBSR in shadow mode. No enforcement, no risk. Review the counterfactual record. When the evidence supports action, grant authority to Guard.
What you get:
- >IBSR running on live traffic in observation mode
- >Counterfactual records showing what would have been blocked
- >Guard ready to activate when you grant authority
- >Direct access to engineering during deployment
What happens next
- 1You email us. We scope the deployment together.
- 2IBSR deploys in shadow mode. Observation only, no enforcement. Typically 2-4 weeks.
- 3You review the counterfactual record.
- 4You decide. Grant authority for specific, bounded abuse classes.
For operators running validator infrastructure at institutional scale. If you're responsible for nodes processing staked value and need to move faster than your current incident response allows.