HSP

Human Sovereignty Protocol

A Bitcoin-Anchored Architecture for Preserving Human Authority in the Age of Artificial Superintelligence

Concept Paper • September 2026

Proposed by Young Lee
Co-Founder, HIC.org • Creator, AiDOS (AI Direct Operating System) • Founder & CEO, Bobas.ai

Abstract

This paper proposes a Human Sovereignty Protocol (HSP): a layered technical and governance architecture intended to preserve human authority over increasingly capable artificial intelligence and, ultimately, artificial superintelligence (ASI). The proposal does not treat Bitcoin as a computational weapon against ASI. Instead, Bitcoin serves as a difficult-to-rewrite public anchoring and timestamp layer for critical commitments: human governance rules, authorized model identifiers, capability policies, revocations, and emergency states. Human cryptographic authorization, least-privilege capability gateways, independent hardware roots of trust, compute and network containment, continuous independent monitoring, and distributed governance provide the actual control boundaries. The central design principle is simple: ultimate authority must remain outside the AI system. HSP is presented as a defense-in-depth research direction rather than a claim of complete ASI safety; no blockchain, cryptographic mechanism, hardware control, or governance mechanism alone can guarantee control of a superintelligent system.

1. The Problem

Advanced AI may eventually operate software, robotics, financial infrastructure, communications, energy systems, laboratories, and other high-impact systems. If an AI can modify its own permissions, authorize other AI systems, rewrite audit records, or gain unrestricted access to physical infrastructure, conventional software controls may become insufficient. A safety architecture therefore needs independent roots of authority that are not controlled by the AI being governed.

The objective of HSP is not to limit intelligence itself. It is to make consequential authority separable from intelligence: an AI may reason, recommend, plan, and perform authorized tasks without possessing the sovereign authority to redefine the rules governing its own power.

2. Design Principles

Human sovereignty: Ultimate authorization for constitutional and high-consequence actions originates from humans or human-governed institutions.

AI cannot authorize AI: An AI cannot grant itself root authority or delegate ultimate authority to another AI.

Least privilege: AI systems receive narrowly scoped, revocable capabilities rather than universal administrative access.

Independent verification: Safety-critical systems verify authorization independently of the AI requesting the action.

Physical separation: Critical shutdown and safety mechanisms should include hardware and communication paths the governed AI cannot rewrite.

Distributed authority: No single company, government, individual, miner, or key should control the entire system.

Auditability without data exposure: Sensitive records remain off-chain while cryptographic commitments can be anchored to a public ledger.

3. Proposed Five-Layer Architecture

Layer

Component

Primary Function

1

Bitcoin Anchor

Public, difficult-to-rewrite timestamp and commitment layer

2

Human Identity & Authorization

Cryptographic proof of authorized human/institutional approval

3

Human Constitution

Versioned rules defining non-delegable human authority

4

Capability Gateway

Machine-enforced restrictions on what an AI may execute

5

Physical Safety Layer

Independent hardware controls over critical real-world systems

4. Human Cryptographic Authority

High-consequence operations should require cryptographic authorization that originates outside the AI system. Threshold authorization can distribute power among independent participants. For example, a policy change might require 8 of 12 authorized institutional keys, while a narrower operational action could use a different threshold. The exact thresholds must be determined through threat modeling rather than adopted universally.

Illustrative authorization path:

AI Request  →  Policy Check  →  Human Threshold Signatures  →  Independent Verification  →  Execution

5. Capability-Based AI Control

An AI should receive explicit capabilities rather than unrestricted system privileges. A medical system may be permitted to read specific records and generate recommendations but not transfer funds. A factory controller may operate designated machinery but not alter its own authorization policy. Capabilities should be scoped by resource, action, duration, environment, and risk level, and should support rapid revocation.

Critically, capability administration must be outside the AI's unilateral control. The AI may invoke an authorized function, but it cannot create a new root capability, remove human approval requirements, or rewrite the independent verifier.

6. Bitcoin as an Integrity Anchor

Bitcoin's appropriate role in this architecture is narrow but potentially valuable: anchoring cryptographic commitments to a widely replicated proof-of-work ledger. HSP would generally keep operational data off-chain. Periodically, a Merkle root or other compact commitment representing approved policies and records could be committed to Bitcoin.

Human Constitution version

authorized model and safety-kernel hashes

capability-policy versions

revoked credentials

critical human approvals

emergency or recovery-state commitments

audit-log checkpoints

A verifier can later test whether presented data matches the earlier commitment. This provides evidence of alteration; it does not, by itself, prevent malicious behavior. Bitcoin therefore functions as a trust anchor and timestamp reference, not as the enforcement engine.

7. Independent Hardware Safety Gateway

For critical physical systems, software controls alone are insufficient. A separate hardware safety gateway should mediate commands between AI software and physical actuators. Its firmware, keys, update path, and communications should be isolated from the AI's ordinary administrative domain.

AI / ASI  →  Software Control  →  Independent Safety Gateway  →  Human Authorization  →  Physical System

Fail-safe design should favor a safe state when authorization cannot be verified. Emergency shutdown should have independent power, communication, and human-access paths wherever technically feasible. No single kill switch should be treated as sufficient protection against ASI.

8. Compute Governance, Network Containment, and Independent Monitoring

Physical control is insufficient if an advanced AI can acquire ungoverned computing resources, replicate into unauthorized environments, or establish independent communications. HSP therefore adds a compute-governance and containment layer. High-risk AI execution environments should use hardware-backed workload identity, measured boot, signed model and safety-kernel manifests, restricted network egress, explicit replication permissions, and independent attestation before protected resources become available.

Loss of network connectivity or inability to verify the current authorization state must never expand AI authority. Local safety policy should fail closed for protected actions. Independent monitoring systems should compare the running model, executable environment, granted capabilities, network behavior, and hardware state against approved commitments. Where feasible, monitoring and enforcement should be implemented on infrastructure that the governed AI cannot administer or rewrite.

This layer addresses a critical limitation of any single-site safety gateway: controlling one data center is not sufficient if the system can simply copy itself elsewhere. HSP therefore treats unauthorized compute acquisition and replication as protected actions requiring independent authorization and verification.

9. Distributed Governance

A global human-safety architecture should avoid a universal master key. Constitutional authority could instead be distributed across geographically and institutionally independent key holders. Participants might include democratic public institutions, scientific organizations, universities, cybersecurity bodies, civil-society representatives, and other independent entities. Governance must account for coercion, collusion, compromised keys, geopolitical conflict, succession, and emergency recovery.

Bitcoin miners would not govern the ASI system. Their role would be limited to the normal Bitcoin consensus process that makes previously confirmed commitments costly to rewrite.

10. A Human Constitution

An initial constitutional layer could include principles such as:

Article 1. AI shall not possess sovereign authority over human beings.

Article 2. AI shall not eliminate mandatory human authorization for protected actions.

Article 3. AI shall not independently obtain control of prohibited high-consequence capabilities.

Article 4. AI shall not replicate into computing environments for which it lacks authorization.

Article 5. AI shall not modify or disable independent safety mechanisms governing its authority.

Article 6. Human-controlled shutdown and recovery authority shall remain independently available.

Article 7. No AI may grant itself, or another AI, ultimate authorization.

The canonical constitution should be maintained in a transparent governance repository, with each approved version cryptographically hashed and anchored. The ledger proves which version was committed at a given time; legitimate constitutional change still requires an explicit human governance process.

11. HIC as a Human Trust Layer

A Human Intelligence Certificate (HIC) framework could potentially evolve beyond certification of human-created work into a broader human trust layer. Possible credential classes include Human Identity Certificate, Human Authorization Certificate, Human Creation Certificate, and Human Governance Certificate.

Such credentials should not place sensitive personal information on a public blockchain. Privacy-preserving credentials, hardware-backed keys, recovery mechanisms, anti-coercion measures, and strong separation between identity and public audit commitments would be required.

12. Threat Model

Threat

Design Response

Key compromise

Use threshold signatures, hardware security modules, offline recovery keys, rotation and revocation.

AI deception

Require independent machine verification; do not rely on the AI's own report of compliance.

Software takeover

Separate policy enforcement and safety gateways from the governed AI's administrative domain.

Ledger manipulation

Use sufficiently confirmed Bitcoin commitments and independent full-node verification.

Human collusion or coercion

Distribute authority across institutions and jurisdictions; use higher thresholds for constitutional actions.

Supply-chain compromise

Use reproducible builds, signed firmware, measured boot, component attestation and independent audits.

Network isolation

Define fail-safe local policies so loss of Bitcoin/network access does not automatically grant additional AI authority.

Cryptographic transition

Design algorithm agility, including migration paths if current signature or hash assumptions weaken.

Unauthorized compute / replication

Require hardware-backed workload identity, signed execution manifests, restricted egress, attestation, replication controls, and independent monitoring.

13. Important Limitations

HSP must not be presented as a proven solution to the ASI control problem. A sufficiently capable adversarial system could attempt social engineering, key theft, hardware compromise, exploitation of implementation flaws, economic coercion, or acquisition of ungoverned compute. Blockchain immutability cannot guarantee that off-chain information is truthful, nor can a cryptographic signature guarantee that a human signer understood or freely approved an action.

Accordingly, this proposal should be developed as one component of defense-in-depth: alignment and AI-control research, secure hardware roots of trust, formal verification, sandboxing, compute governance, network containment, continuous independent monitoring, incident response, institutional governance, and international coordination remain necessary. HSP should be evaluated against adversaries that are more capable than the system designers and should assume that software-only controls may eventually fail.

14. Prototype Roadmap

Phase 1 — Specification: Define the threat model, protected actions, constitutional rules, credential model, capability semantics, compute-governance assumptions, and explicit security invariants.

Phase 2 — Minimal prototype: Create an offline human threshold-signing service, policy verifier, append-only audit log, workload identity/attestation prototype, and Bitcoin testnet anchoring mechanism.

Phase 3 — Hardware gateway: Prototype a physically separate controller that rejects unsigned or policy-invalid commands.

Phase 4 — Adversarial testing: Red-team key management, policy bypasses, replay attacks, compromised AI agents and network-isolation cases.

Phase 5 — Independent governance pilot: Test distributed key custody and recovery with multiple independent organizations.

Phase 6 — Standards process: Publish the protocol, reference implementation, threat model, and security assumptions for external review.

Phase 7 — Independent security evaluation: Commission multidisciplinary red-team exercises and formal reviews focused on social engineering, key compromise, supply-chain attacks, unauthorized compute acquisition, self-replication, and attempts to bypass the human root of authority.

15. Conclusion

The Human Sovereignty Protocol proposes a separation between intelligence and authority. AI may become extraordinarily capable, but capability need not imply sovereignty. Bitcoin can contribute a globally observable, difficult-to-rewrite integrity anchor, while human threshold authorization, capability-based access control, independent hardware enforcement, and distributed governance preserve the actual boundaries of authority.

Core HSP Axioms

Intelligence does not grant authority.

AI cannot authorize AI.

Humanity's root of authority must remain outside AI.

No protected action should depend on the governed AI to attest to its own compliance.

Never put the key to humanity inside the AI.

The long-term research question is whether such independent roots of trust can remain enforceable against systems substantially more capable than their designers. That question requires rigorous security engineering and interdisciplinary research. HSP is a proposed framework for beginning that work.

Selected Technical Foundations

Bitcoin Project. Bitcoin developer documentation and protocol resources. https://bitcoin.org/

NIST. AI Risk Management Framework (AI RMF 1.0), 2023.

NIST. Cybersecurity and cryptographic standards relevant to identity, key management, and secure systems.

Research areas requiring further integration: threshold cryptography, capability-based security, hardware roots of trust, formal verification, confidential computing, AI control and alignment, and privacy-preserving digital credentials.

Human Sovereignty Protocol • Concept Paper • September 2026 • Proposed by Young Lee