How can you reliably enforce policy as code when developers embed Claude skills directly in their applications?
Most teams treat Claude as a simple API endpoint: a shared key lives in a config file, a prompt is hard‑coded, and every request bypasses any review process. The result is a landscape where any engineer can invoke a skill that extracts, transforms, or even writes data without visibility. Secrets leak, prompts evolve unchecked, and compliance evidence is missing because nothing records who asked what and when.
That reality is dangerous for two reasons. First, Claude can generate or expose sensitive information on demand, so unrestricted access creates a data‑exfiltration vector. Second, without a central guardrail, policy drift is inevitable – one team may start allowing broader queries while another still follows a restrictive baseline. The organization ends up with a patchwork of informal rules that no audit can verify.
Why policy as code alone isn’t enough
Introducing policy as code means you write declarative rules that describe allowed prompts, required approvals, and fields that must be masked. The intention is clear: the system should reject a request that violates a rule before it reaches Claude. In practice, however, the request still travels straight to the Claude endpoint. No component on that path inspects the payload, so the rule never gets enforced, no approval step occurs, and no audit record is created. The setup defines who may ask, but it does not control what actually happens once the request leaves the client.
In other words, the setup – identity providers, OIDC tokens, service accounts – decides who can start a session, but without a gateway that sits in the data path, the session proceeds unchecked. The missing piece is a place where the policy can be evaluated, where sensitive fields can be redacted, and where a replay‑able log can be stored.
hoop.dev as the data‑path enforcement point
Enter hoop.dev. It is a Layer 7 gateway that sits between callers and Claude’s skill endpoint. By routing every request through hoop.dev, you place the policy engine exactly where it can see the full request and response. hoop.dev validates each prompt against your policy as code definitions, blocks disallowed patterns, and can trigger a just‑in‑time approval workflow before the request is forwarded.
Because hoop.dev is the only component that touches the traffic, it also performs the enforcement outcomes that matter:
- Inline masking – hoop.dev removes or redacts PII from Claude’s replies according to the policy.
- Command blocking – any prompt that matches a prohibited pattern is rejected before Claude sees it.
- Just‑in‑time approval – high‑risk requests are paused and routed to an approver, then only forwarded on explicit consent.
- Session recording – hoop.dev captures the full request/response exchange, enabling replay for forensic analysis.
- Audit trail – each session is logged with identity, timestamp, and policy decision, giving you evidence for compliance.
All of these outcomes exist only because hoop.dev occupies the data path. Remove hoop.dev and the same identity tokens would still reach Claude, but none of the masking, approval, or recording would happen.
How the pieces fit together
The architecture follows three clear layers:
- Setup: Users authenticate via OIDC or SAML. Tokens convey group membership that hoop.dev uses to map a caller to a policy profile.
- The data path: hoop.dev receives the HTTP request, parses the Claude payload, and applies the policy engine.
- Enforcement outcomes: Based on the policy decision, hoop.dev may mask data, require approval, block the request, or simply forward it while recording the exchange.
This separation ensures that no downstream component can bypass the controls. Even if a developer has direct network access to the Claude service, the organization’s network topology should route all traffic through the gateway, making hoop.dev the single point of truth for policy enforcement.
Getting started with policy as code for Claude
To try this approach, start with the getting‑started guide. It walks you through deploying the gateway, configuring OIDC, and defining a simple policy that blocks prompts containing the word “delete”. The learn section expands on advanced features such as dynamic masking rules and approval workflows.
Because hoop.dev is open source, you can inspect the policy engine, extend it with custom checks, or contribute improvements back to the community.
FAQ
Can I enforce policy as code without a gateway?
No. Without a data‑path component, the policy never sees the request, so enforcement outcomes like masking or approval cannot be guaranteed.
Does hoop.dev add noticeable latency to Claude calls?
hoop.dev processes traffic at the protocol layer and is designed for low overhead. In most environments the added latency is measured in milliseconds, which is negligible compared to the round‑trip time of the Claude service itself.
Where are the Claude credentials stored?
hoop.dev holds the credentials in its internal store. Agents and callers never see the raw secret, reducing the risk of credential leakage.
Explore the source and contribute on GitHub.
