SOC 2 for MCP servers: securing tool access without losing the audit trail (on on-prem)

A single compromised credential on an MCP server can erase the audit trail needed for SOC 2 compliance.

What SOC 2 expects from on‑prem tool access

SOC 2 focuses on five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. For on‑prem MCP (Model‑Control‑Process) servers, the security principle translates into concrete controls:

• Identity‑based, least‑privilege access to the server.
• Just‑in‑time (JIT) granting of privileges, with explicit approval for risky actions.
• Per‑session logs that capture who did what, when, and the data returned.
• Real‑time masking of sensitive fields to protect confidentiality.
• Separation of credential storage from the user or agent that runs commands.

Auditors look for evidence that each of these controls is enforced consistently, not just described in policy.

Typical gaps in MCP deployments

Many organizations run MCP servers with static service accounts or shared SSH keys. The credential lives on the operator’s workstation, and any command issued goes straight to the server. This model satisfies the identity‑setup requirement, users authenticate via SSO before they can reach the host, but it leaves three critical gaps:

• The connection bypasses any centralized enforcement point, so there is no way to block dangerous commands before they run.
• Responses are streamed back unchanged, meaning sensitive data can be exfiltrated without any redaction.
• Session activity is either not recorded or is stored on the same host that the user controls, making the logs vulnerable to tampering.

These gaps mean that, even with strong identity providers, an organization cannot demonstrate the audit‑trail and data‑protection controls required by SOC 2.

Why the data path must host enforcement

The missing piece is a gateway that sits on the data path between the identity layer and the MCP server. The gateway is the only place where the system can inspect, approve, mask, or record traffic before it reaches the target. Identity and role checks (the setup) decide who may start a request, but they cannot enforce command‑level policies without being in the data path.

hoop.dev as the SOC 2‑aligned gateway

hoop.dev is an open‑source, Layer 7 gateway that fulfills the enforcement role described above. It operates as an OIDC/SAML relying party, verifies the user’s token, and then proxies the connection to the MCP server. While proxying, hoop.dev can:

• Grant access only for the duration of a request, revoking it automatically on disconnect.
• Require an approval workflow for commands that match a risk policy (for example, database schema changes or file system writes).
• Apply inline masking rules to response payloads, ensuring that fields such as credit‑card numbers or personal identifiers never leave the gateway in clear text.
• Record every session, including the full command stream and the masked response, in a storage location that is separate from the MCP host.
• Provide replay capability so auditors can view exactly what happened during a flagged session.

Because hoop.dev is the sole point where traffic is inspected, all SOC 2 enforcement outcomes are guaranteed to happen. Removing hoop.dev would re‑expose the three gaps listed earlier.

Mapping SOC 2 controls to hoop.dev features

Below is a concise mapping of the SOC 2 criteria to the capabilities hoop.dev provides:

• Security – logical access control: JIT access and approval workflows enforce least‑privilege at the moment of use.
• Security – monitoring: Per‑session logs capture user identity, command, timestamp, and masked response, supplying the audit evidence auditors require.
• Confidentiality – data protection: Inline masking removes sensitive fields from the data path, satisfying confidentiality requirements.
• Processing integrity – change management: Risk policies can block or route high‑impact commands to a human reviewer, ensuring that only authorized changes are applied.
• Availability – controlled access: Because credentials are stored only in the gateway, accidental credential leakage does not affect service uptime.

In practice, an organization can configure these policies once, then rely on hoop.dev to enforce them automatically for every connection to an MCP server.

Deploying hoop.dev on‑prem for MCP servers

Deployment follows the standard on‑prem pattern: a Docker Compose file runs the gateway alongside a network‑resident agent that has direct network reach to the MCP host. The agent holds the server credential; users never see it. After the gateway is up, administrators register the MCP server as a connection in the UI, define masking rules, and create approval policies for privileged commands.

The official getting‑started guide walks you through deploying the gateway on‑prem, connecting it to your identity provider, and adding the first MCP connection.

Generating SOC 2 evidence with hoop.dev

When an audit period ends, the SOC 2 auditor asks for:

• Proof that only authorized identities accessed the MCP server.
• Evidence that any sensitive data returned was protected.
• Logs showing the full command history.

hoop.dev supplies all three. The gateway’s audit log can be exported in a structured format, and because the logs are stored outside the MCP host, they remain resistant to tampering. Masking policies are also versioned, giving auditors a clear view of what data was redacted and why.

FAQ

How does hoop.dev ensure logs cannot be altered after a session ends?

hoop.dev writes each session record to a backend that is separate from the MCP server. The gateway writes the record when the session terminates, and because the storage is not under the same control as the MCP host, an attacker who compromises a user’s workstation cannot directly modify the recorded data.

Can we keep our existing SSO provider?

Yes. hoop.dev acts as an OIDC/SAML relying party, so any standards‑compliant identity provider (Okta, Azure AD, Google Workspace, etc.) can continue to issue tokens. The gateway validates the token and extracts group membership to drive its JIT and approval decisions.

What if we need to mask a new field in the future?

Masking rules are managed centrally in hoop.dev’s policy UI. Adding a new field only requires updating the rule set; the change takes effect immediately for all subsequent sessions, without touching the MCP server or its client applications.

For deeper details on policy configuration, see the learn section of the hoop.dev site.

By placing enforcement in the data path, hoop.dev gives organizations the concrete, auditable controls that SOC 2 demands while preserving the flexibility of on‑prem MCP deployments.

Ready to see the code and start a trial deployment? Visit the hoop.dev GitHub repository for the open‑source project and follow the getting‑started guide.