What auditors really need
Many assume that simply logging a user’s IP address satisfies compliance evidence, but raw logs without context are insufficient. Auditors typically require a complete, immutable trail that shows who accessed what, when, and under which policy. They look for evidence of intent (approval workflows), the exact commands executed, and any data that left the system. They also expect that sensitive fields are protected, yet still verifiable that masking occurred when required.
Why typical logging falls short
Standard system logs often capture connection timestamps and usernames, but they rarely record the payload of a database query or the output of an SSH session. Without that depth, an auditor cannot confirm that a privileged operation was performed correctly or that a data‑leak prevention control was applied. Moreover, logs stored on the same host that runs the service are vulnerable to tampering, making it hard to prove integrity.
How an MCP gateway can fill the gap
An MCP (Managed Control Plane) gateway sits at the protocol layer between the client, whether a human engineer, an automated service account, or an AI‑driven agent, and the target resource such as a database, Kubernetes cluster, or remote host. By intercepting traffic, the gateway can record every request and response, enforce just‑in‑time approvals, apply inline masking, and block disallowed commands before they reach the backend. Those capabilities produce the detailed audit data that compliance frameworks require.
hoop.dev as the data‑path gateway
hoop.dev implements exactly this pattern. It is an open‑source Layer 7 gateway that proxies connections to supported targets and enforces policy at the data path. Because the gateway sits between identity verification (OIDC/SAML) and the resource, it is the only place where enforcement can happen. hoop.dev records each session, captures the full command stream, and stores the audit trail outside the target’s host. It also masks sensitive fields in responses and requires human approval for high‑risk operations. In this way, hoop.dev generates compliance evidence for your programs without claiming any certification.
Best practices for collecting compliance evidence
- Enable session recording for every connection. Ensure that the gateway logs the full request and response payloads, not just metadata. This provides the command‑level audit auditors expect.
- Scope access with just‑in‑time (JIT) policies. Define short‑lived permissions that are granted only after an approval workflow. The approval record becomes part of the evidence set.
- Apply inline data masking. When a response contains personally identifiable information (PII) or other regulated data, configure the gateway to mask those fields. The masking action itself is logged, proving that data protection controls were active.
- Store audit logs in a secure logging service. Export the gateway’s audit feed to a logging service that preserves integrity, keeping the evidence trustworthy.
- Tag each session with identity context. The gateway ties every request to the OIDC token that authenticated the client, preserving the who‑and‑why information required by most standards.
- Regularly review and prune retention policies. Align log retention with the longest period required by the standards you follow, and ensure that older logs are archived securely.
Integrating the gateway into your compliance workflow
Start by deploying the gateway using the getting‑started guide. Register each critical resource, PostgreSQL, Kubernetes clusters, SSH hosts, as a connection in the gateway. Define policy rules in the learn section, specifying which groups can request access, which commands require approval, and which fields must be masked. Once the gateway is live, all traffic to those resources flows through hoop.dev, automatically generating the evidence needed for audits.
FAQ
What types of evidence does hoop.dev capture?
It records the full request and response payloads, the identity of the requester, timestamps, approval decisions, and any masking actions applied. All of these are recorded as audit entries.
Can I use hoop.dev with existing IAM solutions?
Yes. hoop.dev authenticates users via OIDC or SAML providers such as Okta, Azure AD, or Google Workspace. It then maps group membership to the gateway’s policy engine, so you can use your existing identity investments.
Do I need to modify my applications to work with the gateway?
No. Because hoop.dev operates at the protocol layer, clients continue to use their standard tools (psql, kubectl, ssh, etc.). The gateway intercepts the traffic transparently, so no code changes are required.
Explore the open‑source code on GitHub.
