Security
Security as the capacity to continue under failure: a capture-oriented adversary model, guardians kept inside the threat model, recovery tested in public — and an operational layer still largely unwritten.
A proposed doctrine derived from ratified cross-pillar commitments; a draft capture-resistance model and hostile-fork drill; no implementation and no executed drill. Technical threat modelling, incident response, cryptographic design, supply-chain security, disaster recovery and vulnerability disclosure remain unbuilt.
What must remain possible when systems fail, adversaries enter, and the people entrusted with defence become part of the danger?
What security must preserve
Security is usually drawn as a wall: threat outside, value inside, perimeter hardened between them. That picture is inadequate for the Protocol. Its proposed architecture is deliberately open — plural implementations, portable identity, public accounts, permissionless exit. It still contains components with boundaries and secrets; openness does not abolish access control. What it refuses is the idea that one perimeter, one operator or one institution can secure the whole.
There is a deeper problem with the wall. The captures this project was designed around often arrive with credentials. A firm buys the dominant client. A state coerces the only legal entity. A founder retains the keys long after the founding. Wealth accumulates governance weight through transactions the rules permit. Nothing has broken in, yet the people inside can no longer refuse the terms.
Availability is therefore too small an objective. An institution can remain online while its users lose agency; a particular instance can disappear while its community carries its identity, relationships and state into an independent successor. The first is a security failure by this project’s definitions. The second may be a security success.
The thing to preserve is the capacity to continue otherwise: the ability of people and communities to remain connected, recover what is theirs, reorganize, and act without permanent dependence on the component or guardian that failed them. Horizon supplies the contents of that continuity — survival, recovery capacity, distributed knowledge, institutional memory, plurality and future optionality. Security asks whether those things remain available under pressure.
The landing page calls this pillar the immune system of an open architecture. The metaphor is useful only under discipline. An immune system is not a police force, and even immunology has long challenged a simple equation between foreignness and danger — damage and context matter. In this pillar, people are never classified as foreign matter. The signals are changes in system condition: concentrated control, privileged action without authority, loss of exit, failing dependencies, violated boundaries. The response is directed at evidenced harm and the responsible capability, under due process. Otherwise the metaphor licenses exactly the pathology it was meant to prevent.
A capture model, not yet a security model
The first discipline is sound: threats before mechanisms. A defence chosen before its adversary and protected object are named is theatre.
RFC-0001, the Protocol’s draft infrastructure specification, names six capture strategies. The acquirer buys control. The incumbent joins an open protocol, dominates its use, then withdraws with the users. The state coerces through jurisdiction. The insider converts early legitimacy into permanent position. The plutocrat turns wealth into governance weight. The optimizer games the system’s own measures until they reward the opposite of their purpose.
The list’s distinctive choice is to look inward. Incumbents, insiders, plutocrats and optimizers participate in the system; the founder is named as the first insider risk. The draft also refuses to stop at protocol rules. It requires a public register of nine capture surfaces: physical infrastructure; code and maintainership; clients; identity and naming; data and state; funding; governance; legal wrappers; and external dependencies such as compute, models and standards bodies. Capture tends to settle in these adjacent layers because that is where nominal openness can coexist with practical control.
This is useful and narrow. It is a capture-oriented adversary model, not a complete security analysis. It does not model ordinary software compromise, stolen keys, malicious dependencies, denial of service, operator error, data corruption, fire, flood, or an accident with no adversary at all. It does not rank likelihood or impact. It has not been exercised against an implementation, because no implementation exists.
Established practice makes the boundary visible. The NIST Cybersecurity Framework 2.0 organizes a mature security lifecycle around six functions: govern, identify, protect, detect, respond and recover. RFC-0001 contributes distinctive ideas to governance, identification, structural detection and recovery. It supplies very little operational protection or response. That comparison does not make NIST the Protocol’s doctrine. It prevents a capture model from being advertised as a finished security posture.
From the material that does exist, this independent pass proposes three commitments. They are a candidate doctrine for review, not yet a ratified project position.
I. Defend the capacity to continue, not the permanence of an instance
No component should be able to hold the future hostage to its survival. That is the security meaning of the Architecture pillar’s plurality and exit commitments.
The draft specification translates the idea into several requirements. Communities must be able to leave with state, data, relationships and identity, and to fork without permission. At least two independently governed implementations must interoperate before a version is called stable. Concentration is capped through proposed floors for independent entities across each capture surface. Legal authority must be distributed across at least three uncorrelated jurisdictions, and the loss of any one must be survivable.
These numbers — two implementations, a 60 percent client-share trigger, four independent entities with seven as a target, three jurisdictions — are design proposals in an unreviewed draft, not natural constants or validated safety thresholds. Their purpose is clearer than their calibration: remove indispensable components; make losses local; preserve a route around whoever currently controls the main road.
This is resilience through plurality rather than invulnerability through fortification. NIST’s cyber-resilience guidance uses four verbs: anticipate, withstand, recover, adapt. The Protocol’s contribution is to add a political test to the technical one. Recovery is not complete merely because service returns. Did people recover their identity, relationships and standing? Can they still leave? Did the incident create a permanent controller? A system restored by removing its users’ alternatives has recovered its machinery and lost its purpose.
The commitment is strongest at Protocol-infrastructure scale, where the draft requirements apply. At participant scale, the project has one hard boundary — system legibility must not become ambient legibility of persons — but no developed human-security programme. At civilizational and existential scale, Horizon defines what must survive and what no survival measure may erase; Security has not designed the mechanisms. Keeping these scales separate is part of the honesty of the page.
II. Put every guardian inside the threat model
Every defensive capability is dual-use. Monitoring can become surveillance. Sanctions can discipline dissent instead of abuse. A recovery key can become a master key. An emergency office can preserve the system and preserve itself. A security team is an insider with unusually powerful tools and an unusually persuasive reason to be exempt.
So the guard receives no constitutional exception. Under the draft rules, every security role, mandate and key expires on a published schedule and is renewed only by fresh consent. Every exercise of privileged capability is logged. Sanctions are graduated, contestable and reviewable. Emergency powers must be defined before the emergency, limited in scope, public in exercise, subject to automatic sunset, and followed by review. Governance authorizes these powers; Security never authorizes itself.
This also corrects an easy misuse of transparency. Public design is a serious security tradition: Saltzer and Schroeder’s classic open-design principle says protection should not depend on secrecy of the design or implementation. RFC-0001 applies that instinct to structural capture: concentration, resource flows and privileged actions must be visible enough for outsiders to reproduce the account.
But public structure does not require immediate publication of an exploitable vulnerability before anyone can repair it. Coordinated vulnerability disclosure exists precisely to combine remediation with eventual public disclosure. The Protocol has no policy for that timing, no protected reporting channel, and no rule preventing a remediation window from becoming indefinite secrecy. Those remain open decisions. What is already clear is the boundary: the existence and use of security power cannot be secret, even when a technical detail is temporarily withheld.
The same precision applies to surveillance. Horizon’s ratified position permits standing monitoring of dangerous systems — fissile material, pathogen synthesis, concentrated compute — when the authority is publicly justified, contestable, transparent in exercise and subject to expiry or genuine renewal. It continues to refuse ambient surveillance of persons as a standing condition of life; person-level attribution requires bounded due process. Security inherits that line. A threat does not become less real because monitoring is constrained, and monitoring does not become legitimate merely because the threat is real.
The rule is simple to state and hard to institutionalize: the defender remains governed while defending.
III. Recovery is credible only when rehearsed
A right of exit that has never been exercised may conceal missing exports, undocumented dependencies, names that do not travel, keys held by the incumbent, or a social graph whose portability exists only in prose. Recovery plans fail quietly until the day they are asked to work loudly.
RFC-0001 therefore proposes an annual hostile-fork drill. A community must stand up an independent instance using only capabilities available to everyone, carrying its code, state, ledger, identities and relationships without incumbent permission, while one legal jurisdiction is treated as unavailable. Time, labour, infrastructure cost, losses and deviations are published. This project has drafted the exercise as DRILL-0001. It has never executed it; there is no implementation to fork.
The drill document is honest about what it cannot decide. RFC-0001 requires exit-cost thresholds but supplies no numbers, so a first run could measure cost without declaring success. It does not say who convenes the drill, who attests the result, whether a failed drill must be repeated, or how a scheduled rehearsal represents an incumbent actively trying to obstruct departure. Those are not footnotes. They determine whether the exercise tests independence or stages it.
Rehearsal itself is not an eccentric project invention. NIST contingency guidance treats tests and exercises as part of maintaining recovery capability. The Protocol’s sharper proposal is what gets rehearsed: not only restoration by the incumbent, but departure from it. Conventional disaster recovery asks whether the organization can resume. A hostile-fork drill asks whether the governed can continue if the organization is the failure.
That distinction is the pillar’s best chance to produce evidence. The numerical thresholds may be wrong. The drill design may fail review. An attempted fork may expose costs so high that the architectural promise collapses. All three outcomes would teach more than another declaration of resilience.
The loop
The three commitments need one another. Continuity without governed guardians can become protected captivity: the system survives because nobody is allowed to leave it. Governed guardians without practiced recovery can remain impeccably legitimate while failing at the moment of loss. Rehearsal without a clear object of protection can restore the institution while discarding identity, relationships, plurality or agency.
In compressed form: preserve the capacity to continue; keep the defender governed; rehearse the recovery. This is the proposed Security doctrine. It awaits comparison, criticism and owner ratification.
What the draft already specifies
At Protocol scope, the nine requirements form a partial defensive structure.
Map and detect. Publish the capture-surface register. Monitor client share and concentration. Record resource flows and privileged actions so an outside party can recompute the structural account. The open problems are serious: metrics can be gamed, and nominally independent entities may share investors, cloud infrastructure or jurisdiction.
Constrain response. Use monitored boundaries, graduated sanctions and cheap dispute resolution for participant violations. Use only pre-authorized, public and expiring powers for emergencies. These are institutional controls, not packet-level incident response.
Make loss survivable. Preserve permissionless exit, implementation plurality, distributed control and jurisdictional redundancy. Apply power demurrage after an incident: whatever authority the crisis concentrated expires. A crisis is not a title deed.
Test the promises. Run the hostile-fork and jurisdiction-loss drill and publish the result. None of this is practiced today. The specification is draft v0.1, the drill is draft v0.1, and the infrastructure they describe does not exist.
The operational layer is still missing
The gap is larger than the earlier phrase “incomplete operational layer” suggests. The project has no technical threat model and no asset/risk assessment beyond capture surfaces. It has no incident-response roles, severity model, triage, containment, eradication, recovery coordination, communications plan or post-incident learning process. Current NIST incident-response guidance exists; the Protocol has not evaluated or adapted it.
There is no cryptographic architecture, key-management or recovery scheme, release-signing design, secure build process, dependency policy, software bill of materials, hardware-supply-chain position, backup doctrine, recovery-time or recovery-point objective, vulnerability-disclosure policy, protected researcher channel, Sybil-resistance design, or method for distinguishing a dangerous anomaly from noise. The RFC names several of these as surfaces. Naming a surface is not securing it.
Nor does this pillar contain a biosecurity, nuclear-security or advanced-AI-security programme. Horizon makes catastrophic-risk reduction a priority and constrains how it may be pursued. The Diagnosis establishes urgency. Neither supplies Security with an operational mechanism, and this page will not fabricate one.
These omissions do not make the existing work worthless. They determine its maturity. The Protocol currently has a distinctive theory of structural capture, a set of proposed institutional controls, and one unexecuted recovery exercise. It does not yet have a security programme.
What this pillar claims, and does not
It claims that continuity of agency is a better protected object than institutional uptime; that defenders must remain subject to the rules they enforce; that structural concentration and privileged action should be publicly auditable; and that recovery claims should be tested through exercises capable of disproving them.
It does not claim that RFC-0001 is validated, that its numerical thresholds are correct, that openness is always safer, that public evidence eliminates the need for temporary confidentiality, that DRILL-0001 is unprecedented, that any implementation conforms, or that catastrophic risk yields to protocol design. It promises no invulnerability. Some attacks will succeed; some losses will be permanent; some exercises will reveal that the proposed architecture cannot yet recover.
The first work
The first useful step is not another principle. Security engineers and community operators should review DRILL-0001 against the hostile conditions it claims to simulate, then turn it into an executable acceptance test alongside the first prototype. Its missing thresholds, authority and attestation must go through the RFC process rather than being improvised by whoever runs it.
In parallel, the project needs two deliberately ordinary documents: an incident-response plan and a vulnerability-disclosure policy. They will reveal the actual interface between publicity, temporary confidentiality, authority and speed. Cryptographers, supply-chain specialists, identity researchers, disaster-recovery practitioners and red teams have entire missing chapters to write after that.
The standard for contribution is the same as the standard for security: name the thing protected, the failure considered, the power your answer creates, and the evidence that could prove you wrong. The immune system is not installed. It is learning what it would have to become.