Missing audit trails on tool access is a direct route to SOC 2 failure.
SOC 2 expects concrete evidence that every privileged interaction with a system is linked to an identified user, that the action was authorized, and that the outcome is immutable for the audit period. When developers or automated agents reach an MCP server, the connection often bypasses traditional log collectors, leaving the audit team with gaps that can be cited as a control deficiency.
Teams consider typical workarounds, manual log forwarding, ad‑hoc shell history, or periodic screenshots, as fragile because they cannot guarantee that a malicious command was blocked or that sensitive data was redacted. The standard therefore requires a single, enforceable point where identity, policy, and recording converge.
Why a gateway is required for SOC 2 evidence
The SOC 2 criteria for logical and physical access control are built around three pillars: identification, authorization, and auditability.
Identification is handled by an OIDC or SAML identity provider that asserts who the caller is.
Authorization must be enforced at the moment the request reaches the target system, not after the fact.
Auditability requires the organization to retain a reliable record of each request, the decision made, and the response.
When an MCP server sits behind a network perimeter, the only place that can satisfy all three pillars simultaneously is the data path between the requester and the server. Placing controls inside the server or in a separate logging pipeline cannot guarantee that a command was not altered before it arrived, nor can it provide real‑time approval workflows required by SOC 2.
hoop.dev as the data‑path enforcement layer
hoop.dev implements a Layer 7 gateway that sits directly in the traffic flow to an MCP server.
The gateway authenticates each caller against the organization’s OIDC provider, extracts group and role information, and then decides whether the request may proceed, needs a human approval, or should be blocked.
Because hoop.dev uniquely observes the full protocol exchange, it can enforce several SOC 2‑relevant outcomes:
- Session recording: hoop.dev captures every request and response and stores a replay‑able log that ties the action to the authenticated identity.
- Just‑in‑time approval: For high‑risk commands, hoop.dev routes the request to a designated approver, creating a documented approval event before execution.
- Inline data masking: hoop.dev redacts sensitive fields in responses, such as passwords, tokens, or PII, in real time, ensuring that logs never expose confidential data.
- Command blocking: hoop.dev halts dangerous operations (for example, destructive database statements) before they reach the MCP server.
hoop.dev records each of these actions in an audit trail that can be trusted to meet the “auditability” requirement of SOC 2. Because the gateway itself generates the trail, no compromised MCP server or malicious insider with server‑level access can alter the evidence.
Integrating hoop.dev with GCP‑hosted MCP servers
Deploying hoop.dev on GCP follows the same pattern as any other target. A Docker‑Compose or Kubernetes manifest runs the gateway close to the MCP server, ensuring low latency and network proximity. The gateway holds the server’s credential, so users never see the underlying secret.
Identity federation is configured once with the organization’s OIDC provider, Google Workspace, Azure AD, or any SAML source, allowing the same policy engine to govern both human engineers and service accounts.
Once deployed, the access flow looks like this:
- A user or automated agent obtains an OIDC token from the corporate IdP.
- The user or agent presents the token to hoop.dev, which validates it and extracts the caller’s attributes.
- Based on policy, hoop.dev either forwards the request to the MCP server, routes it for approval, or blocks it outright.
- hoop.dev records the full exchange, masks data as needed, and stores it for the audit period.
This architecture satisfies SOC 2’s “Logical Access Controls” and “System Operations” criteria because every privileged action is both authorized and documented at the exact point where it could cause impact.
Generating SOC 2 evidence with hoop.dev
Auditors typically request three artifacts: an access‑control matrix, a log of privileged actions, and proof that sensitive data was protected.
- Access‑control matrix: Policies are defined centrally and enforced by the gateway, giving auditors a clear mapping of roles to allowed actions.
- Privileged‑action log: The session recordings include timestamps, caller identity, command text, and approval status, forming a comprehensive audit log.
- Data‑protection evidence: Inline masking records indicate which fields hoop.dev redacted, proving that PII never entered the permanent log store.
hoop.dev produces the logs, making them independent of the MCP server’s own logging mechanisms, eliminating a common source of evidence inconsistency.
Getting started
To see a concrete walkthrough of deploying the gateway, refer to the getting‑started guide. The learn section expands on policy authoring, approval workflows, and masking rules.
FAQ
Does hoop.dev replace the MCP server’s native authentication?
No. hoop.dev authenticates the caller and then forwards the request using the server’s own credential, which remains stored only inside the gateway.
Can I use hoop.dev with existing GCP IAM policies?
Yes. hoop.dev complements IAM by adding a runtime enforcement layer that operates on the actual traffic, not just on resource‑level permissions.
How long are the audit records retained?
Retention follows the organization’s log‑storage policy; hoop.dev simply writes records that can be archived for the audit period required by SOC 2.
Next steps
Explore the open‑source implementation on GitHub and begin integrating the gateway into your GCP environment to close the SOC 2 evidence gap for MCP servers.
