All posts

HIPAA for AI coding agents: guardrails for code and data access (on GCP)

The organization granted an AI coding agent a service‑account token that could read any Cloud SQL database in a health‑care project. The agent fetched rows containing protected health information (PHI), injected the data into generated code, and pushed the artifact to production without any human review. The organization discovered the breach weeks later, and the audit team struggled to prove who accessed the PHI, when, and what the agent actually did with it. HIPAA’s Security Rule does not pre

Free White Paper

AI Guardrails + AI Code Generation Security: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

The organization granted an AI coding agent a service‑account token that could read any Cloud SQL database in a health‑care project. The agent fetched rows containing protected health information (PHI), injected the data into generated code, and pushed the artifact to production without any human review. The organization discovered the breach weeks later, and the audit team struggled to prove who accessed the PHI, when, and what the agent actually did with it.

HIPAA’s Security Rule does not prescribe a particular technology, but it does require three concrete evidentiary pillars for any system that handles PHI: (1) detailed audit logs that tie every access request to an authenticated identity, (2) safeguards that prevent unauthorized disclosure of PHI, and (3) a documented process that shows privileged actions were approved and can be reproduced. When an AI agent acts as a non‑human identity, those pillars become harder to satisfy because the agent’s code can request credentials, issue queries, and write results without a person signing off on each step.

To comply, an organization must build a control plane that continuously captures evidence, masks PHI before it reaches the agent, and forces just‑in‑time (JIT) approvals for risky operations. The control plane must sit on the data path, between the AI agent and the GCP resource, so that no request can bypass logging, masking, or approval. In other words, the enforcement point must be the gateway that proxies every connection, not an optional library inside the agent’s runtime.

hoop.dev is a Layer‑7 gateway that fulfills exactly that architectural requirement. It runs as a network‑resident service in the same VPC as the target GCP resources and proxies connections to databases, Kubernetes clusters, Cloud Storage, and other supported services. Because the gateway is the only path the AI agent can use, hoop.dev becomes the sole place where enforcement can happen.

How hoop.dev generates HIPAA evidence for AI coding agents

When an AI coding agent initiates a connection, hoop.dev first validates the agent’s OIDC or service‑account token. The identity verification step belongs to the setup layer: it decides *who* the request is, but it does not enforce any policy on its own. Once the token is accepted, the request passes to the gateway.

From that point onward, hoop.dev creates a log entry that records the authenticated identity, timestamp, full request payload, and response status. The entry appears before the request is forwarded, so the system captures every attempt, successful or blocked. Because the gateway sits on the data path, those audit records exist only because hoop.dev intercepts the traffic.

When a response contains PHI, hoop.dev redacts or tokenises the sensitive fields before the data reaches the AI agent, so the agent never sees raw PHI. The masking operation is part of the enforcement outcome; without hoop.dev in the data path, the raw data would flow directly to the agent.

Continue reading? Get the full guide.

AI Guardrails + AI Code Generation Security: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

If the agent attempts a command that could modify or export PHI, such as an INSERT that writes to a protected table or a kubectl exec that runs a script on a pod, hoop.dev pauses the request, sends a notification to an authorized reviewer, and proceeds only after the reviewer grants explicit approval. hoop.dev records the approval decision in the same audit log, providing the documented process HIPAA expects.

All of these enforcement outcomes, session recording, inline masking, JIT approval, and command blocking, are possible only because hoop.dev occupies the gateway position. If the AI agent connected directly to Cloud SQL or GKE, none of these controls would be enforced.

Why continuous evidence matters for HIPAA audits

HIPAA auditors look for a complete, chronological chain of custody for PHI. They ask for logs that show who accessed what, when, and whether the access was authorized. Because hoop.dev writes a log entry for every request, the evidence accumulates continuously rather than being generated retroactively. You can forward the logs to Cloud Logging, SIEM platforms, or another retention system, giving auditors a ready‑to‑use data set.

The logs also capture masking events and approval decisions. When hoop.dev redacts a field, the log notes the field name and the masking rule applied. When a JIT approval is granted, the log records the reviewer’s identity and the justification. These details satisfy HIPAA’s requirement for “record of disclosures” and “access control” without needing separate manual processes.

Setting up the control plane

The setup phase involves configuring an OIDC provider (Google Workspace, Azure AD, etc.) and granting the AI coding agent a minimal service‑account role that allows it to request a token. hoop.dev validates that token and extracts group membership to drive policy decisions. The system stores the actual credentials for the target GCP resources, database passwords, Kubernetes service‑account keys, or Cloud Storage access keys, only in the gateway, so the AI agent never sees them.

After you deploy the gateway (a Docker Compose quick‑start is available), you register each GCP target as a connection in hoop.dev. The registration defines the host, port, and credential reference. From that point, every client, whether a human developer, a CI job, or an autonomous AI agent, must speak to the gateway to reach the resource.

For detailed steps on deployment, identity configuration, and policy authoring, see the getting‑started guide and the broader feature documentation at hoop.dev/learn. Those pages walk you through installing the gateway, connecting to Cloud SQL, enabling masking rules for PHI columns, and configuring approval workflows.

FAQ

  • How does hoop.dev help me produce audit logs that satisfy HIPAA? hoop.dev records every request and response in an audit log that includes the authenticated identity, timestamp, command, and outcome. Because the gateway is the only path to the resource, no access can escape logging.
  • Does hoop.dev encrypt the data it masks? hoop.dev masks sensitive fields before the data reaches the AI agent, ensuring the agent never sees raw PHI. Encryption of data at rest or in transit is handled by the underlying GCP services; hoop.dev focuses on masking, logging, and approval.
  • Can I use hoop.dev with existing CI pipelines that run AI‑generated code? Yes. The pipeline simply points its database or kubectl client to the hoop.dev endpoint. No code changes are required; the gateway intercepts the traffic, applies policies, and returns the result.

By placing a Layer‑7 gateway in front of GCP resources, hoop.dev creates the continuous, verifiable evidence that HIPAA auditors require while preventing unauthorized exposure of PHI to AI coding agents.

Explore the open‑source repository and start building your HIPAA‑compliant AI workflow: https://github.com/hoophq/hoop.

Open source

Save the open-source gateway for agent data access

Hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.

Star and save the repo →More posts