A common misconception is that running a self-hosted stack automatically guarantees in-transit data governance while data moves between services. The reality is that without an explicit control plane, traffic can be inspected, altered, or logged by any component that sits on the network path.
In-transit data governance means applying confidentiality, integrity, and audit policies to every packet that travels between a client and a resource. It includes masking sensitive fields, blocking dangerous commands, requiring human approval for risky operations, and recording the entire session for later replay.
Why in-transit data governance matters for self-hosted models
Self-hosted models give teams full ownership of compute, storage, and networking. That ownership often leads to the belief that "we control everything," so additional safeguards are unnecessary. In practice, three gaps appear:
- Credentials are stored on the host and may be exposed to any process that can read them.
- Network traffic between services travels over internal subnets where privileged pods or compromised agents can sniff data.
- Auditors and incident responders have little visibility into who ran what command and what data was returned.
These gaps exist even when the initial setup, identity providers, OIDC tokens, IAM roles, or service accounts, correctly identifies the requester. Setup decides who may start a connection, but it does not enforce what happens once the connection is open.
The data path is the only place to enforce governance
Because enforcement must happen where the bytes flow, the gateway that sits between the identity layer and the target resource becomes the enforcement point. No matter how fine-grained the access token is, once the request leaves the authentication check it can no longer be altered by the token itself. The gateway can inspect the protocol, apply policies, and decide whether to allow, mask, or abort each operation.
hoop.dev provides the required data-path enforcement
hoop.dev is a Layer 7 gateway that inserts itself on the connection path for databases, Kubernetes clusters, SSH, RDP, and HTTP services. By deploying a network-resident agent next to the target, hoop.dev intercepts every request and response. It then:
- Masks configured sensitive fields before they reach the client, ensuring that credit-card numbers or personal identifiers never leave the server in clear text.
- Blocks commands that match a deny list, preventing destructive actions from being executed.
- Routes high-risk operations to a human approver, adding a just-in-time approval step.
- Records the full session, enabling replay and forensic analysis without exposing the underlying credential.
All of these outcomes are possible only because hoop.dev sits in the data path. The identity layer supplies the user’s token, but hoop.dev is the component that actually enforces masking, approval, and audit.
How hoop.dev integrates with self-hosted deployments
To bring hoop.dev into a self-hosted environment, teams deploy the gateway using Docker Compose or a Kubernetes manifest. An agent runs on the same network segment as the target service, holding the service credentials so that users never see them. Identity is handled via OIDC or SAML; hoop.dev validates the token, extracts group membership, and then applies the appropriate policy set.
The workflow looks like this:
- Engineer authenticates to the corporate IdP and receives an OIDC token.
- hoop.dev verifies the token and maps the user to a policy profile.
- The user’s client (psql, kubectl, ssh, etc.) connects to hoop.dev instead of the raw endpoint.
- hoop.dev’s data-path inspects each request, masks or blocks as defined, and records the session.
This pattern works for any self-hosted resource, whether it is a PostgreSQL database behind a private subnet or a Kubernetes cluster that developers access for debugging. Because the gateway is the only place where traffic can be altered, it provides a single source of truth for in-transit data governance.
Getting started
For a step-by-step walkthrough, see the getting-started guide. The documentation also explains how to define masking rules, deny lists, and approval workflows in the learn section. All of the configuration lives in open-source files that you can version-control alongside your infrastructure code.
By placing a purpose-built gateway in the data path, self-hosted teams can finally claim true in-transit data governance without relying on ad-hoc network tricks or custom scripts.
Explore the hoop.dev source code on GitHub to see how the project is built and to contribute your own extensions.
