HIPAA Compliance with Secure Enclaves

Healthcare organizations face a paradox. AI tools can surface life-saving insights from patient records — catching missed diagnoses, flagging drug interactions, identifying deteriorating patients before a crisis. But the data that makes AI powerful is exactly what HIPAA most strictly protects. Protected Health Information (PHI) can't just be sent to an inference API.

The usual answers — redact the data, use a Business Associate Agreement, process everything on-premises — each come with real tradeoffs. Redaction destroys clinical signal. BAAs provide legal coverage but not technical assurance. On-premises infrastructure is expensive and hard to scale.

Secure enclaves offer a different path: run AI and analytics workloads directly on PHI in a hardware-isolated environment where not even the cloud provider can access the data, and produce cryptographic proof of that isolation for auditors.

This guide covers HIPAA's specific technical requirements, how enclave-based architectures satisfy them, and what implementation looks like in practice.

What HIPAA Actually Requires Technically

HIPAA's Security Rule (45 CFR Part 164) is divided into Administrative, Physical, and Technical safeguards. For cloud-based AI workloads on PHI, the Technical Safeguards (§164.312) are the most relevant.

Access Controls (§164.312(a)(1))

Covered Entities must implement technical policies and procedures allowing only authorized persons or software programs to access electronic PHI. This includes:

• Unique user identification — each user or system must have a unique identifier
• Automatic logoff — terminate sessions after inactivity
• Encryption and decryption — addressable implementation specification

For AI workloads, the access control requirement is satisfied if the PHI is only accessible within an authenticated, hardware-isolated execution environment. Enclaves satisfy this because the isolation is enforced at the CPU level — not via software ACLs that can be misconfigured.

Audit Controls (§164.312(b))

Covered Entities must implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI.

This is where enclave attestation becomes directly useful. Every enclave execution produces a hardware-signed attestation document that records:

• The exact software image that ran
• The timestamp of execution
• Cryptographic proof that the environment was unmodified
• The nonce binding the attestation to a specific request

This audit log is not just a record — it's a tamper-evident, cryptographically verifiable record. An auditor cannot claim the record was altered because the signature chain runs back to the CPU manufacturer's root of trust.

Integrity Controls (§164.312(c)(1))

ePHI must be protected from improper alteration or destruction. The addressable specification is the ability to authenticate ePHI.

PCR measurements (Platform Configuration Registers) in the attestation document provide exactly this. PCRs are cryptographic hashes of the enclave image, kernel, and loaded modules — fingerprinting the exact state of the environment that processed the PHI. Any modification to the software running in the enclave changes the PCRs, making tampering detectable.

Transmission Security (§164.312(e)(1))

PHI transmitted over electronic networks must be guarded against unauthorized access. The addressable specifications include encryption in transit.

Enclave-based architectures handle this with mutual TLS between the client and the enclave endpoint. The connection is authenticated using the enclave's attestation-backed certificate — the client can cryptographically verify it is communicating with an untampered enclave before transmitting any PHI.

The Business Associate Agreement Question

Many healthcare organizations stop at getting a BAA from their cloud AI provider. This satisfies the administrative requirement, but it does not satisfy the technical safeguards on its own.

A BAA is a contractual instrument. It binds the provider to use PHI only for agreed-upon purposes and to implement appropriate safeguards. What it cannot do:

• Provide technical proof that a specific computation ran correctly
• Prevent an insider at the provider from accessing data (only deterrence and liability)
• Satisfy auditors who want cryptographic evidence rather than a contract

The HHS Office for Civil Rights (OCR) has signaled in guidance and enforcement actions that Technical Safeguards must be implemented as technical controls, not just administrative agreements. A BAA combined with hardware isolation and attestation provides both layers.

Architecture: PHI Through a Secure Enclave

Here's what a HIPAA-compliant AI architecture using secure enclaves looks like:

┌─────────────────────────────────────────────────────┐
│  Covered Entity / Workforce Member                  │
│                                                     │
│  EHR System ──────► Data Export (encrypted)         │
│                           │                         │
└───────────────────────────│─────────────────────────┘
                            │ Mutual TLS
                            ▼
┌─────────────────────────────────────────────────────┐
│  Treza Platform (BAA Signatory)                     │
│                                                     │
│  ┌─────────────────────────────────────────────┐    │
│  │  AWS Nitro Enclave (Hardware Isolated)       │    │
│  │                                             │    │
│  │  PHI decrypted in CPU-protected memory      │    │
│  │  AI model processes PHI                     │    │
│  │  Attestation document generated             │    │
│  │  Output encrypted before leaving boundary   │    │
│  │                                             │    │
│  └─────────────────────────────────────────────┘    │
│                                                     │
│  Cloud Provider cannot access enclave memory        │
│  Platform logs: encrypted metadata only             │
│                                                     │
└─────────────────────────────────────────────────────┘
                            │
                            ▼ Encrypted output + Attestation
┌─────────────────────────────────────────────────────┐
│  Covered Entity                                     │
│                                                     │
│  AI output (decrypted locally)                      │
│  Attestation document (stored for audit)            │
│                                                     │
└─────────────────────────────────────────────────────┘

The key properties of this architecture:

1. PHI never exists in plaintext outside the enclave boundary. It arrives encrypted, is decrypted by the CPU inside the enclave, and the output is re-encrypted before it leaves.

2. The cloud provider operates the physical infrastructure but cannot see the data. AWS Nitro Enclaves isolate memory from the parent instance, the hypervisor, and AWS itself.

3. Every computation produces a signed audit record. The attestation document is generated by the Nitro hardware, not by software — it cannot be forged by the platform operator.

4. The covered entity can independently verify the attestation. PCR values can be checked against the expected values for the AI model image, confirming no tampering occurred.

Implementation with the Treza SDK

Deploy a Clinical AI Workload

import { TrezaClient } from '@treza/sdk';
 
const treza = new TrezaClient({
  baseUrl: 'https://app.trezalabs.com',
  apiKey: process.env.TREZA_API_KEY,
});
 
// Deploy a clinical summarization model into a Nitro Enclave
const enclave = await treza.createEnclave({
  name: 'clinical-nlp-prod',
  region: 'us-east-1',
  walletAddress: process.env.WALLET_ADDRESS,
  providerId: 'aws-nitro',
  providerConfig: {
    dockerImage: 'myorg/clinical-summarizer:v3.2',
    cpuCount: 4,
    memoryMiB: 8192,
  },
});
 
console.log('Enclave deployed:', enclave.id);

Verify Before Processing PHI

Always verify the attestation before sending any PHI. This step confirms the enclave is running your exact model image and has not been tampered with.

// Use a nonce to bind this attestation to this specific verification
const nonce = `hipaa-audit-${Date.now()}-${crypto.randomUUID()}`;
 
const verification = await treza.verifyAttestation(enclave.id, { nonce });
 
if (!verification.isValid) {
  // Do NOT proceed — the enclave may be compromised
  throw new Error(`Attestation failed: ${verification.error}`);
}
 
// Verify PCR values match the expected image hash
const expectedPCR0 = process.env.EXPECTED_PCR0; // hash of your Docker image
if (verification.pcrs['0'] !== expectedPCR0) {
  throw new Error('Enclave image hash mismatch — unexpected software running');
}
 
// Store the attestation document for your HIPAA audit log
await auditLog.store({
  enclaveId: enclave.id,
  nonce,
  attestation: verification.attestationDocument,
  pcrs: verification.pcrs,
  timestamp: new Date().toISOString(),
  hipaaCompliant: verification.complianceChecks.hipaa,
});

Process PHI in the Enclave

// Structured clinical note for AI summarization
const clinicalNote = {
  patientId: 'INTERNAL-ID-ONLY', // use internal IDs, not names
  encounterDate: '2026-02-13',
  chiefComplaint: 'Chest pain, onset 3 hours ago...',
  vitals: { bp: '142/88', hr: 94, spo2: 97 },
  hpi: 'Patient is a 64-year-old presenting with...',
  medications: ['metformin 1000mg BID', 'lisinopril 10mg QD'],
  assessment: 'Rule out ACS...',
};
 
const result = await treza.callEnclave(enclave.id, {
  endpoint: '/v1/summarize',
  method: 'POST',
  body: {
    note: clinicalNote,
    task: 'discharge_summary',
    format: 'structured',
  },
});
 
// PHI was processed entirely inside the enclave
// The cloud provider saw only encrypted bytes in transit and in memory
const summary = result.data;

Generate a HIPAA Compliance Report

For OCR audits or internal compliance reviews, generate an attestation-backed report covering a specific time period.

const complianceReport = await treza.getComplianceReport(enclave.id, {
  startDate: '2026-01-01',
  endDate: '2026-03-31',
  standard: 'hipaa',
  format: 'pdf',
});
 
// The report includes:
// - List of all executions with timestamps
// - PCR measurements for each run (proving software integrity)
// - Hardware attestation signatures from AWS Nitro
// - Mapping to HIPAA Technical Safeguard sections
// - Access control log (who requested each computation)

HIPAA Safeguard Mapping

Common Implementation Questions

Does Treza sign a BAA?

Yes. Covered Entities and Business Associates using Treza for PHI processing can execute a BAA with Treza Labs. This, combined with the technical controls described above, satisfies both the administrative and technical safeguard requirements.

Can we use our own model weights?

Yes. Docker-packaged models — including proprietary fine-tuned clinical models — are loaded into the enclave. The model weights are protected by the same hardware isolation as the PHI. The cloud provider cannot access either.

What happens if the enclave is terminated unexpectedly?

Nitro Enclaves are ephemeral by design. When an enclave shuts down (whether expected or unexpected), all memory is cryptographically erased. PHI cannot persist or leak from a terminated enclave. This is a HIPAA-favorable property: it prevents residual PHI accumulation.

How do we handle the minimum necessary standard?

The minimum necessary standard (§164.502(b)) requires that PHI be limited to the minimum needed for a given purpose. This is handled at the application layer — structure your API calls to send only the fields required for the specific AI task. The enclave processes what it receives; your application controls what gets sent.

Does this work with EHR integrations (Epic, Cerner, etc.)?

Yes. The enclave accepts standard input formats (HL7 FHIR, C-CDA, or raw JSON). Your existing EHR integration sends structured data to the enclave endpoint over mutual TLS. The response is structured output — summaries, flags, classifications — that flows back into your EHR workflow.

What This Doesn't Cover

Enclaves address the technical safeguards for data processing. HIPAA compliance is broader:

• Workforce training (§164.308(a)(5)) — your staff still needs HIPAA training
• Risk analysis (§164.308(a)(1)) — enclave deployment should be documented in your risk analysis
• Policies and procedures (§164.316) — your organization needs documented policies for AI systems processing PHI
• Physical safeguards — the physical security of workstations and devices accessing the enclave API

Technical controls are a necessary component of HIPAA compliance, not a complete substitute for the program as a whole.

Getting Started

Treza supports HIPAA workloads in production. The process:

1. Reach out — we'll walk through your specific use case and execute a BAA
2. Deploy — package your AI workload as a Docker container and deploy via the SDK or CLI
3. Verify — run attestation verification and confirm PCR values match your image
4. Integrate — connect to your EHR system or data pipeline via the enclave API
5. Audit — retrieve compliance reports on demand for OCR audits or internal review

Get in touch to discuss your HIPAA AI workload.

Further Reading

• How to Run AI on Sensitive Data Without Violating HIPAA or GDPR — Broader guide covering PHI, PII, and financial data
• What Is a TEE? Complete Guide — How Nitro Enclaves and other TEEs work
• Cryptographic Compliance for Regulatory Requirements — Attestation as audit evidence
• HHS HIPAA Security Rule — Official guidance from the Office for Civil Rights
• AWS Nitro Enclaves — Underlying hardware isolation technology
• Treza SDK on GitHub

Treza is a confidential compute platform that makes compliance automatic. Deploy any workload into a hardware-protected enclave — data encrypted in memory, inaccessible to the cloud operator, every execution backed by cryptographic proof. Get started.