compliance gate

---

title: ComplianceGate & Integrity Health created: 2026-07-07 updated: 2026-09-08 type: concept tags: [compliance, layer-2] confidence: high source_files:

• contracts/src/health/ComplianceGate.sol
• contracts/src/health/EHRGate.sol
• contracts/src/framework/AgentAuthorityResolver.sol
• contracts/src/health/SmartBAAFactory.sol
• contracts/src/health/CoveredEntityRegistry.sol

---

Integrity Health is the HIPAA/healthcare vertical — the flagship proof that the Integrity Protocol works in the most heavily regulated industry there is. It is not a side feature; it is the demonstration that makes the rest of the protocol credible.

ComplianceGate is the per-agent primitive (an EIP-1167 clone) that connects a single agent to that vertical.

Table of contents

• What it does
• The Integrity Health stack (shared singletons)
• The closed loop

What it does

Each agent's ComplianceGate declares its regulated vertical (None | Healthcare) and exposes one live read the oracle and dashboard can call without knowing Integrity Health's internals:

function isHealthcareCompliant(address coveredEntity) external view returns (bool);

It never fakes a true. For a Healthcare-vertical agent it does a live read: CoveredEntityRegistry.isActiveCoveredEntity(coveredEntity) and SmartBAAFactory.isBAAActive(coveredEntity, agent). Self-declared compliance flags (mirroring the SDK's integrity.compliance.* telemetry attributes) are stored separately and are never consulted by this live-verified boolean — a dishonest agent cannot self-declare its way to compliance.

The Integrity Health stack (shared singletons)

• CoveredEntityRegistry — registry of HIPAA covered entities and business associates (admin-vetted; being listed is a claim of real legal status).
• SmartBAAFactory / SmartBAA — one on-chain Business Associate Agreement escrow per (covered entity, agent) pair; the agent posts $ITK collateral, slashable to the covered entity on an arbitrated breach. See Smart BAA for the full state machine and what the old wiki overstated (no on-chain EIP-712 signing, no dispute-window timer, no controller recovery — corrected there).
• HIPAAGuardrailRegistry — anchors which OPA policy version governed each PHI access decision.
• EHRGate — the real PHI-access enforcement boundary: requires patient consent and an active SmartBAA and a minimum AIS, resolving the agent's authority and AIS through AgentAuthorityResolver.

ComplianceGate does not replace EHRGate as the enforcement point — it is the read-optimized summary surface. EHRGate still performs its own live checks at access time through patient grants, active BAAs, and the shared authority resolver.

The closed loop

The BCC middleware enforces the same BAA on-chain before an agent even acts: a clinical BCC commitment carries a signed covered_entity_address, OPA flags it requires_baa, and the middleware calls SmartBAAFactory.isBAAActive(coveredEntity, agent) — failing closed if it can't positively confirm.

flowchart TB
    BCC["BCC commitment<br/>(covered_entity_address, requires_baa)"]
    MW["bcc_middleware<br/>(pre-execution gate)"]
    CG["ComplianceGate.isHealthcareCompliant<br/>(read-optimized summary)"]
    EHR["EHRGate.checkAccess<br/>(real-time PHI-access enforcement)"]
    BAA["SmartBAAFactory.isBAAActive(coveredEntity, agent)"]

    BCC --> MW --> BAA
    CG --> BAA
    EHR --> BAA
    EHR -->|also checks| Consent["patient consent"]
    EHR -->|also checks| AIS["minimum AIS<br/>(authority resolver read)"]

Loading

All three consult the same underlying isBAAActive read rather than caching their own copy of BAA status — a lapsed BAA is invisible to none of them.

PHI never reaching the oracle in the first place is a separate, SDK-side concern from this on-chain compliance gate — see Observability & PHI Safety for the client-side Redactor design.

Related: agent primitives, BCC, Smart BAA, contracts.