How can you prove to a SOC 2 auditor that your MCP servers are both secure and fully auditable?
Many organizations run MCP (Model‑Control‑Process) servers as internal tools that automate deployment pipelines, data processing, or configuration management. In practice, engineers often grant themselves permanent credentials, embed service‑account keys in scripts, or allow any authenticated user to invoke the server without any visibility into what commands were run. The result is a sprawling surface of standing access where a single compromised token can issue destructive actions, and the audit team is left with vague cloud‑provider logs that do not show the exact request payloads or the human decision that authorized them.
Even when an organization adopts least‑privilege identities, the request still travels directly to the MCP endpoint. The identity provider verifies the token, but once the request leaves the IdP there is no checkpoint that can enforce policy, record the exact query, or mask sensitive fields before they reach the server. The auditor therefore sees a gap: the control matrix shows “access is limited to service accounts,” yet the evidence does not demonstrate that each invocation was reviewed, logged, or protected against data leakage.
Why the data path matters for SOC 2 evidence
SOC 2 requires that an organization can produce concrete artifacts for the following criteria:
- Logical access controls that restrict who can invoke the tool.
- Complete, immutable logs of every request, including user identity, timestamp, and request payload.
- Evidence that sensitive response data is protected, either by masking or by redaction, before it is stored or displayed.
- Just‑in‑time (JIT) approval workflows that demonstrate a human decision for high‑risk operations.
These artifacts must be generated at the point where the request is made, not after it reaches the MCP server. If the enforcement layer lives only in the identity provider (the Setup stage), the auditor cannot verify that the request was examined or altered before execution. The missing link is a gateway that sits in the data path and applies the required controls.
Introducing hoop.dev as the enforcement layer
hoop.dev is an open‑source Layer 7 gateway that proxies every connection to MCP servers. It sits between the authenticated identity and the target service, inspecting the wire‑protocol payloads in real time. Because hoop.dev is the sole conduit, it can enforce three core SOC 2 outcomes:
- Session recording. hoop.dev records each request and response, attaching the user’s OIDC claims and a precise timestamp. Because the recording is performed by the gateway, it provides an auditable trail independent of the MCP server.
- Inline data masking. Sensitive fields, such as API keys, passwords, or personal identifiers, are redacted before the response is handed to the client or persisted in logs.
- Just‑in‑time approval. For operations flagged as high‑risk, hoop.dev routes the request to an approval workflow, requiring a designated reviewer to approve or deny before the command reaches the MCP server.
All of these actions are performed by hoop.dev, not by the MCP server itself. The gateway’s policy engine runs in a separate process, guaranteeing that the enforcement outcomes exist only because hoop.dev is present in the data path.
How hoop.dev satisfies each SOC 2 trust service principle
Security – logical access. The gateway validates OIDC tokens, extracts group membership, and matches it against a policy that defines which users may invoke which MCP endpoints. Because the check occurs at the gateway, any attempt to bypass the policy by calling the server directly is blocked.
Availability – controlled execution. JIT approvals prevent accidental or malicious execution of destructive commands. The approval step adds a human checkpoint without introducing downtime, because the request simply waits in the gateway queue until an approver signs off.