A newly hired data‑science contractor writes a function that forwards raw patient notes to a large‑language‑model API for summarization. The code runs in a CI pipeline, automatically invoking the function whenever a new file lands in a bucket. No one looks at the payload, no audit trail exists, and the raw notes contain protected health information (PHI). The organization now faces a compliance breach the moment the pipeline processes a single record.
Why phi matters for function calling
Regulators define phi as any individually identifiable health information that is created, received, stored, or transmitted by a covered entity. When phi travels through a function‑calling interface, it can be logged, cached, or inadvertently exposed in error messages. A breach can trigger hefty fines, loss of trust, and mandatory remediation. The risk is not theoretical; many teams treat function calls like ordinary API requests and rely solely on network firewalls or token scopes.
In practice, developers often grant a service account broad permissions, embed the account’s secret in CI scripts, and let the function call flow unchecked to the downstream model. The result is a blind spot: the identity system knows who can start the request, but nothing monitors what data actually moves across the wire.
The missing control plane
Identity and token provisioning (OIDC, SAML, service‑account roles) answer the question “who may invoke the function?” They do not answer “what data is being sent?” or “has the request been approved?” Without a data‑path enforcement layer, phi can be transmitted, stored, or logged without any real‑time protection. The setup alone cannot enforce inline masking, command‑level audit, or just‑in‑time approval.
hoop.dev as a data‑path gateway for function calls
hoop.dev provides the missing layer by sitting between the caller and the target function endpoint. It authenticates the user or service via OIDC/SAML, then inspects each request at the protocol level. Because hoop.dev is the only place the traffic passes, it can:
- Mask phi fields in responses before they reach the caller.
- Record every function‑call session for replay and audit.
- Require a human approval step when a request contains phi or other high‑risk payloads.
- Block commands that match a deny list, preventing accidental data exfiltration.
All of these outcomes exist because hoop.dev sits in the data path. The identity system merely decides who can start a request; hoop.dev enforces the policy, logs the interaction, and applies real‑time masking.
Practical steps to protect phi in function calling
1. Identify phi fields. Create a schema that lists the attributes that constitute phi (e.g., patient name, medical record number, diagnosis). This schema drives masking rules in hoop.dev.
2. Deploy hoop.dev near the function endpoint. Use the quick‑start guide to run the gateway as a Docker Compose service or in Kubernetes. The gateway holds the target credentials, so callers never see them.