Security Overview

Last updated: April 1, 2026

Clique runs vendor-supplied AI models against PHI inside the hospital, never outside it. The security model is built around two ideas: data never leaves the hospital perimeter, and the code that touches it can be cryptographically proven -- before it runs and continuously while it runs -- to be the code the vendor shipped. This page describes how that works at a level useful to security and infrastructure teams evaluating Clique.

Architecture & Trust Boundaries

Clique is deployed as three nested trust zones inside a customer hospital. The innermost zone -- the confidential-computing enclave -- is the only place PHI in use is ever processed. Each boundary enforces a different control, and only specific well-typed messages are allowed to cross them.

Anatomy of an Attested Workload

An "enclave" on Clique is not a container in the Docker sense. It is a hardware-isolated VM whose memory is encrypted with a key that never leaves the CPU (or, for GPU workloads, the H100's confidential-compute controller). The contents of a Clique enclave are:

• Hardware root of trust. Intel TDX, AMD SEV-SNP, or NVIDIA H100 Confidential Compute, depending on the host. Each provides a per-machine attestation key rooted in a manufacturer-signed certificate chain.
• Measured boot. The firmware, bootloader, kernel, and initramfs are hashed into PCRs (PCRs 0-9 on TPM-backed hosts; TDX MRTD / RTMR0-3 on Intel TDX). Any substitution changes the measurement, which changes the quote, which fails verification.
• Sealed vendor image. The model container is pulled by digest only (sha384:<measurement>), never by tag. The digest is pinned in a vendor-signed manifest and included in the attestation payload as a runtime measurement.
• Runtime isolation from the host kernel. The host hypervisor cannot read enclave memory. The enclave has no /proc/host, no shared filesystems, and no debugger attach surface. Side-channel mitigations (LVI, TSX aborts, cache partitioning on TDX) are enabled at boot.
• Egress policy: DENY ALL by default. The enclave has a single outbound unix socket to an attested sidecar that brokers (a) the inference response channel back to the client and (b) the audit-event stream to the control plane. No DNS, no general-purpose network, no package fetches at runtime.

Attestation Flow

Every workload is verified before it is allowed to receive session keys, and re-verified continuously while it runs.

1. Enclave self-measures. On launch, the enclave measures itself -- firmware, kernel, sealed image digest, launch policy -- and produces a quote signed by the hardware attestation key (TDX REPORT / SEV-SNP ATTESTATION_REPORT / NVIDIA SPDM report).
2. Control plane verifies the quote. The attestation verifier validates the hardware signature chain against the vendor CA (Intel PCS, AMD KDS, NVIDIA NRAS) and matches the measurement payload against the vendor-signed manifest for that model version.
3. Policy engine evaluates expected values. PCR / MRTD values, image digest, launch flags, and customer-specific policy (e.g. "H100 CC must be on", "model vX.Y.Z only") are checked. Any mismatch is a hard failure -- not a warning.
4. Session keys are released. Only if every check passes, the control plane releases the per-session mTLS key material and the wrapping key used to unseal vendor weights. Without this step the enclave has no way to communicate with clients or decrypt the model.
5. Heartbeat re-attestation every 60s. While the workload runs, the enclave re-attests on a 60-second heartbeat. A failed or missing heartbeat quarantines the session, revokes keys, and raises a compliance-panel alert identical to the one shown in the control plane.

Audit Log Integrity

Every security-relevant event -- attestation verdict, session open/close, policy change, key release, heartbeat result, admin action -- is written to an append-only log. Integrity is guaranteed by a per-tenant hash chain anchored to an Ed25519 signing key held by the control plane.

event[n].hash = sha256( event[n-1].hash || event[n].payload )
root_sig      = Ed25519_sign( control_plane_key, event[n].hash )

• Each event's hash binds it to every prior event; modifying or removing any event breaks the chain at that point and every point after.
• The rolling root hash is signed with Ed25519 on every write. Signatures are batched and published to an internal Merkle root once per hour; that Merkle root is itself timestamped and archived separately from the primary log store.
• A background verifier replays the chain continuously. Any mismatch -- corrupted event, missing index, signature failure -- raises an alert within 60 seconds and page the on-call.
• Logs are retained for 7 years in accordance with HIPAA §164.316(b)(2). The append-only store is WORM-backed; operator accounts have no delete permission.
• Customers can export the signed log and verify it independently using the published control-plane public key. Sample verifier code is available on request.

Data Residency & Egress

Clique's residency story is simple: PHI stays in the hospital, full stop. This is enforced at the network layer, not just by policy.

• PHI never leaves the hospital perimeter. Inference requests and responses traverse only the client ←→ enclave path, both sides of which sit inside the customer's network.
• Enclave egress is DENY by default. iptables / eBPF rules drop all outbound traffic except the two allowed destinations: the in-perimeter client endpoint (mTLS, PHI-bearing) and the in-perimeter control-plane audit endpoint (no PHI).
• Only attestation tokens and control-plane telemetry leave the hospital. This is a narrow, well-typed stream: signed attestation quotes, signed audit events, heartbeat metrics, error counters. Schemas are published; there are no free-form fields.
• The BAA-scoped audit stream is the only off-site channel. Every field is listed in the BAA and every byte is signed. If it is not in that schema, it does not leave.
• Model weights are pulled inbound only. Vendor weights are encrypted at rest and unsealed inside the enclave after attestation. The vendor never has a return path to PHI.

Compliance Mapping

The following table maps specific HIPAA Security Rule and SOC 2 Common Criteria controls to the Clique mechanisms that satisfy them. This is the mapping used in our SOC 2 Type II report and is available with auditor commentary under NDA.

Encryption

In transit. TLS 1.3 with HSTS and certificate pinning on API connections. Internal service-to-service traffic uses mutual TLS. Enclave sessions additionally derive per-session keys that are released only after successful attestation.

At rest. AES-256-GCM on all persistent data, managed by a dedicated KMS with automatic rotation. Customer-managed encryption keys (CMEK) are available for enterprise deployments. Model weights are encrypted at rest and unsealed inside the enclave after attestation.

Access Controls

• RBAC. Clinician / IT / Researcher / Admin role archetypes, with granular permissions scoped to the minimum necessary.
• SSO. SAML 2.0 and OIDC integration with the customer's identity provider.
• MFA. Enforced for all accounts; hardware security keys (WebAuthn / FIDO2) required for privileged roles.
• Least privilege. Internal employee access is scoped, time-boxed, and requires written justification. Break-glass access is written to the audit chain in real time.
• Audit. Every access event is recorded immutably. See Audit Log Integrity above.

Infrastructure Security

• Production environments are isolated in dedicated VPCs with strict segmentation and default-deny egress.
• All infrastructure is managed as code. Configuration drift is detected and alerted on automatically.
• Container images are scanned pre-deploy and again on a rolling schedule; critical CVEs block promotion.
• Host-based intrusion detection runs across all production systems. The enclave host is additionally monitored for integrity-measurement deviations.

SOC 2 Type II

Clique has completed SOC 2 Type II certification, independently audited by a third-party firm. Scope covers the Trust Service Criteria for Security, Availability, and Confidentiality. Continuous monitoring and annual re-certification apply. A copy of the report is available upon request under NDA.

Incident Response

We maintain a documented incident response plan, tested regularly through tabletop exercises and simulations:

• 24/7 on-call security engineering coverage
• Automated alerting for anomalous activity, failed attestations, and audit-chain integrity failures
• Defined severity classification and escalation procedures
• Customer notification within 24 hours for incidents affecting their data
• HIPAA breach notification within the timeframes required by 45 CFR 164.410
• Post-incident review and published root cause analysis

Penetration Testing

Independent third-party firms conduct penetration tests at least annually. Scope covers the application layer, APIs, infrastructure, cloud configurations, and the enclave attestation path. Critical and high findings are remediated within defined SLAs. Summary reports are available to customers under NDA.

Vendor Security

Model vendors with access to the enclave runtime undergo security review before onboarding and are re-assessed annually. A signed BAA is a hard prerequisite for enclave provisioning and is enforced by the policy engine, not just by process.

Responsible Disclosure

Security researchers are welcome to report vulnerabilities to security@cliquehealth.com. We commit to:

• Acknowledgement within 48 hours
• Initial severity assessment within 5 business days
• Fix windows scaled to severity: critical within 7 days, high within 30, medium within 90
• Good-faith researchers will not be pursued legally for testing that respects user privacy, avoids service disruption, and does not exfiltrate PHI

We do not currently operate a paid bug bounty -- we are early-stage and would rather be honest about that than promise payouts we cannot commit to. We credit reporters by name (with permission) in our security release notes.

Questions

To request our SOC 2 report, a HITRUST letter, a copy of the architecture diagram in a higher-resolution form, or to discuss a specific control with our security team, contact security@cliquehealth.com.