Many assume that attaching a static OpenAI API key to an agent is enough to control what the model can do, but that ignores the need for fine‑grained iam. In reality, a single secret gives every instance of the SDK unrestricted access to the same endpoints, and any compromise of that secret instantly grants full privileges.
How teams typically expose the OpenAI Agents SDK today
Most early adopters embed the API key directly in code or environment files that are checked into version control. The key is then shared across development, staging, and production environments. Engineers copy the same secret between machines, and CI pipelines reuse it for automated runs. Because the key is static, there is no record of which run actually invoked the model, no way to revoke a single usage, and no audit trail that ties a request back to a specific identity.
This pattern creates three concrete risks. First, credential sprawl makes rotation painful and often ignored. Second, any compromised host can issue unlimited requests, inflating costs and exposing data. Third, the lack of per‑request visibility means security and compliance teams cannot answer who asked the model to generate a particular output.
The missing piece: iam that still reaches the OpenAI endpoint directly
What many teams need is a way to bind each request to an identity and enforce policies such as rate limits, content filters, or approval workflows. The natural idea is to introduce an iam layer that checks a token before the SDK calls the OpenAI service. However, most implementations place that check in the application code itself. The request still travels straight from the SDK to the OpenAI API, bypassing any central enforcement point. As a result, the iam check can be disabled, bypassed, or simply not applied to background jobs that use the same library.
In this state, the iam system decides whether a request may start, but it does not control the actual data path. The request reaches the target without a gate that can log, mask, or block the payload. Without a gateway, there is no guarantee that every call will be recorded, that sensitive user data in the prompt will be redacted, or that a privileged operation will require an explicit approval step.
Why the data path must host enforcement
Enforcement outcomes, such as per‑request logging, inline masking of personally identifiable information, just‑in‑time approval, and session replay, can only be guaranteed when they occur on the network path that carries the request. If the gateway sits between the SDK and the OpenAI service, it becomes the single point that can inspect the wire‑level protocol, apply policies, and produce immutable evidence of each interaction.
hoop.dev fulfills that role. It acts as a Layer 7 identity‑aware proxy that terminates the SDK’s outbound connection, validates the caller’s oidc token, and then forwards the request to OpenAI on behalf of the agent. Because hoop.dev is the only component that sees the raw request and response, it can record every session, mask sensitive fields in real time, and enforce just‑in‑time approvals before the payload leaves the gateway.
When a request arrives, hoop.dev checks the caller’s groups, applies any configured masking rules, and, if required, pauses the flow for a manual approval. Only after those checks does it forward the request to the OpenAI endpoint using its own credential. The original SDK never sees the credential, and the organization retains a complete audit trail that ties each model invocation to a specific user and policy decision.
hoop.dev records each session, producing a tamper‑evident audit log that can be used to satisfy internal governance and external audit requirements.
How to wire the OpenAI Agents SDK through hoop.dev
The setup begins with a standard oidc identity provider such as Okta, Azure AD, or Google Workspace. Engineers obtain short‑lived tokens that represent their user identity. hoop.dev is configured as a relying party, meaning it validates those tokens and extracts group membership for policy evaluation. The gateway is deployed as a Docker container or a Kubernetes pod, close to the network where the SDK runs.
Next, a connection definition for the OpenAI service is created inside hoop.dev. The definition stores the service credential that the gateway will use when forwarding requests. Because the credential lives inside the gateway, developers never embed it in code. The SDK is pointed at the gateway’s local address instead of the public OpenAI endpoint, and all traffic automatically passes through the data path.
From an iam perspective, the essential controls are now enforced at the gateway. hoop.dev logs the interaction and provides a tamper‑evident audit trail that can be used to satisfy internal governance and external audit requirements. It also applies masking rules to prompts that contain PII and can require an approver to sign off on high‑cost or high‑risk model calls.
Practical steps to get started
- Read the getting started guide to deploy the gateway in your environment.
- Review the learn section for detailed explanations of iam policies, masking, and approval workflows.
- Configure your OpenAI Agents SDK to connect to the local gateway endpoint instead of the public API.
- Define iam groups and mapping rules in your identity provider so that hoop.dev can make authorization decisions.
- Test the end‑to‑end flow and verify that each request appears in the audit console.
By moving the enforcement point into the data path, organizations gain visibility, control, and compliance without changing the SDK’s programming model.
View the hoop.dev source on GitHub to explore the implementation details and contribute improvements.
