HIPAA-Compliant Agent Communication for Healthcare AI

The Compliance Problem: AI Agents and Healthcare Data

HIPAA's Security Rule requires three categories of safeguards for electronic PHI (ePHI): administrative, physical, and technical. For agent-to-agent communication, the technical safeguards are the hardest to satisfy because they must apply to every system that touches ePHI in transit.

The relevant technical safeguards under 45 CFR 164.312 include:

• Access control (164.312(a)): Only authorized persons or software programs should access ePHI
• Audit controls (164.312(b)): Hardware, software, and procedural mechanisms to record and examine access to ePHI
• Integrity controls (164.312(c)): Policies and procedures to protect ePHI from improper alteration or destruction
• Transmission security (164.312(e)): Technical security measures to guard against unauthorized access to ePHI during electronic transmission

GDPR adds its own requirements for healthcare data processing under Article 9 (special categories of personal data), including explicit consent, data minimization, and the right to erasure. For organizations operating across the US and EU, both regulatory frameworks apply simultaneously.

The compliance challenge is not abstract. When an AI agent sends a patient summary from System A to System B, every intermediary system in the data path must satisfy these requirements. That includes the transport layer, any relay infrastructure, logging systems, and error handling mechanisms. A single unencrypted hop, a single log entry containing PHI in plaintext, or a single third-party system without a Business Associate Agreement (BAA) creates a compliance violation.

Why Cloud APIs Are Risky

The most common architecture for AI agents involves calling cloud APIs -- OpenAI, Anthropic, Google, or others -- to process data. For general-purpose tasks, this works. For healthcare data, it creates a compliance gap that is difficult to close.

The core problem: most AI API providers do not sign BAAs by default. A Business Associate Agreement is a legal contract required by HIPAA whenever a "covered entity" (hospital, clinic, insurer) shares PHI with a "business associate" (any vendor that handles PHI on their behalf). Without a BAA, sending PHI to the API provider is a HIPAA violation, regardless of how the data is encrypted in transit.

Some providers offer BAA-covered tiers (typically enterprise plans with significant minimum commitments), but the BAA covers the API processing, not the data path. If your agent sends PHI through a series of hops -- agent to API gateway to load balancer to inference server -- each hop must be covered. And the agent-to-agent communication layer is almost never included in the API provider's BAA scope.

The dynamic nature of AI agents makes this worse. As one compliance researcher observed: "Static controls collapse when an agent rewrites its plan mid-run." An agent that decides autonomously to call a new API endpoint, forward data to another agent, or store intermediate results in a cache creates data flows that were never anticipated in the Data Protection Impact Assessment (DPIA). Each unexpected data flow is a potential compliance gap.

The Pilot Approach: No Data Touches Third-Party Infrastructure

Pilot Protocol is a peer-to-peer overlay network. Agents connect directly to each other through encrypted UDP tunnels. There is no central server that relays application data. The rendezvous infrastructure (registry and beacon) handles peer discovery and NAT traversal signaling, but application data never passes through the rendezvous servers.

This architecture eliminates an entire category of compliance risk. When Agent A sends a patient summary to Agent B, the data travels through a direct encrypted tunnel between the two agents. No cloud API sees the data. No third-party relay sees the data. No intermediary log captures the data. The only systems that handle ePHI are the two agent endpoints, both of which are on infrastructure you control.

For the NAT traversal case where direct connectivity is not possible (symmetric NAT on both sides), Pilot uses relay through the beacon server. Even in this case, the data is end-to-end encrypted before it reaches the relay. The beacon sees only encrypted ciphertext that it cannot decrypt, because it does not possess the session key established during the agents' X25519 key exchange.

# Architecture: direct tunnel (no third party in data path)

  Agent A (Hospital)           Agent B (Specialist)
  +-----------------+         +-----------------+
  | PHI Processing  |         | PHI Processing  |
  | Pilot Daemon    | ======= | Pilot Daemon    |
  +-----------------+  E2E    +-----------------+
                     Encrypted
                      Tunnel

# The registry only handles address resolution (no PHI)
# The beacon only handles NAT signaling (no PHI)
# Even relay mode: beacon sees only encrypted ciphertext

Encryption Properties: X25519 + AES-256-GCM End-to-End

Pilot's encryption is not optional. When two agents establish trust, all subsequent communication is encrypted by default using port 443 (the secure port). The encryption stack uses:

• X25519 key exchange: Elliptic-curve Diffie-Hellman for session key establishment. Each connection generates a fresh ephemeral key pair, providing forward secrecy -- compromising one session key does not compromise past or future sessions.
• AES-256-GCM: Authenticated encryption for all tunnel traffic. GCM provides both confidentiality (data cannot be read) and integrity (data cannot be modified without detection).
• Random nonce prefix per connection: Each secure connection generates a random nonce prefix, preventing nonce reuse across sessions. This is a defense-in-depth measure against nonce-misuse attacks.
• Ed25519 identity signing: Trust handshakes are signed with the agent's permanent Ed25519 key, ensuring that the peer you establish a session with is the peer you intended to trust.

The entire encryption stack uses Go's standard library (crypto/ecdh, crypto/aes, crypto/cipher, crypto/ed25519). There are zero external dependencies. This matters for compliance because every dependency is an additional surface area that must be audited, and Go's standard crypto libraries are well-audited and FIPS-adjacent (the crypto/tls package supports FIPS 140-2 mode on supported platforms).

Trust Model as Access Control

HIPAA requires access controls that limit ePHI access to authorized persons and software programs. In Pilot, the trust model is the access control mechanism. An agent cannot communicate with another agent unless both sides have completed a mutual trust handshake.

Handshake as explicit consent

The trust handshake is a two-party protocol. Agent A requests trust from Agent B, providing a justification. Agent B reviews and explicitly approves or rejects. This maps directly to HIPAA's "minimum necessary" principle and GDPR's explicit consent requirement for special category data:

# Hospital agent requests trust with specialist agent
pilotctl trust request 1:0001.0000.0042 \
  --justification "Patient referral data exchange per BAA #2026-0142"

# Specialist agent reviews
pilotctl trust list-pending --json
# {
#   "address": "1:0001.0000.0017",
#   "justification": "Patient referral data exchange per BAA #2026-0142",
#   "public_key": "ed25519:abc123...",
#   "tags": ["role:clinical","dept:radiology"]
# }

# Specialist approves
pilotctl trust approve 1:0001.0000.0017

The justification field creates a documented record of why access was granted. This record is stored locally and can be exported for compliance audits. The BAA reference in the justification links the technical access control to the legal agreement -- a practice that auditors specifically look for.

Revocation as instant de-authorization

When a BAA expires, a physician leaves a practice, or a collaboration ends, trust revocation is immediate:

# Revoke access immediately
pilotctl trust revoke 1:0001.0000.0042

# Effect is instant:
# - Active connections are terminated
# - The revoked agent cannot reconnect
# - The revoked agent cannot discover your address
# - No waiting for certificate expiration or CRL propagation

Compare this to certificate-based access control where revocation requires CRL distribution or OCSP checking, with propagation delays measured in hours. Pilot's revocation is effective within the keepalive interval (30 seconds by default, immediate if a connection is active).

Private by default

Agents on Pilot are invisible by default. An agent that has not been explicitly made public cannot be discovered by any other agent, even if they know its address. This means a healthcare agent processing PHI is invisible to the entire network unless it explicitly trusts specific peers. There is no directory listing, no enumeration, no way for an unauthorized agent to discover that a healthcare agent exists.

This is the opposite of the "Agent Card" model used by some protocols, where agents advertise their capabilities publicly. For healthcare, public advertisement of agent capabilities would leak metadata about what kinds of data processing are happening -- itself a potential compliance concern.

Audit Trails: Structured Logging and Event Webhooks

HIPAA's audit controls requirement (164.312(b)) mandates mechanisms to record and examine access to ePHI. Pilot provides two audit mechanisms:

Structured logging via slog

Every Pilot daemon logs connection events, trust operations, and data exchanges using Go's structured logging package (log/slog). Log entries include structured fields that can be parsed by log aggregation systems:

# Example log entries (JSON format)
{"time":"2026-02-28T10:15:03Z","level":"INFO","msg":"trust.approve","peer":"1:0001.0000.0042","justification":"Patient referral per BAA #2026-0142"}
{"time":"2026-02-28T10:15:04Z","level":"INFO","msg":"connection.open","peer":"1:0001.0000.0042","port":443,"encrypted":true}
{"time":"2026-02-28T10:15:05Z","level":"INFO","msg":"data.send","peer":"1:0001.0000.0042","port":1001,"bytes":4096}
{"time":"2026-02-28T10:15:30Z","level":"INFO","msg":"connection.close","peer":"1:0001.0000.0042","reason":"complete"}

Webhook events for SIEM integration

For organizations running a Security Information and Event Management (SIEM) system, Pilot can push events to a local HTTP endpoint:

# Forward all agent events to your SIEM
pilotctl set-webhook http://localhost:9090/siem-ingest

# Events are pushed in real time:
# - trust.request, trust.approve, trust.revoke
# - connection.open, connection.close
# - task.submit, task.complete
# - data.send, data.receive

The webhook pushes to a local HTTP server -- it does not send events to an external service. This keeps audit data on your infrastructure. The SIEM integration happens on your side, in your network, under your control.

Architecture: Self-Hosted Rendezvous + Encrypted Tunnels + Trust-Gated Access

For maximum compliance, healthcare organizations can self-host the entire Pilot infrastructure. The rendezvous server (registry + beacon) is a single Go binary that runs on your own hardware:

# Deploy your own rendezvous server (inside your network)
pilotctl rendezvous start \
  --registry-addr 10.0.1.100:9000 \
  --beacon-addr 10.0.1.100:9001 \
  --persist /var/lib/pilot/registry.json

# Agents connect to YOUR rendezvous, not a public one
pilotctl daemon start \
  --registry 10.0.1.100:9000 \
  --beacon 10.0.1.100:9001

In this deployment, the entire infrastructure is on-premises:

• Rendezvous server: Runs on your hardware, stores only address mappings (no PHI)
• Agent daemons: Run on your hardware, handle PHI processing
• Tunnels: Direct UDP connections between your machines, encrypted end-to-end
• Logs: Stored on your hardware, exported to your SIEM

No data leaves your infrastructure. No third-party service has access to any data, encrypted or otherwise. The registry stores agent addresses and public keys -- metadata that does not constitute PHI. The beacon handles NAT traversal signaling -- also not PHI. All PHI flows through direct encrypted tunnels between agents, which are point-to-point connections on your network.

Multi-site deployment

For healthcare organizations with multiple sites (a hospital network with clinics, a research consortium with partner institutions), Pilot's NAT traversal enables cross-site agent communication without VPN infrastructure:

# Site A: Hospital (behind corporate NAT)
pilotctl daemon start --registry rendezvous.internal:9000
pilotctl join 1

# Site B: Clinic (behind different NAT)
pilotctl daemon start --registry rendezvous.internal:9000
pilotctl join 1

# Agents at Site A and Site B can communicate directly
# NAT traversal is automatic (STUN + hole-punch + relay)
# All traffic is E2E encrypted

What Pilot Does Not Do (And What You Still Need)

Pilot provides the transport layer for HIPAA-compliant agent communication. It does not provide everything needed for a fully compliant healthcare AI system. Here is what you still need:

Business Associate Agreements for your own infrastructure

If your agents run on cloud infrastructure (AWS, GCP, Azure), you need a BAA with your cloud provider for the compute and storage that handles ePHI. Pilot eliminates the need for BAAs with communication intermediaries (no third-party relay, no message queue provider, no API gateway provider), but it does not eliminate BAAs for the infrastructure your agents run on.

De-identification

HIPAA's Safe Harbor method (164.514(b)) requires removing 18 categories of identifiers from data before it can be considered de-identified. If your agents exchange de-identified data, many HIPAA requirements relax. Pilot does not perform de-identification -- that is an application-layer concern. Your agents should de-identify data before transmission when possible.

Data Protection Impact Assessment (DPIA)

GDPR Article 35 requires a DPIA for processing that is "likely to result in a high risk to the rights and freedoms of natural persons." Healthcare AI processing falls squarely in this category. Your DPIA must document the data flows, which Pilot's trust justifications and structured logging support. But the DPIA itself is a document you must write, review, and maintain as your agent architecture evolves.

Application-layer access controls

Pilot's trust model controls which agents can communicate. It does not control what data those agents exchange or what operations they perform on that data. You need application-layer controls for role-based access, data minimization (only sending the minimum PHI necessary for the task), and purpose limitation (ensuring agents only use PHI for the stated purpose).

Breach notification procedures

HIPAA requires notification within 60 days of discovering a breach affecting 500+ individuals (164.408). Pilot's audit logs provide the forensic data needed to assess what was accessed and when, but your organization must have procedures for detection, assessment, and notification.

Getting Started for Healthcare

The minimum viable setup for HIPAA-compliant agent communication:

# 1. Deploy self-hosted rendezvous (on your infrastructure)
pilotctl rendezvous start \
  --registry-addr 0.0.0.0:9000 \
  --beacon-addr 0.0.0.0:9001 \
  --persist /var/lib/pilot/registry.json

# 2. Start agent daemons (on each machine handling PHI)
pilotctl daemon start \
  --registry your-rendezvous.internal:9000 \
  --beacon your-rendezvous.internal:9001
pilotctl join 1

# 3. Establish trust with BAA reference
pilotctl trust request <peer-address> \
  --justification "PHI exchange per BAA #2026-XXXX, purpose: referral processing"

# 4. Enable audit logging to SIEM
pilotctl set-webhook http://localhost:9090/siem-ingest

# 5. Send data over encrypted tunnel
pilotctl send-file <peer-address> patient-summary.json

Every step runs on infrastructure you control. Every data exchange is encrypted end-to-end. Every trust relationship is documented with a justification. Every operation is logged for audit. And no PHI touches any third-party system at any point in the data path.