In short: PYRHELIX is an offline dual-control release gate for sensitive BIO/PII artifacts. It does not replace perimeter security, compliance review, or clinical judgment. It closes one specific gap: no single actor, key, or approval should be able to move a high-consequence artifact across the release boundary alone.
By BIO/PII export, we mean high-consequence data bundles such as genomic files, clinical exports, research packets, identity-linked health records, and derived AI-ready datasets leaving a controlled environment.
The gap between what BIO/PII data is worth and how it's protected
The BIO and health-data economy is enormous, and it's getting more automated every year as AI pipelines touch more of it. The security incidents in this space are not rare, and they are not small.
- 23andMe (2023): attackers used credential stuffing, feeding passwords stolen from unrelated breaches into 23andMe's login page until roughly 14,000 accounts matched. Because of the platform's DNA-relative matching feature, that cascaded into exposure of genetic and ancestry data tied to an estimated 6.9 million users, including a disproportionate concentration of Ashkenazi Jewish and ethnically Chinese users who were then targeted with hateful, ancestry-specific harassment. (HIPAA Journal, Wikipedia)
- Change Healthcare / UnitedHealth (2024): a single server without multi-factor authentication was the entry point for a ransomware group. Change Healthcare clears roughly 1 in 3 U.S. patient records. The final confirmed count was 192.7 million people affected, the largest healthcare breach ever reported to HHS, disrupting billing and payment processing across thousands of hospitals and clinics nationwide. Response cost: $3.1 billion in 2024 alone. (BleepingComputer, Cybersecurity Dive)
- Vastaamo (Finland, 2020): a psychotherapy clinic stored ~36,000 patients' therapy notes unencrypted, on a system whose root account had no password. When extortion of the company failed, the attacker emailed roughly 30,000 patients directly, demanding ransom to avoid publishing their session notes. The clinic went bankrupt within months. (Wikipedia, CNN)
None of these three were release-boundary failures. They were perimeter and infrastructure failures: credential stuffing, a missing MFA setting, unencrypted storage with no root password. A signing protocol does not fix a server with no root password, and we are not going to claim otherwise.
What they show, together, is a pattern. BIO and health data carries some of the highest-consequence blast radius of any data category, and the organizations holding it are frequently operating below the security maturity that scale would justify. Compliance frameworks like HIPAA and GDPR mandate access logging and encryption at rest.
They say much less about what happens at the moment a sensitive artifact is about to leave a controlled environment. In practice, that moment is still often gated by one signature, one approval click, one export button.
That narrower gap, not "BIO security" broadly but specifically the release and export decision, is what we're building PYRHELIX to close. It is not a fix for this industry. It is one piece of it, and we want to find out if it actually holds up.
Why the release step specifically stays weak
A few structural reasons this keeps happening, independent of any one company's competence:
- Compliance is not the same discipline as security engineering. Passing a HIPAA audit checks access logs and encryption settings. It rarely asks whether one compromised or coerced person can push sensitive data out the door alone.
- Security engineering talent concentrates in tech and finance, not biotech. Research organizations hire for domain science, not for building dual-control release infrastructure in-house.
- Consolidation creates concentration risk. Change Healthcare touching a third of U.S. patient records through one platform is the extreme case. The same pattern, one vendor, one pipeline, one signer, repeats at smaller scale everywhere.
- Release is usually the last, least-engineered step in an otherwise carefully built research or clinical pipeline. By the time data is ready to ship, the hard technical work already happened, and the actual export is often just an email or a shared drive.
What PYRHELIX is
PYRHELIX enforces that a sensitive bundle cannot be released by one actor acting alone. The workflow has two independent steps.
- Producer (Strand A): the party that generated the artifact seals its content hash and attests to what was produced. This alone is not enough to release anything.
- Authority (Strand B): an independent reviewer, using a different signing key and a different role, attests approval. That attestation is cryptographically bound to the exact same bundle closure Strand A produced.
The release boundary only opens when both strands are present, use distinct keys, and bind to the same closure. Every step is recorded in a signed, hash-chained governance journal, so a separate offline verifier, potentially running on a machine that never touched the original data, can independently replay the whole decision trail: what was produced, who approved it, with which keys, in what order.
Worth getting right rather than sounding clever: a real DNA double helix does not have strands named "A" and "B." The correct terms are sense strand (coding strand) and antisense strand (template strand), and neither one alone is the functional, stable molecule; the helix only exists once both are bound together.
"Strand A" (producer) and "Strand B" (authority) are protocol role labels that borrow that single idea, not a claim to real molecular-biology nomenclature.
PYRHELIX's separate, internal bit-level integrity subsystem does use the correct sense/antisense terms for an unrelated purpose (parity diagnostics on hashed symbol streams). The governance mechanism described here is plain Ed25519 dual-signature binding over a shared closure hash.
Two pieces of the actual code
Real source, not simplified for effect.
Role separation can't be satisfied by accident. In strict mode, the verifier checks that Strand A and Strand B didn't reuse the same signing key, the same role, or the same underlying public key. Any one of those three silently fails the whole bundle:
# pyrhelix/governance/verifier_enforcement.py
if strand_a_key_id and strand_a_key_id == strand_b_key_id:
errors.append(error("KEY_ID_REUSE", "authenticity",
"Strand A and Strand B reused the same key_id in strict mode."))
attestation.strand_b_authenticity_verified = False
attestation.cross_strand_binding_verified = False
if strand_a_role and strand_a_role == strand_b_role:
errors.append(error("ROLE_REUSE", "authenticity",
"Strand A and Strand B reused the same role in strict mode."))
attestation.strand_b_authenticity_verified = False
attestation.cross_strand_binding_verified = False
There's no "trust me, these are different people" flag anywhere in this path. If the same key produced both attestations, the bundle fails.
Every journal entry is chained into the one before it, not just hashed on its own. The entry hash is computed over prev_entry_hash + canonical_bytes, so tampering with entry N breaks the hash of every entry after it, not just the one you touched:
# pyrhelix/governance/chronicle_io.py
canonical_bytes = canonical_chronicle_bytes(payload)
payload["entry_hash"] = sha256_hex_bytes(
(prev_entry_hash + canonical_bytes.decode("utf-8")).encode("utf-8")
)
payload["event_signature_b64"] = base64.b64encode(
signing_key.sign(canonical_bytes).signature
).decode("ascii")
Splice out or edit one line of the journal and every subsequent entry fails replay. That is exactly what the adversarial CI gate checks for (journal_tail_truncation, manifest_closure_tamper, and several others) on every commit.
Built on standards, not custom cryptography
For supply-chain security readers: PYRHELIX is not yet an in-toto or SLSA-compatible attestation format. That compatibility layer is the next evaluated integration path, not a claim we are making today.
What it actually rejects
An adversarial CI gate exercises these cases on every change, not just the happy path:
- Two strands signed with the same key or role
- A revoked or retired signing key reused for a new decision
- Journal tampering, sequence gaps, or tail truncation
- Replay of a superseded governance session
- Authority key rotation without a signed rotation event
- A bundle declaring "no raw payload" while raw sensitive content is actually present in the bundle directory
Running it offline
python tools/governance_ci_gate.py
It bootstraps local producer/authority keys, emits a provisional bundle (Strand A), finalizes it (Strand B), verifies the finalized bundle, and independently verifies the signed journal, all without a network call. It exits non-zero on any failure, which is also how it runs in CI on every commit.
The repository is currently private while we validate this against a real BIO/PII workflow before opening it more broadly.
What this is not
- Not a runtime AI firewall. Tools like LlamaFirewall or NeMo Guardrails intercept model calls in real time and inspect prompts or outputs as they happen. PYRHELIX operates downstream of that. It gates the moment content leaves the organization, after inference is already done.
- Not a fix for the kind of breaches described above. Those were perimeter and credential failures, not release-gate failures.
- Not a compliance scoring product. Tools that score content against frameworks like GDPR or HIPAA evaluate what's inside a bundle. PYRHELIX only verifies cryptographically that two independent signatures exist. It doesn't replace that evaluation. It gates release after it.
- Not yet interoperable with in-toto/SLSA attestation formats. We're sequencing that compatibility layer after real-world validation, not blocked on it technically.
- Not externally audited yet. Internal verification today means an automated test suite plus the adversarial CI gate above.
If BIO/PII export is part of your work, three questions:
- Is release approval today genuinely single-approver, or do you already run a dual-control process?
- Does verification need to work fully offline, or is a networked service acceptable?
- What would have to be true for you to say "this doesn't solve my problem"?
If any of these land for you, we'd like to run a real scenario together: Emails are not allowede
