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 is in scope. That includes the transport layer, any relay infrastructure, logging systems, and error handling. A single unencrypted hop, a single log entry containing PHI in plaintext, or a single third-party system without a Business Associate Agreement where one is required can be enough to put a deployment out of compliance.

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 harder. An agent that decides on its own 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 a registry and a beacon handle discovery and NAT traversal. When no direct path works, traffic is relayed through the beacon. That adds an intermediary to the data path: on the public backbone the beacon is run by Vulture Labs, and in a self-hosted deployment it is yours. 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).
• Nonce prefix and counter: Each time a tunnel key is derived for a peer, the daemon picks a random 4-byte nonce prefix, then counts up from it. The receiver rejects counters it has already seen.
• Ed25519 identity signing: Trust handshakes are signed with the agent's persistent Ed25519 key, so the peer you establish a session with is the peer you intended to trust.

The tunnel encryption uses Go's standard library (crypto/ecdh, crypto/aes, crypto/cipher, crypto/ed25519), with no third-party crypto library to review. 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 network-level access control. By default, an agent cannot exchange messages with another agent until a trust handshake between them has been approved. Some requests are approved without a person: when both sides request trust, when they share a network, when the daemon runs with --trust-auto-approve, or when the requester is on the daemon's built-in trusted-agents list. Decide on each of these before PHI is involved.

Handshake as an authorization step

The trust handshake is a two-party protocol. Agent A sends Agent B a request with an optional justification, a free-text note. Agent B's operator approves or rejects it. This is a technical authorization step. It is not a substitute for legal consent, minimum-necessary policy, or application-level authorization:

# Hospital agent asks the specialist agent for trust
pilotctl handshake <specialist-address> "Referral summaries for radiology review"

# On the specialist's machine: list requests (node ID, justification, time received)
pilotctl pending

# Specialist approves
pilotctl approve <hospital-address>

The justification is a note for the person approving, capped at 1,024 bytes. It is not covered by the request's signature, which binds only the two node IDs. The receiving daemon keeps it in the pending queue, writes it to its log, and, for requests that arrive directly, includes it in the handshake.received and handshake.pending webhook events. Approving or rejecting the request removes it from the queue, and the trust record an approval creates keeps the peer's node ID, public key and approval time, not the justification. When the direct path fails, the request is relayed through the registry, which holds the justification until the peer collects it.

So keep PHI and contract details out of the justification. If you need a record of why access was granted, keep it in your own system of record, for example by storing the webhook event when the request arrives.

Revocation as instant de-authorization

When a BAA expires, a physician leaves a practice, or a collaboration ends, revoke trust:

# Revoke trust with a node
pilotctl untrust <peer-address>

# What the daemon does:
# - removes the trust record and tears down the tunnel to that node
# - sends the node a revocation notice (best effort)
# - asks the registry to remove the trust pair, so it stops resolving your endpoint for that node
# - blocks messages to and from that node until a new handshake is completed

Certificate-based access control depends on CRL distribution or OCSP checks for revocation. Pilot's revocation takes effect on your daemon when the command runs. It does not wait for the 25-second tunnel keepalive or the 60-second registry heartbeat.

Private by default

Pilot withholds an agent’s reachable endpoint and connectivity from untrusted peers by default; a daemon is only publicly visible when started with --public. 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, which your risk analysis would then have to account for.

Audit Trails: What the Daemon and Registry Record

HIPAA's audit controls standard (164.312(b)) asks for mechanisms that record and examine activity in systems that contain or use ePHI. Pilot records network and trust activity, not what your applications do with the data. There are three sources, and they live in different places.

Daemon log

Each daemon writes a structured log with Go's log/slog package to ~/.pilot/pilot.log on its own machine. Start the daemon with --log-format json to get one JSON object per line for a log shipper. At the default info level the log records trust changes (handshake requests with their justification, approvals, rejections and revocations) and tunnel path changes, such as a switch to relay.

Webhook events for SIEM integration

The daemon can POST its events as JSON to an HTTP(S) endpoint you choose. Each event carries event_id, event, node_id, timestamp and data:

# Send this daemon's events to your SIEM collector
pilotctl set-webhook http://localhost:9090/siem-ingest

# Events include:
# - handshake.pending, handshake.approved, handshake.rejected, trust.revoked
# - conn.established, conn.fin, conn.rst
# - data.datagram, file.delivered
# - node.registered, key.rotated, tunnel.*, security.*

Delivery is best effort. The daemon queues up to 1,024 events, tries each POST up to three times, and drops events when the queue is full, so treat the webhook as a feed into your SIEM, not as the audit record itself. Link-local and cloud-metadata addresses are refused, but any other target is accepted, including remote hosts. Point it at a collector on your own infrastructure.

Registry audit log, on a registry you run

The registry keeps its own audit log of registry changes, among them node registrations, trust pairs created and revoked, relayed handshakes, network joins and key rotations. It is a 1,000-entry hash-chained buffer that can also be exported to Splunk HEC, syslog/CEF or a JSON endpoint. Reading it (pilotctl extras audit) and configuring export (pilotctl extras audit-export set) take the registry admin token. On the public backbone only Vulture Labs holds that token, so this log is only yours if you run your own registry.

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.

# On each machine handling PHI: use the registry and beacon you run
export PILOT_REGISTRY=registry.example.com:9000
export PILOT_BEACON=registry.example.com:9001
pilotctl daemon start --log-format json

In this deployment:

• Agent daemons: Run on your hardware, handle PHI processing
• Tunnels: Direct UDP connections between your machines when a direct path works, relayed through the beacon as ciphertext when it does not
• Registry and beacon: Run by you, so registry metadata and relayed traffic stay on your infrastructure
• Logs: Stored on your hardware; you ship them 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.

On the public backbone, the registry and beacon are run by Vulture Labs. The registry holds each node's ID, public key, network addresses, hostname and email if you set them, which nodes trust each other, and relayed handshake requests with their justification. When a direct path fails, the beacon relays the tunnel traffic as ciphertext. Vulture Labs offers no BAA for any of this. To keep that metadata and relayed traffic on infrastructure you control, run your own registry and beacon.

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) and Site B (clinic), each behind its own NAT,
# with PILOT_REGISTRY and PILOT_BEACON set to your registry and beacon
pilotctl daemon start --hostname hospital-a-agent
pilotctl daemon start --hostname clinic-b-agent

# Site A asks Site B for trust; Site B approves (addresses from pilotctl info)
pilotctl handshake <clinic-b-address> "Referral summaries"
pilotctl approve <hospital-a-address>

# NAT traversal is automatic (STUN + hole-punch + relay)
# All tunnel 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. Vulture Labs offers no BAA, for the public backbone or anything else, so if registry metadata or relayed traffic needs to be covered, run your own registry and beacon. 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. Daemon logs, webhook events and, on a registry you run, the registry audit log can feed that documentation, 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 logs and events can show which nodes connected, and when, but not which PHI an application read. Your organization must have procedures for detection, assessment, and notification.

Getting Started for Healthcare

A starting point for a healthcare-oriented test deployment:

# 1. Run your own registry and beacon (see /self-hosting/), then on each machine:
export PILOT_REGISTRY=registry.example.com:9000
export PILOT_BEACON=registry.example.com:9001
pilotctl daemon start --log-format json

# 2. Request trust with a short note that contains no PHI
pilotctl handshake <peer-address> "Referral processing"

# 3. On the peer: review and approve
pilotctl pending
pilotctl approve <your-address>

# 4. Send this daemon's events to your SIEM collector
pilotctl set-webhook http://localhost:9090/siem-ingest

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

This setup gives you encrypted transport, an approved trust relationship, and network and trust 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.