A continuous audit log, real‑time masking of sensitive data, and just‑in‑time approvals together provide the evidence auditors need to verify SOC 2 compliance for an MCP service.
Most teams start by exposing an LLM endpoint directly to developers, CI pipelines, or automated agents. The endpoint often runs with a single service account that has broad read and write permissions. Requests flow straight to the model server, and the only record kept is whatever the application writes to its own logs, if anything at all. That approach leaves three gaps that SOC 2 auditors flag: (1) there is no independent, immutable audit trail of who asked what; (2) sensitive user data can be returned unfiltered; and (3) any risky operation proceeds without a human check.
Addressing the first gap usually means adding an identity layer, OIDC or SAML tokens that identify each caller. That step tells the MCP server *who* is making a request, but it does not change the fact that the request still travels straight to the model process, bypassing any central control point. The second and third gaps remain: the model can still emit raw data, and there is no gate that can pause a request for approval.
Why the data path must host enforcement for SOC 2
SOC 2 requires evidence that access is controlled, that data is protected, and that any deviation from policy is recorded. Those controls can only be guaranteed if they sit on the path between the caller and the MCP server. A gateway placed there can inspect each request, enforce masking rules, trigger an approval workflow, and write an immutable record that is independent of the model process.
This is where hoop.dev comes in. hoop.dev is a Layer 7 gateway that proxies connections to infrastructure, including the built‑in MCP server. It runs an agent inside the network that holds the credentials for the MCP service, while every client authenticates through an OIDC identity provider. Because the gateway is the sole conduit for traffic, it can apply the enforcement outcomes that SOC 2 auditors look for.
Setup: identity and least‑privilege grants
First, each user or automated agent obtains an OIDC token from a trusted IdP (Okta, Azure AD, Google Workspace, etc.). The token carries group membership that maps to specific MCP workloads. hoop.dev validates the token, extracts the identity, and then decides whether the request may proceed based on the least‑privilege policy you define. This step determines *who* is making the call, but it does not yet enforce any guardrails.
The data path: hoop.dev as the enforcement point
All MCP traffic is forced through hoop.dev’s proxy. Because the proxy sits at the protocol layer, it can:
- Record every request and response, storing the session outside the MCP process for immutable audit.
- Apply inline masking to any fields that match a sensitivity pattern, ensuring that protected data never leaves the gateway in clear text.
- Require just‑in‑time human approval for operations that match a risk rule, such as prompts that include private identifiers.
- Block commands or queries that violate a predefined policy before they reach the model.
Each of these actions is an enforcement outcome that exists only because hoop.dev occupies the data path. Remove hoop.dev and the MCP server would again handle requests directly, losing the audit trail, masking, and approval steps.
Evidence that satisfies SOC 2 criteria
SOC 2 is organized around five Trust Services Criteria. hoop.dev’s enforcement outcomes map directly to each:
- Security: Recorded sessions prove that only authorized identities accessed the MCP service, and blocked requests demonstrate that malicious or out‑of‑policy actions never executed.
- Availability: The gateway can enforce rate limits and health checks, providing documented evidence that the service remained available under defined conditions.
- Processing integrity: Approval workflows create a verifiable chain of custody for high‑risk prompts, showing that processing followed approved procedures.
- Confidentiality: Inline masking guarantees that personally identifiable information (PII) or secret keys are never transmitted in clear, and the logs themselves are stored with access controls that meet confidentiality requirements.
- Privacy: By redacting sensitive fields before they leave the gateway, hoop.dev helps you demonstrate compliance with privacy commitments.
Because the logs are written by the gateway, they are independent of the MCP application’s own logging. Auditors can verify the integrity of the logs by checking the gateway’s version and configuration, which are themselves recorded in the same audit trail.
Getting started with continuous SOC 2 evidence
To begin, follow the getting‑started guide to deploy the hoop.dev gateway alongside your MCP server. The quick‑start uses Docker Compose, but you can also run the gateway in Kubernetes or on a VM if that matches your environment. After deployment:
- Configure your OIDC provider in the gateway’s identity settings.
- Register the MCP endpoint as a connection, supplying the service‑account credential that the gateway will use.
- Define masking rules for the data fields you need to protect.
- Set up approval policies for high‑risk prompts.
- Enable session recording to capture every exchange.
All of these steps are documented in the public repository and the learning center. Once the gateway is live, every request to MCP will generate the evidence required for SOC 2 audits without any changes to your client code.
FAQ
How does hoop.dev ensure the audit log cannot be tampered with?
Because the gateway writes the log outside the MCP process, the log is not subject to the same write permissions as the application. The gateway’s own identity and configuration are recorded alongside each session entry, creating a chain of custody that auditors can verify.
Can I add masking rules after the gateway is deployed?
Yes. Masking policies are managed through the gateway’s configuration API. Changes take effect immediately for new requests, and existing logs remain unchanged, preserving the original evidence.
hoop.dev provides the core evidence required for SOC 2, but you may integrate its log output with broader SIEM or compliance platforms if you need additional correlation or retention capabilities.
Ready to see the code? Explore the open‑source repository on GitHub and start building continuous SOC 2 evidence for your MCP service today.
