When an organization can prove that every interaction with its MCP servers is authorized, recorded, and tamper‑free, SOC 2 auditors have the evidence they need without chasing missing logs.
SOC 2 focuses on five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. For the security criterion, auditors expect a documented control environment, strict access management, and an audit trail that ties every action back to a verified identity. The confidentiality and privacy criteria demand that any personally identifiable or sensitive data exposed by a tool be protected, either by limiting who can see it or by redacting it in logs. Processing integrity requires that no unauthorized command can alter the state of a service without appropriate review.
In many teams, developers connect directly to MCP servers from their workstations using long‑lived service accounts. Those accounts often have broad privileges, and the connection bypasses any central enforcement point. As a result, teams lack a guaranteed record of who ran which command, they miss real‑time validation of intent, and they cannot hide sensitive fields from audit logs. Even when organizations adopt OIDC or SAML for authentication, the client presents the token to the MCP server, which trusts the caller and executes the request without a checkpoint that could enforce SOC 2 controls.
Why the data path matters for SOC 2
Authentication (the setup) tells the system who is making a request, but it does not enforce what the request can do. SOC 2 requires that the enforcement happen where the request actually traverses – the data path. Without a gateway that sits between the identity provider and the MCP server, the organization cannot guarantee that every request is examined for policy compliance, that sensitive responses are masked, or that an approval workflow is triggered for risky operations.
Introducing a gateway that fulfills SOC 2 evidence requirements
hoop.dev acts as an identity‑aware proxy for MCP servers. It receives the OIDC token, validates the user’s groups, and then forwards the request to the target service. Because the gateway sits in the data path, it applies a suite of controls that directly satisfy SOC 2 expectations:
- Session recording: hoop.dev records each interaction, timestamps it, and stores the log in a secure store. Auditors can replay any session to verify that the observed behavior matches the recorded intent.
- Just‑in‑time (JIT) access: Users receive temporary permissions that expire when the session ends, limiting the blast radius of any credential compromise.
- Approval workflows: hoop.dev routes high‑risk commands to a designated approver before execution, providing documented evidence of manual review.
- Inline data masking: hoop.dev redacts sensitive fields in responses before they reach the audit log, ensuring that logs do not expose confidential information while still preserving the ability to audit the transaction.
- Command blocking: hoop.dev identifies and rejects dangerous statements before they reach the MCP server, preventing accidental or malicious state changes.
hoop.dev produces each of these outcomes. Removing the gateway eliminates all of those controls, even though authentication might still be in place.
How hoop.dev generates SOC 2 evidence
Auditors look for three core artifacts: a definitive access log, proof of review for privileged actions, and assurance that sensitive data is protected. hoop.dev supplies all three:
- hoop.dev logs every session with the user’s identity, the exact command, and the response status. The logs are retained without alteration and can be exported for audit purposes.
- hoop.dev records approval events alongside the original request, showing who approved, when, and why. This satisfies the “review of privileged operations” requirement.
- When a response contains fields marked as confidential, hoop.dev masks them before they are written to the audit log, preserving confidentiality while still providing a complete activity trail.
Because the gateway deploys inside the same network segment as the MCP server, it enforces these policies without requiring changes to the server’s configuration. Teams adopt the solution by following the standard deployment guide, configuring OIDC, and registering the MCP server as a protected resource. The detailed steps are covered in the getting‑started documentation and the broader feature overview at hoop.dev/learn.
FAQ
Do I need to replace existing service accounts?
No. hoop.dev stores the credentials needed to talk to the MCP server internally. Users never see those credentials; they authenticate with OIDC, and the gateway injects the appropriate service account only for the duration of the session.
Can I still use existing CI pipelines?
Yes. CI jobs obtain an OIDC token from the identity provider and connect through hoop.dev just like a human user. The same JIT and masking controls apply, giving you audit‑ready pipelines.
What happens to logs if a breach occurs?
Because hoop.dev writes logs to a protected store, an attacker who compromises the MCP server cannot alter the recorded session data. The logs remain available for forensic analysis and SOC 2 audit review.
Explore the source code, contribute improvements, and see how the gateway is built by visiting the GitHub repository: https://github.com/hoophq/hoop.
