Technical Controls for Healthcare AI Agent Communication

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 question is contractual scope. A Business Associate Agreement may be needed when a covered entity shares PHI with a service provider, and provider coverage varies by product and plan. Teams need to verify which processing, transport, logging, support, and subprocessors are covered before sending PHI.

Some providers offer BAA-covered services, but scope varies. If an agent sends PHI through an API gateway, load balancer, inference service, observability system, or support workflow, review how each component is covered. This is the same transport challenge that cross-company agent collaboration faces: agents on different infrastructure need a secure channel with a documented data path.

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: Minimize Intermediaries in the Data Path

Pilot Protocol is a peer-to-peer overlay network. It prefers direct encrypted UDP tunnels, while coordination services handle discovery and NAT traversal. When direct connectivity is unavailable, encrypted relay fallback can add a Pilot-operated intermediary to the data path; the relay forwards ciphertext and does not hold the tunnel key.

This architecture can reduce the number of systems that handle plaintext. On a direct path, application data moves between the two endpoints without an application broker. Teams still need to account for endpoint software, optional relay paths, app services, logs, backups, and every other component in their own data-flow and vendor review.

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 handles address resolution, not application payloads
# The beacon handles NAT signaling and may relay ciphertext
# Even relay mode: beacon sees only encrypted ciphertext

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

Pilot tunnel encryption is enabled by default across ports. Port 443 is a secure-service convention, not a distinct second cryptographic layer in the current SDK. The encryption stack uses:

• X25519 key exchange: Each daemon generates a key pair at startup and derives a distinct tunnel secret with each peer. This provides peer isolation; the current daemon-lifetime key design does not provide per-session forward secrecy.
• 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). For a broader overview of encrypted tunnel advantages for P2P AI networks, including the security and performance trade-offs of different tunnel architectures, see the dedicated comparison.

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 approves or rejects it. This can support a technical authorization workflow, but it is not a substitute for legal consent, minimum-necessary policy, or application-level authorization:

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

# Specialist agent reviews
pilotctl 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 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 untrust 1:0001.0000.0042

# Effect is instant:
# - Active connections are terminated
# - The revoked agent cannot reconnect
# - The revoked peer no longer receives your endpoint through this trust grant
# - 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

Pilot withholds an agent’s reachable endpoint and connectivity from untrusted peers by default. Some directory metadata, tags, or network membership may remain visible depending on configuration, and shared-network membership can grant connectivity. Treat metadata exposure and network join rules as explicit design decisions for healthcare deployments.

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":"node.registered","peer":"1:0001.0000.0042","hostname":"referral-agent"}
{"time":"2026-02-28T10:15:04Z","level":"INFO","msg":"conn.established","peer":"1:0001.0000.0042","port":443,"encrypted":true}
{"time":"2026-02-28T10:15:05Z","level":"INFO","msg":"data.datagram","peer":"1:0001.0000.0042","port":1001,"bytes":4096}
{"time":"2026-02-28T10:15:30Z","level":"INFO","msg":"conn.fin","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:
# - node.registered, agent.registered, agent.heartbeat
# - conn.established, conn.fin, conn.rst
# - data.datagram, file.delivered
# - key.rotated, tunnel.*, security.*

The webhook can push to any HTTP/HTTPS endpoint you configure — point it at a local server (as above) to keep audit data on your infrastructure. Cloud-metadata addresses are blocked, but nothing forces the target to be localhost, so choose the endpoint deliberately.

Architecture: Encrypted Tunnels + Trust-Gated Access

Pilot Protocol prefers direct encrypted tunnels between agents. Coordination infrastructure handles address resolution and NAT traversal, and an encrypted relay path may be used when direct connectivity fails. Applications layered on Pilot can also introduce their own service providers.

# Start agent daemons on each machine handling PHI
pilotctl daemon start --email clinician@hospital.example.com
pilotctl network join 1

In this deployment:

• 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

On a direct path, plaintext stays at the endpoints and the network transports ciphertext. On a relay path, the relay handles ciphertext and connection metadata. Your risk analysis should classify that metadata and document both paths rather than assuming it cannot be sensitive.

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 --email agent@hospital-a.example.com
pilotctl network join 1

# Site B: Clinic (behind different NAT)
pilotctl daemon start --email agent@clinic-b.example.com
pilotctl network 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 transport controls that can support a healthcare deployment. It does not make an agent system compliant on its own. Here is what you still need:

Business Associate Agreements for your own infrastructure

If agents run on cloud infrastructure, review whether a BAA and related contractual controls are required for the compute, storage, observability, support, and relay services in scope. Pilot can reduce intermediary plaintext access, but it does not decide which vendors or paths require contractual coverage.

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

A starting point for a healthcare-oriented test deployment:

# 1. Start agent daemons (on each machine handling PHI)
pilotctl daemon start --email agent@hospital.example.com
pilotctl network join 1

# 3. Establish trust with BAA reference
pilotctl handshake <peer-address> "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

This setup gives you encrypted transport, a documented trust relationship, and network/security events to integrate with your audit process. Before using PHI, validate direct and relay paths, endpoint logging, app dependencies, retention, incident response, and contractual scope.