What SOC 2 expects from an MCP gateway
Are you struggling to prove that your MCP gateway meets SOC 2 requirements? SOC 2 focuses on the Trust Services Criteria, especially security, availability, and confidentiality. Auditors look for concrete evidence that every access request is authorized, that sensitive data is protected in transit and at rest, and that the organization can reconstruct what happened during an incident. To satisfy these controls you need immutable logs of who connected, what commands were issued, and any data that left the system, plus a record of any manual approvals that overrode automated policies.
How teams typically run MCP gateways today
In many organizations teams launch the MCP gateway as a simple container or VM that developers point their agents at. Teams often run the gateway with a static service account credential that they share across the team. Because the gateway sits directly in front of the model‑serving endpoint, every request flows straight through without a central checkpoint. The result is a blind spot: there is no guaranteed audit trail, no enforced data‑masking, and no way to require a human sign‑off for risky operations. Engineers can see the raw responses, but the organization cannot prove to an auditor that the appropriate controls were applied.
Why generating SOC 2 evidence requires a data‑path gateway
The SOC 2 audit trail must be complete and tamper‑evident. That means the point where a request enters the MCP service must enforce policy and capture evidence. A data‑path gateway intercepts the wire‑level protocol, applies masking rules before sensitive fields leave the system, and records every command for later replay. It also provides a hook for just‑in‑time (JIT) approvals, ensuring that privileged actions only occur after a designated reviewer grants consent.
How hoop.dev provides the required evidence
hoop.dev sits in the data path of an MCP gateway. By proxying every connection, hoop.dev can:
- Record each session, preserving a replayable log that shows exactly what was sent and received.
- Mask sensitive fields in responses, guaranteeing that confidential data never appears in logs or on the client screen.
- Enforce JIT approval workflows, blocking high‑risk commands until an authorized reviewer approves them.
- Retain a comprehensive audit trail that you can export for SOC 2 evidence collection.
Because hoop.dev controls the traffic, the organization can demonstrate to auditors that it accounts for every access event, enforces data protection policies at the point of egress, and performs privileged actions only with documented consent. The gateway also isolates credentials from users and agents, reducing the risk of credential leakage.
Mapping SOC 2 criteria to hoop.dev capabilities
SOC 2’s Security (Common Criteria) requires logical access controls, monitoring, and incident response. hoop.dev satisfies these by:
- Binding every request to an OIDC‑issued identity, so access always traces to a known user or service account.
- Generating a per‑session record that includes timestamps, user ID, command text, and masked response data.
- Providing a configurable policy engine that denies, allows, or requires approval for specific commands.
SOC 2’s Availability criteria demand that systems are resilient and that failures are logged. hoop.dev runs as a stateless proxy that you can deploy in high‑availability mode behind a load balancer, and any denial or error appears in the audit log.
SOC 2’s Confidentiality criteria focus on protecting data in transit and at rest. hoop.dev’s inline masking ensures that sensitive fields never leave the gateway unprotected, and the gateway terminates TLS connections, guaranteeing encrypted transport.
Operational considerations
When you adopt hoop.dev for SOC 2 compliance, treat the gateway as a critical security component. Deploy it using the getting‑started guide so that the agent runs inside the same network segment as the MCP target. Configure role‑based groups in your identity provider to reflect the principle of least privilege; hoop.dev honors those groups when evaluating policies. Regularly review the audit logs and configure alerting for denied commands or unexpected approval requests.
hoop.dev handles high‑throughput workloads. Because it operates at the protocol layer, it adds only minimal latency while still performing masking and policy checks. Horizontal scaling is straightforward: run multiple gateway instances behind a load balancer, and each instance writes to the same backend store, which consolidates the session logs. This approach lets you meet both performance SLAs and SOC 2’s requirement for consistent monitoring across all instances.
Key takeaways
- SOC 2 demands verifiable evidence of who accessed what, when, and how data was protected.
- A data‑path gateway is the only place to enforce those controls reliably.
- hoop.dev provides session recording, inline masking, JIT approvals, and comprehensive audit trails, all essential for SOC 2 evidence.
- Deploying hoop.dev follows the standard getting‑started workflow and leverages existing OIDC identity providers.
- Operational hygiene, regular log review, role‑based group management, and high‑availability deployment, ensures the evidence remains trustworthy.
FAQ
Does hoop.dev make my MCP gateway SOC 2‑certified?
hoop.dev does not claim certification. It generates the audit evidence that auditors require for SOC 2 compliance.
Can I use hoop.dev with existing MCP deployments?
Yes. hoop.dev acts as a transparent proxy, so existing agents and client tools continue to work without code changes.
What kind of logs does hoop.dev produce?
hoop.dev captures a full session record, including timestamps, user identity, command text, and masked response data. You can export these logs to your SIEM or retain them for audit purposes.
Ready to see how hoop.dev can help you meet SOC 2 evidence requirements? Check out the project on GitHub and start building a compliant MCP gateway today.
