How can you prevent Claude from exposing proprietary code or secrets when it runs inside your CI/CD pipeline? Data masking ensures that any sensitive value is hidden before the model sees it.
In many organizations, engineers invoke Claude directly from build jobs, passing entire source trees, configuration files, and environment variables as part of the prompt. The connection is a simple HTTPS call to the public Claude endpoint. No gateway sits in front of the request, so the model receives raw API keys, database passwords, and internal URLs. Those values can appear in Claude’s response, in logs, or in any downstream artifact, creating a permanent source of leakage. There is also no central record of who sent which prompt, what data was included, or what the model returned.
To address authentication, teams often configure their CI system to obtain short‑lived OIDC tokens from an identity provider such as Okta or Azure AD. The token proves which service account is making the request, and group membership can be used to decide who is allowed to call Claude. However, the token alone does not enforce any protection on the payload; the request still travels straight to Claude with all secrets intact.
This unsanitized state is the precondition we must fix: we have identity verification, but the data path remains open, and there is no audit of what was sent or received. The missing piece is a gateway that can inspect, mask, and record each interaction while still honoring the OIDC‑based identity check.
Why data masking matters for AI coding agents
Claude, like other generative AI services, processes every token it receives. Even if the model does not intentionally leak the content, downstream logs, caches, or debugging output can inadvertently capture it. Data masking replaces any field identified as a secret, environment variables, private keys, or customer identifiers, with a placeholder before the payload reaches the model.
Masking also reduces the attack surface for insider threats. An engineer with access to the CI system might try to extract secrets by crafting a prompt that forces the model to echo back the hidden value. If the gateway replaces the secret with asterisks or a hash, the model never sees the original, and the engineer cannot retrieve it.
Architectural pattern for secure AI integration
The pattern consists of three layers:
- Setup layer: Identity providers issue short‑lived OIDC tokens to CI jobs. The token authenticates the request and conveys group membership, but on its own it does not enforce masking.
- Data‑path layer: A Layer 7 gateway intercepts the HTTPS request, parses the JSON payload, applies masking rules, forwards the sanitized request to Claude, and then returns the model’s response to the CI job.
- Enforcement outcomes: The gateway records each session for audit, stores the masked request and response for replay, and can trigger just‑in‑time approval if a request contains a high‑risk operation.
This separation guarantees that the only component that ever sees the raw secret is the CI runner itself; the gateway never exposes it to the AI service.
Implementing the pattern with hoop.dev
hoop.dev provides the data‑path layer described above. It runs a network‑resident agent next to your CI runners and acts as an identity‑aware proxy for Claude. When a CI job presents a valid OIDC token, hoop.dev validates the token, extracts the user’s groups, and selects the appropriate masking policy. The request payload is inspected in real time; any field that matches a configured secret pattern is replaced with a safe placeholder before the request is sent to Claude’s endpoint. The response follows the same path, allowing hoop.dev to mask any sensitive data that Claude might return.
Because hoop.dev sits in the data path, it also records each session, creating an audit log that security teams can review. The gateway can trigger a just‑in‑time approval workflow if a request tries to access a protected resource, ensuring that no privileged operation proceeds without explicit consent.
All of this happens without changing the CI job’s code. The job simply points its Claude client at the hoop.dev endpoint, just as it would point at the public Claude API. hoop.dev handles credential storage, masking, and logging behind the scenes.
For a step‑by‑step guide on deploying hoop.dev in a container environment, see the getting started guide. The feature documentation provides deeper detail on configuring masking rules, approval workflows, and session replay.
Key considerations when masking AI traffic
- Pattern definition: Choose patterns that reliably identify secrets (e.g., regexes for API keys, PEM headers, or UUIDs). Overly broad patterns can corrupt legitimate data, while overly narrow patterns may miss secrets.
- Performance impact: Real‑time inspection adds latency. hoop.dev is designed for Layer 7 processing, but you should benchmark the added round‑trip time in your CI pipeline to ensure it stays within acceptable limits.
- Policy lifecycle: As new services are added, update the masking policies accordingly. hoop.dev allows you to version policies so you can roll back if a change introduces false positives.
FAQ
What types of data can hoop.dev mask?
hoop.dev can mask any JSON field that matches a configured pattern. Common use cases include API keys, OAuth tokens, database connection strings, and personally identifiable information. The masking engine works on the payload level, so it can also redact values inside nested objects.
Does masking interfere with Claude’s ability to generate useful code?
Masking only replaces the value of fields identified as sensitive. The surrounding code structure remains intact, so Claude still receives the context it needs to produce accurate suggestions. In practice, teams see no degradation in output quality when masking is applied correctly.
Can I still review the original, unmasked request?
No. The design principle is that the AI service never sees raw secrets. hoop.dev stores only the masked version in its audit log. If you need the original for debugging, you must retrieve it from the CI job’s secure storage before it is sent through the gateway.
Next steps
Start by cloning the open‑source repository and following the deployment instructions. Explore the masking rule syntax, define the patterns that match your organization’s secrets, and enable session recording for full auditability.
Explore the open‑source repository on GitHub to get the code, contribute improvements, or file issues.
