Why does just-in-time access matter when you let an MCP server talk to PostgreSQL?
Why static credentials are a liability
Most teams that run PostgreSQL workloads still rely on a handful of long-lived usernames and passwords stored in configuration files or secret managers. Those credentials are often shared among engineers, scripts, and CI pipelines. When a breach occurs, the attacker inherits every permission that the static account holds, and the organization has no clear record of who issued which query. The database itself sees only a single client identity, so it cannot attribute actions to individual users or services. Auditors therefore struggle to prove that privileged commands were executed only by authorized personnel.
In addition, the same set of credentials is used for ad‑hoc debugging, routine data pulls, and automated jobs. The lack of temporal scoping means that a developer who needed access for a short investigation retains that power indefinitely. This creates a large attack surface and makes it difficult to enforce the principle of least privilege.
The missing piece in just-in-time access
Just-in-time access promises to grant a user a narrowly scoped permission for the exact duration needed. In practice, teams often implement the request‑and‑approval workflow in an identity provider or ticketing system, but the actual database connection still goes directly from the client to PostgreSQL. The request may be approved, yet the connection bypasses any enforcement point. That means the database continues to see an unmediated session, with no real‑time masking of sensitive columns, no command‑level blocking, and no immutable audit trail of the query stream. The approval process alone does not protect the data path.
Without a gateway that sits between the requester and the database, the organization cannot guarantee that the granted privilege is enforced at the moment of execution. The request may be valid, but the database remains exposed to accidental or malicious statements, and there is no built‑in replay capability for forensic analysis.
Introducing hoop.dev as the data‑path gateway
hoop.dev is a layer‑7 gateway that proxies PostgreSQL connections. By placing hoop.dev in the data path, every request must travel through the gateway before reaching the database. The gateway reads the user’s OIDC token, extracts group membership, and applies a just‑in‑time policy that limits the session to the approved scope and time window.
How the gateway enforces just-in-time access
When a user initiates a connection to an MCP server that talks to PostgreSQL, hoop.dev validates the token against the configured identity provider. It then checks the request against an approval workflow. If the request is approved, hoop.dev creates a short‑lived session that is bound to the specific database role required for the task. The session expires automatically when the approved window ends, preventing any further commands.
Inline masking and audit logging
hoop.dev inspects each query and response at the wire‑protocol level. It can redact columns that contain personally identifiable information before the data reaches the client, ensuring that even a privileged user never sees raw PII. Every statement is recorded with the user’s identity, timestamp, and outcome, producing a query‑level audit log that can be replayed for investigations. The gateway also blocks dangerous statements such as DROP DATABASE or ALTER ROLE when the policy disallows them.
Getting started
To adopt this approach, deploy the hoop.dev gateway in the same network segment as your PostgreSQL cluster. Register the database as a connection in the gateway configuration, and let the gateway store the database credentials so that engineers never handle them directly. Configure OIDC authentication with your identity provider, and define a just‑in‑time policy that ties approval requests to specific MCP server operations. The official getting‑started guide walks you through the Docker Compose deployment, the connection registration steps, and the policy creation workflow.
For detailed instructions, see the getting‑started documentation. The broader feature set, including masking rules and guardrails, is described in the learn section. The complete source code and contribution guidelines are available on GitHub.
View the source on GitHub to explore the implementation details and start contributing.
FAQ
- Can I use existing PostgreSQL users with this setup? Yes. hoop.dev can proxy connections using a dedicated service account while still mapping each request to the original user’s identity for audit purposes.
- What happens if an approval expires while a query is still running? The gateway terminates the session as soon as the approved window ends, ensuring that no further commands are processed.
- Is the masking performed on the client side? No. Masking occurs inside the gateway before the data leaves the data path, so the client never receives unredacted sensitive fields.
