Without auditable control over AI‑driven actions, a SOC 2 audit can turn into a nightmare.
SOC 2 evidence requirements for AI agents
SOC 2 evaluates five trust‑service criteria, but for an AI integration the most relevant are Security, Confidentiality, and Processing Integrity. Auditors expect concrete evidence that:
- Each request to the Claude Agent SDK ties to a verified identity.
- Privileged operations, such as model fine‑tuning or data upload, receive human approval before execution.
- All inputs and outputs that contain personal or business‑critical data get masked or redacted in logs.
- Every session can be replayed to prove what was sent and what was received.
- Access grants only for the time needed to complete the task (just‑in‑time).
In practice, many teams embed the SDK directly in their services, pass static API keys to Claude, and rely on the cloud provider’s logs. That approach leaves three gaps:
- Setup only. Identity verification happens at the token level, but the request then travels straight to Claude without a checkpoint that can enforce policy.
- No centralized data path. Because the SDK talks directly to the service, there is no place to capture a full audit trail.
- No enforcement outcomes. Without a gateway, you cannot mask fields, require approval, or record the session for replay, so the evidence auditors demand simply does not exist.
Why the data path must be controlled
The SOC 2 standard treats the data path as the security perimeter. Controls that protect the request and response must be applied where the traffic actually flows. If the enforcement point sits outside the process that holds the credentials, you gain two guarantees:
- The process never sees raw secrets; the gateway presents them to the target service.
- The gateway can inspect, alter, or block all traffic before it reaches the AI model.
Only a purpose‑built, identity‑aware proxy can provide those guarantees while still letting developers use the familiar Claude SDK APIs.
hoop.dev as the SOC 2‑ready gateway
hoop.dev sits in the data path between the Claude Agent SDK and Claude’s endpoints. It acts as an identity‑aware proxy that verifies OIDC or SAML tokens, maps group membership to fine‑grained permissions, and enforces policy before any request leaves the network.
Because hoop.dev is the only component that can see the request, it can:
- Record every session. hoop.dev logs each SDK call with the user’s identity, timestamp, and full request/response payload (masked where required). The logs reside outside the SDK process, meeting the audit‑trail requirement of SOC 2.
- Mask sensitive fields inline. When a response contains credit‑card numbers or personal identifiers, hoop.dev redacts them before hoop.dev writes them to the log, preserving confidentiality without breaking the SDK workflow.
- Require just‑in‑time approval. For high‑risk actions, such as uploading training data, hoop.dev pauses the request and routes it to an approver. The approval record becomes part of the audit evidence.
- Block disallowed commands. If a developer tries to execute a command that exceeds their role, hoop.dev rejects it and records the denial, demonstrating processing integrity.
- Enable replay. hoop.dev replays recorded sessions in a sandbox to verify that the SDK behaved as expected during the audit period.
All of these outcomes exist because hoop.dev occupies the data path; removing it would eliminate the evidence entirely.
Getting started with hoop.dev and the Claude Agent SDK
Deploy the gateway using the Docker Compose quick‑start, then register the Claude endpoint as a connection. The gateway holds the service credentials, so developers never handle them directly. Your OIDC provider authenticates users, and group claims drive the fine‑grained policy you define in the gateway configuration.
For step‑by‑step guidance, see the getting‑started guide and the broader learn section. Both pages walk you through installing the agent, defining a connection, and configuring just‑in‑time approvals for the Claude SDK.
FAQ
Do I need to modify my existing Claude SDK code?
No. hoop.dev works as a transparent proxy. Your application continues to call the SDK as before; the gateway automatically routes the network traffic.
Can I use hoop.dev on‑premise to keep audit logs inside my security zone?
Yes. The gateway is self‑hosted and can be placed behind any internal firewall, ensuring that logs never leave the controlled environment.
What evidence does hoop.dev actually produce for a SOC 2 audit?
hoop.dev generates per‑user session logs, approval records, masking audit trails, and command‑block events. Those artifacts map directly to the Security, Confidentiality, and Processing Integrity criteria required by SOC 2.
Ready to see the code? Explore the open‑source repository on GitHub and start building SOC 2‑ready AI integrations today.
