Many teams assume that encrypting PHI in transit between services automatically satisfies compliance for application‑to‑application (A2A) integrations. In reality, regulators expect concrete evidence that each access to PHI is authorized, recorded, and can be reviewed without exposing the data itself.
A typical A2A flow involves one service calling another over a standard protocol, PostgreSQL, HTTP, SSH, or gRPC, using a static credential that is shared across many jobs. The calling service authenticates once, then the connection persists for hours or days. Because the traffic travels directly from the client to the target, the infrastructure rarely sees who issued each query, what PHI was returned, or whether the request complied with policy.
During an audit, reviewers ask for three categories of artifacts:
- Who accessed PHI, when, and from which identity.
- What data was returned, with any sensitive fields redacted in logs.
- Evidence of any human approval or automated guardrails that prevented unauthorized reads.
Most organizations cannot provide these items because their existing setup lacks a single control point that can observe, modify, and record the traffic. Shared service accounts blur accountability, raw logs dump full PHI payloads, and there is no workflow to pause a risky request for manual review.
Regulatory guidance therefore recommends a data‑path enforcement layer that can:
- Capture every request and response with identity metadata.
- Mask or redact PHI fields before they are written to log storage.
- Require just‑in‑time (JIT) approvals for privileged queries.
- Block commands that violate policy before they reach the backend.
That is exactly the problem hoop.dev solves. hoop.dev is an open‑source Layer 7 gateway that sits between identities and the A2A target. It validates OIDC or SAML tokens, extracts the user’s groups, and then proxies the connection to the underlying service. Because all traffic must pass through hoop.dev, it is the only place where enforcement can happen.
When a request flows through hoop.dev, the gateway records a session record that includes the user’s identifier, the exact command, a timestamp, and metadata about the target. Before the response is stored, hoop.dev applies inline data masking so that any PHI fields are replaced with placeholders, ensuring that log archives never contain raw patient data. If the request matches a policy that requires approval, such as a query that extracts a full medical record, hoop.dev routes the operation to a human reviewer and only forwards it after an explicit “allow” decision is logged.
Because hoop.dev is the sole data‑path component, it can also enforce just‑in‑time access. A user who normally does not have permission to read PHI can be granted a temporary role for a single session, and hoop.dev will automatically revoke that privilege when the connection closes. This approach satisfies the “least privilege” principle while still providing the evidence auditors need.
Deploying hoop.dev is straightforward. The quick‑start guide walks you through a Docker Compose deployment that brings up the gateway and a network‑resident agent next to your database or API. Once the agent is running, you register the target connection in the hoop.dev console, point your client at the gateway address, and let hoop.dev handle authentication, masking, and logging. Detailed instructions are available in the getting‑started documentation, and the learn section explains each feature in depth.
By placing enforcement at the gateway, hoop.dev generates the exact audit evidence required for PHI compliance without requiring changes to your existing services. The recorded sessions, masked logs, and approval trails give auditors a clear, verifiable view of who accessed what, while the underlying services remain untouched.
Explore the source code, contribute improvements, and see how the community is building compliance‑ready A2A pipelines at https://github.com/hoophq/hoop.
FAQ
What evidence does hoop.dev provide for a PHI audit?
hoop.dev creates a per‑session log that records the user identity, timestamp, command, and a masked version of the response. It also stores any approval decisions and can replay the entire session for forensic review.
Does hoop.dev replace my existing IAM policies?
No. IAM decides whether a request can start. hoop.dev sits in the data path and enforces additional controls, masking, approvals, and command blocking, once the request is underway.
Can I adopt hoop.dev without rewriting my services?
Yes. hoop.dev proxies standard protocols, so your applications continue to use their usual client libraries. The only change is the endpoint address, which points to the gateway instead of the direct target.
