Uncontrolled tool access on on‑prem MCP servers can erase the audit trail in minutes.
When a developer or an automated process reaches directly into a server that hosts a language model or a code‑generation service, the connection bypasses any central policy engine. The operator authenticates with a static service account, then runs commands over SSH or an HTTP API without any visibility into what was typed or returned. Missing logs or deliberate overwriting erase the proof of who did what.
NIST SP 800‑53 and related guidance demand that every privileged access event be traceable, that data in transit be protected, and that any privileged command be subject to approval or real‑time inspection. The standard also expects organizations to retain an immutable record of each session so auditors can verify compliance long after the fact. In practice, many on‑prem environments struggle to meet those expectations because the enforcement point lives inside the same host that runs the tool. Attackers can directly access the credential store, stop the logging agent, or modify audit records.
To close that gap, you must issue a non‑human identity on demand instead of baking a long‑lived secret into scripts. You verify the identity with a trusted OIDC or SAML provider, and you configure the resulting token to carry only the groups needed for the specific request. This setup decides who may start a session, but it does not, by itself, guarantee that the session will be recorded or that sensitive output will be hidden.
NIST treats audit readiness as a combination of three controls:
- You assign a unique identity to each session for authentication and authorization.
- You enforce real‑time checks that can block or require approval for risky commands.
- You store an immutable session record that captures both input and output for later review.
You must enforce each control at the point where the request crosses the network boundary, not inside the application process. When a dedicated gateway mediates every request before it reaches the target, you satisfy NIST’s recommendation for a boundary that cannot be bypassed by a compromised MCP server.
Why a gateway in the data path is essential
Only a gateway that sits in the data path can guarantee that every request is inspected, that every response is masked, and that a complete audit record is stored outside the target host. The gateway becomes the single place where policy is applied, making it impossible for a compromised MCP server to tamper with the enforcement outcome.
hoop.dev provides that gateway. It proxies connections to MCP servers, inspects the wire‑level protocol, and applies NIST‑level controls without exposing credentials to the client. Because hoop.dev runs on a network‑resident agent separate from the MCP server, hoop.dev creates the enforcement outcomes because it sits in the data path.
Just‑in‑time identity and approval
When a user requests access, hoop.dev validates the OIDC token, extracts group membership, and checks whether the request matches a policy that requires explicit approval. If approval is needed, hoop.dev pauses the request until a designated approver grants permission. This satisfies NIST’s requirement for controlled privileged access and eliminates the use of long‑lived credentials.
Inline masking of sensitive data
During a session, hoop.dev scans responses from the MCP server and replaces or redacts fields that match a configured pattern, such as API keys, personal identifiers, or proprietary code snippets. The original data never leaves the server unprotected, and the audit log contains the masked version, preserving privacy while still providing evidence of the operation.
Command‑level audit and replay
hoop.dev records every command sent to the MCP server and every response returned. It stores the records in a backend that is independent of the MCP host. Auditors can replay a session to see exactly what was typed, what the model returned, and which approvals were granted. This fulfills NIST’s requirement for immutable audit trails.
Mapping NIST controls to hoop.dev capabilities
| NIST control | Implementation via hoop.dev |
|---|
| AC‑2 Account Management | You issue dynamic, short‑lived OIDC identities per request. |
| AU‑6 Audit Review, Analysis, and Reporting | hoop.dev centralizes session logs that you can query and replay. |
| IA‑2 Identification and Authentication (Organizational Users) | You verify tokens against a trusted IdP before any connection is allowed. |
| SC‑7 Boundary Protection | All traffic to the MCP server passes through hoop.dev, the only place where policy is enforced. |
| SI‑12 Information Management and Retention | Masked logs retain necessary evidence while protecting sensitive fields. |
Each row shows that the control is realized only because hoop.dev sits in the data path. Removing hoop.dev would leave the MCP server exposed to unfiltered access, no masking, and no immutable logs.
Getting started on‑prem
Begin with the getting‑started guide that walks you through deploying the gateway in a Docker Compose environment, connecting an MCP server as a resource, and configuring OIDC authentication. The guide also explains how to define approval workflows and masking rules. All policy definitions live in the gateway configuration, keeping the MCP host untouched.
For deeper technical details, explore the learn section, which describes how session recording works, how masking patterns are expressed, and how you can integrate with existing identity providers.
FAQ
Does hoop.dev replace the existing authentication on the MCP server?
No. hoop.dev consumes the identity token from your IdP and then uses its own service credential to talk to the MCP server. The server’s native authentication remains unchanged, but clients never see those credentials.
Can I retain logs for the full NIST retention period?
Yes. hoop.dev stores session records in a backend of your choice. The storage is independent of the MCP host, so you can configure long‑term retention that satisfies audit requirements.
What happens if the gateway itself is compromised?
Because hoop.dev runs as a separate process on a dedicated host, you can apply the same hardening and monitoring you would for any critical infrastructure component. Compromise of the gateway would appear in the audit logs, and you can rotate its service credential without affecting the MCP server.
Start exploring the source on GitHub to see how the gateway is built and how you can extend it for your environment.
