How can you prove, day after day, that every access to your self‑hosted services generates reliable compliance evidence while still meeting internal policies and external regulations?
Most teams that run their own databases, Kubernetes clusters, or SSH endpoints rely on ad‑hoc log exports, manual ticketing, or occasional snapshots to satisfy auditors. Those artifacts are often incomplete, stored on the same host they describe, and lack the context needed to answer “who did what, when, and why?”. The result is a compliance program that looks good on paper but collapses under scrutiny because evidence cannot be reproduced reliably.
Regulators and internal auditors expect continuous, tamper‑resistant evidence that ties each request to a verified identity, shows the exact commands executed, and records any data that left the system. They also want to see that sensitive fields, personal identifiers, credit‑card numbers, health records, are protected even when they appear in responses. Achieving that level of proof with a purely self‑hosted stack is difficult because the control point is scattered across many services.
The missing piece is a single, identity‑aware gateway that sits on the only path between the requester and the target. Without such a gateway, a user can still connect directly to the database or SSH server, bypassing any policy engine. The authentication layer (OIDC, SAML, service accounts) decides who *may* start a session, but it does not enforce what can happen once the connection is open. Consequently, you end up with a system that knows who logged in, but not what they actually did, and you have no reliable way to mask or block risky operations.
Why a data‑path gateway is required for true compliance evidence
To turn a collection of logs into actionable compliance evidence, the enforcement point must be the data path itself. Only a gateway that proxies the wire‑level protocol can see every query, command, or file transfer in real time. It can then apply three essential controls:
- Session recording. Every byte that travels between client and server is captured, creating an immutable replay that auditors can review.
- Inline data masking. Sensitive fields are redacted or tokenized before they leave the target, ensuring that logs never expose protected data.
- Just‑in‑time approval and command blocking. Risky operations are either routed for human approval or rejected outright before they reach the backend.
These outcomes exist only because the gateway sits in the data path. If you remove the gateway, you lose the ability to record, mask, or approve commands, even though the identity system may still be in place.
hoop.dev as the compliance‑focused data‑path gateway
hoop.dev implements exactly this architectural requirement. It is a Layer 7 proxy that runs alongside your self‑hosted resources. Identity is still handled by your existing OIDC or SAML provider; hoop.dev validates the token and extracts group membership, but the real enforcement happens inside the gateway.
When a user or automated agent initiates a connection, hoop.dev performs the following steps:
- It verifies the identity token (the setup step that decides who may start).
- It establishes a secure tunnel to the target resource, using credentials that only the gateway possesses.
- It inspects each protocol message, applying the configured policies.
- It records the entire session, masks any configured sensitive fields, and, if required, pauses execution for a just‑in‑time approval workflow.
Because hoop.dev is the only component that sees the traffic, it can generate compliance evidence that meets the continuous‑recording requirement. The evidence is stored outside the target, making it resistant to tampering by anyone who controls the underlying service.