Without concrete audit artifacts, an auditor’s request can stall an organization for weeks.
Why compliance evidence matters for MCP deployments
Most teams treat the MCP server as a convenience layer for LLM‑driven code assistance. The default setup streams requests and responses directly to the model, logs them in a local file, and assumes that those logs satisfy any future audit. In practice, those logs are incomplete, can be altered by the same process that generated them, and rarely capture who approved a risky suggestion or whether sensitive data was redacted. When a regulator asks for evidence of how personal data was handled, the organization is left scrambling for trustworthy records.
Current gaps in the uncontrolled MCP flow
In a typical uncontrolled environment, the following conditions hold:
- Authentication is performed once, often via a shared service account, and then the process talks to MCP without re‑evaluating the caller’s identity.
- Requests travel straight to the model. No gateway inspects the payload, so there is no inline masking of credit‑card numbers, social security numbers, or other regulated fields.
- Session data is written to a local log that the same host can truncate or delete, providing no immutable trail.
- Approvals for high‑risk prompts are missing; any engineer can ask the model to generate privileged commands.
These gaps mean that while the organization may have some raw logs, it lacks the structured, tamper‑evident evidence auditors expect for compliance reviews.
Introducing hoop.dev as the data‑path control plane
hoop.dev is deployed as a Layer 7 gateway that sits between every identity and the MCP server. The gateway is the only place enforcement can happen, because it proxies every request and response. Setup components such as OIDC or SAML tokens decide who is allowed to start a session, but they do not enforce any policy on their own.
Once a request reaches the gateway, hoop.dev applies a series of controls that together generate compliance evidence:
- It records each MCP session, capturing the full request, response, timestamp, and the authenticated identity that originated the call.
- It masks regulated fields in real time, ensuring that logs never contain raw sensitive data while still preserving the context needed for audit.
- It can require just‑in‑time approval for prompts that match a high‑risk policy, creating an explicit approval record before the model runs.
- It records the audit trail in a way that the MCP process cannot modify the evidence.
Because hoop.dev is the only component that sees the traffic, every enforcement outcome, session recording, inline masking, JIT approval, exists only because hoop.dev sits in the data path.
How the compliance evidence is structured
When an auditor requests proof, hoop.dev can supply a package that includes:
- A chronological log of every MCP interaction, tagged with the user’s identity and the outcome of any approval workflow.
- A redacted view of the data, showing that masking was applied according to policy.
- Metadata about the gateway version, configuration of masking rules, and the approval policies that were active at the time of each session.
This package satisfies the typical evidence requirements for access control, data handling, and change management without claiming that hoop.dev itself is certified for any specific standard.
Getting started with hoop.dev and MCP
Begin by deploying the gateway using the standard Docker Compose quick‑start. The getting‑started guide walks you through connecting an OIDC identity provider, registering the MCP endpoint as a resource, and enabling session recording and masking. Detailed feature explanations are available in the learn section, where you can explore policy syntax for masking and approval workflows.
FAQ
Do I need to modify my existing MCP client code?
No. hoop.dev proxies standard TCP traffic, so existing clients continue to connect to the same hostname and port. The gateway handles authentication and policy enforcement transparently.
Can I retroactively apply masking to older logs?
Masking is applied in real time as traffic passes through the gateway. For historical data, you would need to re‑process the logs with a separate tool; hoop.dev does not rewrite past records.
What happens if the gateway is unavailable?
Because all traffic must flow through the gateway, an unavailable gateway blocks access to MCP. This fail‑closed behavior ensures that no unrecorded request can slip through.
For the full source code and contribution guidelines, visit the GitHub repository.
