AegisBlock: Privacy-Preserving Medical Blockchain

• AegisBlock is a patient-centric, permissioned blockchain framework that preserves patient anonymity while enabling time-based queries for medical research.
• It employs zero-knowledge proofs, per-block keys, and chained hashes to ensure data integrity and verifiable, HIPAA-compliant data disclosure.
• While the term appears in broader security contexts, its formal instantiation uniquely balances privacy and controlled, retrospective access to health records.

Searching arXiv for papers relevant to “AegisBlock” and closely related “AEGIS/Aegis” usages.

AegisBlock is a patient-centric, permissioned blockchain framework for privacy-preserving medical research that enables researchers to request time-based range queries over personal health records while preserving patient anonymity and maintaining the trustworthiness of the data they receive (Garg et al., 15 Aug 2025). In the literature, the exact term also appears as a conceptual extrapolation in several “Aegis” systems rather than as a formally defined primitive: in those cases, “AegisBlock” is used informally to denote a modular security, enforcement, or provenance unit within broader architectures for autonomous agents, LLM security, blockchain protection, or copyright management (Adapala et al., 22 Aug 2025, Cai et al., 29 Apr 2025, Yuan et al., 13 Mar 2026, Jiang et al., 2024). The most explicit and formal instantiation, however, is the medical research framework introduced in "AegisBlock: A Privacy-Preserving Medical Research Framework using Blockchain" (Garg et al., 15 Aug 2025).

1. Definition and Scope

In its formal usage, AegisBlock is a framework for sharing medical records with researchers such that the anonymity of the patient is maintained while ensuring the trustworthiness of the data provided to researchers (Garg et al., 15 Aug 2025). Its problem setting is shaped by HIPAA and related privacy constraints: protected health information must be disclosed only with proper authorization, while researchers still require longitudinal datasets for cohort studies and other retrospective analyses. The framework therefore combines patient-controlled authorization, blockchain-backed immutability, off-chain encrypted storage, and cryptographic verification.

The central interaction model is patient-centric rather than institution-centric. Patients, hospitals, and researchers are authenticated through a trusted third party, and hospitals act as miners in a permissioned blockchain. A researcher does not directly retrieve plaintext records from the chain; instead, the researcher submits a time-based range query tied to a patient block, and access is granted only upon patient approval (Garg et al., 15 Aug 2025). This design is intended to shorten study timelines by allowing retrospective access to already recorded personal health records, while retaining explicit patient control over the scope of disclosure.

Outside the medical setting, the term is not standardized. "The Aegis Protocol: A Foundational Security Framework for Autonomous AI Agents" states that “AegisBlock” is not an explicitly defined term, but suggests a natural architectural interpretation of an “Aegis block” as a reusable component corresponding to one of the protocol’s security pillars—identity, communication, or policy verification (Adapala et al., 22 Aug 2025). "AegisLLM: Scaling Agentic Systems for Self-Reflective Defense in LLM Security" similarly does not define the term formally, but uses it conceptually as a modular runtime defense block composed of orchestrator, responder, evaluator, and deflector agents (Cai et al., 29 Apr 2025). A plausible implication is that “AegisBlock” functions as a family resemblance term across several domains, but only the medical research framework gives it a direct, paper-level title and system identity (Garg et al., 15 Aug 2025).

2. System Model in the Medical Research Framework

AegisBlock operates as a private, permissioned blockchain populated by three primary participant classes—patients, hospitals, and researchers—plus a trusted third party responsible for off-chain identity verification (Garg et al., 15 Aug 2025). Patients are the owners of personal health records; hospitals act both as healthcare providers and as miners; researchers search for relevant patient records by public condition codes and then request access to specific temporal ranges. The trusted third party ensures that every patient, hospital, and researcher registered to the system is legitimate.

The framework is organized around two phases. In Phase I, a patient and hospital jointly create a new personal health record block for a visit or episode. The block header contains zero-knowledge proofs and signatures showing that the patient and hospital are valid users in the registry without revealing which registered identities they are, and that both parties co-signed the block (Garg et al., 15 Aug 2025). The block body contains public condition codes and a hash construction that links the block to prior blocks and to off-chain encrypted data. After miner validation, the block is appended to the chain once at least 50% of miners approve it.

In Phase II, the researcher performs access acquisition by forking a patient block. The researcher first identifies relevant patients through public condition codes, then creates a researcher request block containing a pointer to the patient block, a requested time range, and the researcher’s signature and identity key. Miners validate that request block. The patient then decides whether to approve the query as requested, narrow the requested time range, or deny access. If approved, the patient creates an authorization block and sends the researcher the off-chain encrypted data and associated verification material needed to recompute the linked hashes and validate integrity against the blockchain record (Garg et al., 15 Aug 2025).

This architecture is explicitly designed so that the blockchain does not function as a plaintext data repository. Instead, it acts as a coordination and verification layer: public condition codes support cohort discovery, while the actual medical content remains encrypted off-chain under patient-controlled symmetric keys. This separation is central to the framework’s privacy claim.

3. Cryptographic Construction and Privacy Mechanisms

AegisBlock’s anonymity model relies on per-block key material, zero-knowledge proofs, and chained hashes that bind off-chain data to on-chain state (Garg et al., 15 Aug 2025). For each block $b$, the patient and hospital generate new public keys $(x^b_p, y^b_p)$ and $(x^b_h, y^b_h)$, respectively. This per-block keying is intended to prevent straightforward linkage of multiple blocks to a single identity by public-key reuse.

The zero-knowledge layer uses non-interactive Schnorr-style proofs made non-interactive via the Fiat–Shamir heuristic. The patient submits a proof of the form

$$\text{ZK\_AND}(\text{ZK\_OR}(p_1,\dots,p_m), y^b_p),$$

and the hospital submits an analogous proof

$$\text{ZK\_AND}(\text{ZK\_OR}(h_1,\dots,h_n), y^b_h).$$

The semantics are specific: the $\text{ZK\_OR}$ component proves knowledge of a private key corresponding to one of the valid registered identities without revealing which one, and the conjunction with the fresh block-specific public key proves that the new block key belongs to a legitimate registered participant (Garg et al., 15 Aug 2025). This lets miners verify legitimacy without de-anonymizing the patient or hospital.

The integrity mechanism is a continuous hashing scheme over off-chain encrypted data and prior block state. For block $b$,

$$H(\hat{b}) = H\big(s^b_p \,\|\, Ptr(D_b) \,\|\, H(D_b) \,\|\, H(\hat{b-1})\big),$$

where $s^b_p$ is the patient’s symmetric key for block $b$, $(x^b_p, y^b_p)$0 is the pointer to encrypted off-chain data, $(x^b_p, y^b_p)$1 is the hash of that encrypted data, and $(x^b_p, y^b_p)$2 is the chained hash from the preceding patient block (Garg et al., 15 Aug 2025). The chain stores

$(x^b_p, y^b_p)$3

with $(x^b_p, y^b_p)$4 a 256-bit nonce. This construction is used to ensure tamper-evidence and to prevent a patient from omitting intermediate blocks in a disclosed range without detection.

The framework’s privacy claim is therefore not based on de-identification alone. It combines: off-chain encrypted storage, per-block keys, anonymity-preserving ZKPs, and a hash chain linking content pointers and encrypted data into a verifiable sequence. A plausible implication is that the blockchain functions less as a data-sharing substrate than as a cryptographic accountability layer for controlled disclosure.

4. Time-Based Range Queries and Patient Control

The query primitive emphasized in AegisBlock is the time-based range query (Garg et al., 15 Aug 2025). A researcher locates a candidate patient block through public condition codes, then creates a request block that forks from that block and encodes the desired temporal interval together with the researcher’s identity public key and signature. Hospitals, acting as miners, validate the request block and append it to the chain once consensus is reached.

Patient control is then exercised through a second authorization step. The patient reviews the query and may deny it, approve it exactly, or narrow the requested range before signing an approval block (Garg et al., 15 Aug 2025). This means range selection is not merely a static consent preference but an interactive, per-request authorization decision. Access to data is therefore mediated by both blockchain consensus and patient intent.

If the approved interval contains $(x^b_p, y^b_p)$5 blocks, the patient sends the researcher $(x^b_p, y^b_p)$6 pieces of information: for each block, the symmetric key $(x^b_p, y^b_p)$7, the pointer $(x^b_p, y^b_p)$8, and the data hash $(x^b_p, y^b_p)$9; plus $(x^b_h, y^b_h)$0 for the block immediately preceding the first approved block $(x^b_h, y^b_h)$1, and the nonce $(x^b_h, y^b_h)$2 for the last approved block $(x^b_h, y^b_h)$3 (Garg et al., 15 Aug 2025). Using these values, the researcher recomputes the linked hashes: $(x^b_h, y^b_h)$4 then propagates the computation through the approved interval and finally checks

$(x^b_h, y^b_h)$5

against the on-chain value in the last approved block (Garg et al., 15 Aug 2025).

This mechanism is intended to enforce two constraints simultaneously. First, researchers cannot learn about unapproved blocks, because they do not receive the symmetric keys, pointers, or predecessor hash context necessary to extend the range. Second, patients cannot selectively omit approved interval blocks without breaking the chain of hashes and failing verification. The resulting access-control semantics are therefore cryptographically coupled to temporal disclosure.

5. Consensus, Threat Model, and Evaluation in the Medical Setting

AegisBlock uses a permissioned, signature-based proof-of-concept style consensus in which hospitals act as miners and a block is accepted once at least 50% of miners approve it (Garg et al., 15 Aug 2025). The paper assumes that malicious miners never exceed 50% and that there is no collusion between parties. Under these assumptions, malicious hospitals may reject blocks to impede progress, but cannot force invalid blocks to be accepted if honest hospitals remain at least half of the miner set.

The threat model explicitly considers malicious patients, malicious hospitals, and malicious researchers. A malicious patient may attempt to upload a block despite not being a valid user; a malicious hospital may sign blocks while invalid or may reject legitimate blocks; a malicious researcher may attempt to use disclosed information to infer records outside the approved range or to deanonymize patients (Garg et al., 15 Aug 2025). The framework’s defenses are correspondingly role-specific: ZK proofs enforce membership validity, co-signatures prevent unilateral block creation, the consensus threshold protects liveness against sub-majority malicious hospitals, and the range-query disclosure design prevents reconstruction outside approved intervals.

The empirical evaluation focuses on scalability and miner adversarial tolerance. The patient block creation experiment varies the number of hospitals among 2,000, 4,000, and 6,000 and the number of patients from 1 to 5 million; runtime and zero-knowledge transcript size grow approximately $(x^b_h, y^b_h)$6 (Garg et al., 15 Aug 2025). The hospital consensus experiment varies hospitals from 1,000 to 5,000 and malicious miner ratios from 10% to 40%; runtime grows approximately $(x^b_h, y^b_h)$7 in the number of hospitals, but for a fixed number of hospitals is largely insensitive to the malicious percentage because malicious nodes reject quickly while honest nodes perform the expensive verification (Garg et al., 15 Aug 2025).

A separate researcher access experiment fixes 6,000 hospitals and varies malicious miners from 10% to 50%. The paper reports that block creation times for the researcher request block and the patient approval block are less than 0.01 seconds and essentially constant, while verification times are relatively constant across malicious percentages, yielding approximately $(x^b_h, y^b_h)$8 behavior with respect to malicious percentage up to 50% (Garg et al., 15 Aug 2025). The abstract summarizes the system as scalable with respect to the number of patients and hospitals and efficient with up to 50% of malicious miners (Garg et al., 15 Aug 2025).

6. Broader Uses of “AegisBlock” Across the Literature

Although the medical framework is the only paper in the provided set that formally titles a system “AegisBlock,” related literature uses the term conceptually to describe modular secure components. In the autonomous-agent setting, the Aegis Protocol is a three-layered security framework with Layer 1 Foundational Identity based on W3C DIDs implemented via ION, Layer 2 Communication using ML-KEM and ML-DSA, and Layer 3 Verification using Halo2 zero-knowledge proofs for policy compliance (Adapala et al., 22 Aug 2025). The paper explicitly states that “AegisBlock” is not a named construct, but infers that an Aegis “block” can be understood as any reusable unit implementing DID-based identity management, PQC-based secure communication, Halo2-based policy proof generation and verification, or their composition (Adapala et al., 22 Aug 2025).

In LLM security, "AegisLLM: Scaling Agentic Systems for Self-Reflective Defense in LLM Security" uses the term informally for a runtime defense block built from four agents—orchestrator, responder, evaluator, and deflector—that wrap a base LLM without modifying its weights (Cai et al., 29 Apr 2025). That pipeline routes benign queries to a responder, unsafe ones to a deflector, and uses an evaluator to post-check safety, with DSPy modules and MIPRO prompt optimization governing the policy behavior (Cai et al., 29 Apr 2025). This suggests a modular “guardrail block” interpretation rather than a blockchain-specific one.

A different security meaning appears in "AEGIS: No Tool Call Left Unchecked -- A Pre-Execution Firewall and Audit Layer for AI Agents," where AEGIS is a pre-execution firewall sitting between model-generated tool calls and the execution layer (Yuan et al., 13 Mar 2026). It implements a three-stage pipeline—deep string extraction, content-first risk scanning, and composable policy validation—and records all decisions in a tamper-evident audit trail based on Ed25519 signatures and SHA-256 hash chaining (Yuan et al., 13 Mar 2026). The paper does not define “AegisBlock” formally, but frames AEGIS as a concrete realization of pre-execution blocking for agent tool calls, which is close to a functional interpretation of the term.

The copyright-management literature provides another adjacent usage. "Trustworthy AIGC Copyright Management with Full Lifecycle Recording and Multi-party Supervision in Blockchain" describes a consortium-chain system for recording the full lifecycle of AI-generated content, including Product ID, Model ID, Description Hash, Product Hash, Producer Sign, Model Sign, Owner Sign, BF, and Status in world state (Jiang et al., 2024). That paper does not use the name AegisBlock, but the provided details explicitly suggest that AegisBlock can be conceptualized as a practical realization or extension of this AIGC-Chain design. This suggests that the term can denote a provenance-preserving blockchain unit in addition to privacy-preserving medical disclosure.

Taken together, these papers do not establish a single canonical definition outside the medical framework. Instead, they reveal a recurring design pattern: “AegisBlock” denotes, formally or informally, a modular trust boundary that combines cryptographic verification, constrained interfaces, and auditability.

7. Significance, Limitations, and Open Directions

In the medical context, AegisBlock’s primary significance lies in combining patient-centric consent with verifiable longitudinal disclosure (Garg et al., 15 Aug 2025). Rather than treating privacy and research access as mutually exclusive, it operationalizes a compromise: public condition codes support cohort discovery, while patient-approved time-based range queries and chained hashes constrain what a researcher can actually retrieve and verify. The system’s contribution is therefore architectural as much as cryptographic.

The paper also makes clear that the current query model is limited. Future work includes conditional queries and count queries, since the present design focuses primarily on time-based range queries (Garg et al., 15 Aug 2025). Another open direction is reducing or eliminating the need for patients to reveal even the last block in a range, potentially through more advanced cryptographic techniques such as secure multi-party computation or more sophisticated zero-knowledge constructions (Garg et al., 15 Aug 2025). Communication complexity is another limitation: the hospital consensus process exhibits approximately $(x^b_h, y^b_h)$9 runtime in the number of hospitals, which the paper identifies as a target for more efficient permissioned-healthcare consensus designs.

Across adjacent literatures, comparable limitations recur in different forms. The Aegis Protocol for autonomous agents is explicitly simulation-based and early-stage, with a median proof-generation latency of 2.79 seconds in a 1,000-agent discrete-event simulation and 0 percent success across 20,000 attack trials, but no live cryptographic integration due to build stability issues (Adapala et al., 22 Aug 2025). AegisLLM’s modular defense pipeline remains empirical rather than formally guaranteed, even though it reports near-random WMDP performance and a 51% StrongREJECT improvement relative to the base model (Cai et al., 29 Apr 2025). The pre-execution AEGIS firewall for tool calls reports blocking all 48 attack instances in its curated suite with 1.2% false positive rate on 500 benign tool calls and 8.3 ms median interception latency across 1,000 consecutive interceptions, but remains rule- and policy-based and leaves broader anomaly detection to future work (Yuan et al., 13 Mar 2026). These comparisons suggest that “AegisBlock,” as a cross-domain concept, is generally associated with strong mediation and verifiability, but often within bounded evaluation settings.

A plausible synthesis is that AegisBlock names a class of systems that transform trust assumptions by inserting a cryptographically constrained, audit-friendly intermediary between parties that do not fully trust each other. In the medical framework, that intermediary is a permissioned blockchain plus off-chain cryptographic disclosure process (Garg et al., 15 Aug 2025). In agent security, it is a layered or runtime policy-enforcement module (Adapala et al., 22 Aug 2025, Cai et al., 29 Apr 2025, Yuan et al., 13 Mar 2026). In copyright provenance, it is a lifecycle-recording blockchain substrate (Jiang et al., 2024). The exact semantics differ, but the shared structure is a block-like trust mechanism that mediates access, constrains behavior, and makes disputes auditable.