Security Overview

Clique runs vendor-supplied 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 to be the code the vendor shipped, both before it runs and continuously while it runs. This page describes how that works at a level useful to security and infrastructure teams evaluating Clique.

SOC 2 Type II · audit in progress HIPAA-aligned architecture HIPAA BAA from day one Confidential Computing

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.

PHI crosses only the client-to-enclave boundary and is bounded by an mTLS session whose keys are released only after attestation. Attestation quotes, policy decisions, and signed audit events flow inside the control plane. Nothing carrying PHI ever crosses the hospital perimeter.

Anatomy of an Attested Workload

An "enclave" on Clique is a much stronger boundary than a container: 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.

Enclave self-measures. On launch, the enclave measures its firmware, kernel, sealed image digest, and launch policy, then produces a quote signed by the hardware attestation key (TDX REPORT / SEV-SNP ATTESTATION_REPORT / NVIDIA SPDM report).
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.
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; the enclave never receives keys.
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.
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 an alert in the control plane's compliance panel.

Audit Log Integrity

Every security-relevant event is written to an append-only log: attestation verdicts, session opens and closes, policy changes, key releases, heartbeat results, and admin actions. 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. A corrupted event, a missing index, or a failed signature raises an alert within 60 seconds and pages the on-call engineer.
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. The network layer enforces this rule on top of written 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 our SOC 2 Type II audit is being conducted against; auditor commentary will be available under NDA once the report is issued.

Control	Clique mechanism
HIPAA §164.312(a)(2)(iv) Encryption at rest	AES-256-GCM on the audit volume and on all persistent enclave state; keys managed by a dedicated KMS with automatic rotation.
HIPAA §164.312(e)(1) Transmission security	TLS 1.3 everywhere, HSTS enforced, certificate pinning on API endpoints. mTLS between enclaves and the control plane, with session keys released only after attestation.
HIPAA §164.312(b) Audit controls	Hash-chained, Ed25519-anchored append-only audit log (see Audit Log Integrity).
HIPAA §164.308(a)(1)(ii)(D) Information system activity review	Continuous replay-verification of the audit chain; real-time anomaly alerts routed to on-call security engineering.
HIPAA §164.308(a)(5)(ii)(C) Log-in monitoring	Every authentication attempt, MFA challenge, and session open is logged with actor, source, and outcome.
HIPAA §164.312(a)(1) Access control	RBAC with Clinician / IT / Researcher / Admin roles; least-privilege by default; break-glass access is time-boxed and written to the audit chain.
HIPAA §164.312(c)(1) Integrity	Hash-chained audit log, signed attestation quotes, and measured boot together establish integrity of both data history and execution environment.
HIPAA §164.504(e) Vendor BAAs	A signed BAA with the model vendor is a hard prerequisite; enclaves cannot be provisioned for a vendor until the BAA reference is present in the policy engine.
HIPAA §164.316(b)(2) Documentation retention	Seven-year retention of audit logs, attestation evidence, and policy history on WORM-backed storage.
SOC 2 CC6.1 Logical access	SSO (SAML 2.0 / OIDC) with enforced MFA, role-based authorization, and hardware-key support for privileged roles.
SOC 2 CC6.6 External boundary protection	Enclave egress DENY-by-default; allow-list limited to two in-perimeter destinations; perimeter egress limited to the signed audit stream.
SOC 2 CC6.7 Transmission confidentiality	TLS 1.3 on all transport; mTLS plus attestation-gated session keys between control plane and enclaves.
SOC 2 CC7.1 Change management	Every container image SHA, config bundle, and policy change is recorded in the audit log; promotion to production requires a signed approval that is itself an audit event.
SOC 2 CC7.2 System monitoring	Continuous heartbeat re-attestation, audit-chain replay, and anomaly detection feed a single compliance panel shown in the control plane.

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

Our SOC 2 Type II audit is underway with an independent third-party firm, scoped to the Trust Service Criteria for Security, Availability, and Confidentiality. We are early-stage and will not claim the certification before the report is issued; the control mapping below is what the audit is being conducted against, and continuous monitoring is already in place. The report will be available under NDA on completion, and we will share the current auditor status with any prospective customer on request.

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 the policy engine enforces it in code as well as in 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 ask about the status of our SOC 2 audit, request a copy of the architecture diagram in a higher-resolution form, or discuss a specific control with our security team, contact security@cliquehealth.com.