Sending raw personal data to a language model is a compliance nightmare waiting to happen, especially without proper pii redaction.
Most teams that adopt the OpenAI Agents SDK simply pass user prompts straight through to the model. The SDK makes it easy to stitch together tools, retrieve context, and generate responses, but it does not filter out names, email addresses, or phone numbers. In practice, developers rely on ad‑hoc string replacements or on the assumption that the model will not retain the data unless explicitly disabled. Both assumptions are false: the model receives exactly what the client sends, and the provider retains the payload for debugging and improvement unless explicitly disabled.
Because the SDK runs inside the same process that constructs the prompt, any client‑side redaction can be bypassed by a bug, a new version of a library, or an unexpected data path such as a background worker. Moreover, without a central audit point, you cannot prove to auditors that PII never left your perimeter, nor can you retroactively scrub a transcript that was already sent.
What you really need is a trustworthy choke point that sees every request before it reaches OpenAI, strips out or masks sensitive fields, and records the interaction for later review. The choke point must be independent of the application code, must operate at the protocol level, and must be able to enforce policies in real time.
Key considerations for pii redaction
1. Location of enforcement. The redaction engine must sit on the data path, not inside the application. This guarantees that even a compromised service cannot skip the check.
2. Identity‑driven policy. Access decisions should be tied to the caller’s identity, which is usually provided by an OIDC or SAML token. By reading group membership, you can apply different redaction rules for developers, support staff, or automated agents.
3. Inline masking. Rather than rejecting the entire request, the gateway can replace PII with placeholders such as [REDACTED_EMAIL] so the model still receives a well‑formed prompt.
4. Auditability. Every session should be recorded, with the original payload (pre‑redaction) stored securely for forensic analysis. This evidence is essential for GDPR, SOC 2, or internal policy reviews.
5. Just‑in‑time approval. For especially sensitive queries, the gateway can pause the request and require a human reviewer to approve the redacted version before it proceeds.
How hoop.dev provides the missing data‑path control
hoop.dev is a layer‑7 gateway that sits between the OpenAI Agents SDK and the OpenAI endpoint. It acts as a proxy for the HTTP calls the SDK makes, inspecting the request body, applying redaction rules, and then forwarding the sanitized payload. Because hoop.dev runs as a separate network‑resident agent, the SDK never sees the raw credentials or the unredacted data.
Setup. Identity is handled via OIDC or SAML. You configure hoop.dev to trust your identity provider (Okta, Azure AD, Google Workspace, etc.). Tokens presented by the SDK are validated, and group claims are extracted to drive per‑user redaction policies. This step decides who is making the request, but it does not enforce any data transformation on its own.
Data path enforcement. All HTTP traffic from the SDK passes through hoop.dev’s gateway. The gateway parses the JSON payload, runs a configurable set of pattern‑matching rules, and replaces any detected PII with safe placeholders. Because the transformation happens at the protocol layer, the SDK cannot bypass it, and the OpenAI service never receives raw personal data.
Enforcement outcomes. hoop.dev records each session, storing the original request (pre‑redaction) and the redacted version. It can also trigger a just‑in‑time approval workflow if a request contains high‑risk data, and it can replay the session for audit purposes. All of these outcomes exist only because hoop.dev occupies the data path.
Getting started quickly
To protect your OpenAI Agents integrations, start by deploying the hoop.dev gateway using the Docker Compose quick‑start. The compose file pulls the latest open‑source image, sets up OIDC validation, and enables masking out of the box. After the gateway is running, register the OpenAI endpoint as a connection in hoop.dev’s configuration, and point your SDK’s base URL to the gateway address.
Full step‑by‑step instructions are available in the getting‑started guide. The guide walks you through identity provider configuration, connection registration, and rule definition for PII patterns. For deeper technical details, the learn section explains how masking, approval workflows, and session replay work under the hood.
All of the code that runs the gateway is open source. You can review, extend, or self‑host the project from the GitHub repository: Explore the source on GitHub.
FAQ
- Does hoop.dev store the original, unredacted data? Yes, it stores the pre‑redaction payload in a secure store that is separate from the gateway process. Access to that store is gated by the same identity checks that govern the gateway.
- Can I use hoop.dev with other LLM providers? The gateway works at the HTTP layer, so any provider that speaks a compatible API can be proxied. You only need to register the target endpoint and define appropriate redaction rules.
- What if a new type of PII appears? You can update the pattern rules in hoop.dev without touching the SDK code. The next request will be processed with the new rule set automatically.
