How can you ensure the Claude Agent SDK respects your organization’s policy as code without exposing secrets?
Most teams hand the SDK a static API key and let it call Claude directly. The key lives in source code, CI pipelines, or developer laptops. There is no runtime gate that checks whether a prompt complies with internal data‑handling rules, and there is no audit trail that shows which prompts were sent or what responses were returned. When a developer accidentally includes a customer’s personal identifier in a prompt, the request sails straight to Claude’s service, the response is streamed back, and the organization has no evidence of the breach.
This unsanitized state is common because the SDK is designed for convenience. It authenticates with a bearer token, opens an HTTPS connection, and returns JSON. The surrounding application code rarely adds a policy‑evaluation layer, and the SDK itself has no built‑in mechanism to enforce “policy as code”. The result is a blind spot: the request reaches the LLM service directly, with no inline masking, no just‑in‑time approval, and no record of what was asked.
What you need is a way to declare the allowed prompt patterns, required redactions, and approval workflows as code, and to have those rules applied automatically every time the SDK talks to Claude. Policy as code can define forbidden keywords, maximum token lengths, and mandatory sanitization of PII. However, even with a policy file in place, the SDK still initiates the connection itself. The request bypasses any enforcement point, meaning the policy never gets enforced, the response is never masked, and there is still no immutable log of the interaction.
Enter hoop.dev. hoop.dev acts as an identity‑aware proxy that sits in the data path between the Claude Agent SDK and the Claude service. By routing all SDK traffic through hoop.dev, you move the enforcement surface out of the client process and into a controlled gateway. hoop.dev validates each request against your policy as code, blocks disallowed prompts, applies real‑time masking to any response that contains sensitive data, and records the full session for replay and audit.
Setup: identity and least‑privilege grants
The first step is to configure an OIDC or SAML identity provider that issues short‑lived tokens for developers and automated agents. These tokens identify who is making the request and what groups they belong to. hoop.dev consumes the token, extracts group membership, and maps it to the policy definitions you have authored. Because the token is short‑lived and scoped, the risk of credential leakage is reduced.
The data path: hoop.dev as the enforcement gateway
When the Claude Agent SDK sends an HTTP request, it is directed to the hoop.dev endpoint instead of Claude’s public API. hoop.dev terminates the TLS connection, inspects the request payload, and evaluates it against the declared policy as code. If the prompt contains a prohibited phrase or exceeds a token limit, hoop.dev rejects the request before it ever reaches Claude. If the request passes, hoop.dev forwards it to Claude, receives the response, and applies any inline masking rules, such as redacting email addresses or credit‑card numbers, before returning the result to the SDK.