An engineering team grants a newly hired contractor a service account that can invoke the internal MCP server used by CI pipelines. The contractor runs a script from a pod in the Kubernetes cluster, pulls sensitive configuration data, and the team discovers the leak only after the damage is done. No one can point to a command, a user, or a time window that explains how the data left the environment.
Why the current model fails to satisfy SOC 2 evidence requirements
Most organizations rely on identity federation (OIDC or SAML) to decide who may call an MCP server. The setup gives the contractor a JWT that the server trusts, and the request flows directly to the server over the network. This arrangement satisfies the "who can access" part of a security policy, but it leaves three critical gaps:
- There is no immutable record of each request, so auditors cannot prove who executed which operation.
- Sensitive fields in the server’s response travel back to the caller in clear text, violating data‑in‑transit protection controls.
- Any dangerous command can be run without a human check, breaking segregation‑of‑duties requirements.
From a SOC 2 standpoint, the evidence needed to demonstrate these controls is missing. The standard expects continuous, tamper‑evident logs of access, documented approval workflows, and proof that sensitive data is protected at every step.
What the precondition fixes – and what it still leaves open
Introducing a strong identity provider and scoping the service account to the MCP server solves the "who can start" question. The contractor now has a token that conveys only the permissions required for the CI job. However, the request still travels straight to the MCP server, bypassing any enforcement point. Without a gateway in the data path, the organization still cannot:
- Capture a per‑command audit trail.
- Mask or redact confidential fields before they reach the caller.
- Require a manager’s approval for high‑risk operations.
In other words, the identity layer alone does not generate the SOC 2 evidence auditors demand.
hoop.dev as the mandatory data‑path control surface
hoop.dev is a Layer 7 gateway that sits between the identity layer and the MCP server. Deployed as a separate service in the Kubernetes cluster, it runs an agent next to the MCP server. Every request from a user, CI job, or AI‑driven tool must pass through hoop.dev before reaching the server.
Because hoop.dev is the only place the traffic is inspected, it can enforce all of the controls required for SOC 2:
- Session recording: hoop.dev records each protocol exchange, producing a replayable log that shows exactly what was sent and received.
- Just-in-time approval: High‑risk commands trigger an approval workflow; the request is paused until a designated approver signs off.
- Inline data masking: Sensitive fields (API keys, passwords, personal identifiers) are redacted in the response before they leave the gateway.
- Command blocking: Dangerous statements (e.g., destructive configuration changes) are rejected outright, preventing accidental or malicious misuse.
All of these outcomes exist only because hoop.dev occupies the data path. If the gateway were removed, the same identity setup would still allow unrestricted access, and none of the audit or masking capabilities would be present.
Mapping hoop.dev capabilities to SOC 2 trust‑service criteria
SOC 2 evaluates five trust‑service criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. The following table shows how hoop.dev’s features provide continuous evidence for each criterion when protecting MCP servers on Kubernetes.
| SOC 2 Criterion | Evidence generated by hoop.dev |
|---|
| Security | Per‑session logs, approval records, and command‑block events prove that only authorized actions were performed. |
| Availability | Gateway health metrics and fail‑over logs demonstrate that the access path remains operational. |
| Processing Integrity | Replayable recordings verify that requests were processed exactly as received, without unauthorized alteration. |
| Confidentiality | Inline masking ensures that protected data never leaves the gateway in clear text; audit logs capture the masked view only. |
| Privacy | Identity‑aware policies enforce that personal data is accessed only by users with the appropriate role, and the audit trail records the rationale for each access. |
Because hoop.dev records each session in a durable store, it provides a complete audit trail that auditors can retrieve at any time. The evidence is generated continuously, eliminating the need for manual log extraction before each audit.
Getting started with hoop.dev for MCP servers
Deploying the gateway follows the standard getting started guide. The process includes:
- Running the hoop.dev Docker Compose file (or the Helm chart) inside the Kubernetes cluster.
- Registering the MCP server as a connection, supplying the host address and the service credentials that the gateway will use.
- Configuring OIDC authentication so that each caller presents a JWT that hoop.dev can validate.
- Enabling the masking and approval policies that match your organization’s SOC 2 controls.
The feature documentation provides detailed guidance on policy syntax, replay tools, and integration with CI pipelines. All configuration is declarative, and the open‑source repository contains the full source code for review.
FAQ
Does hoop.dev make my MCP server SOC 2 compliant?
No. hoop.dev generates the audit evidence that a SOC 2 audit expects, but compliance ultimately depends on the broader set of controls your organization implements.
Can I use hoop.dev with existing CI/CD pipelines?
Yes. Because hoop.dev presents the same wire‑protocol endpoints as the native MCP server, pipelines can point to the gateway without code changes. The gateway then applies the configured guardrails.
What happens to logs if the gateway pod crashes?
hoop.dev writes logs to an external, durable store before acknowledging the request. A crash does not erase already‑recorded sessions, ensuring continuous evidence.
Ready to see the code in action? Explore the open‑source repository on GitHub and start building a SOC 2‑ready audit trail for your MCP servers today.
