How can an automated MCP server use a non-human identity to talk to PostgreSQL without exposing static passwords or losing visibility?
Most teams provision a service account, embed its credentials in CI pipelines, and point the server directly at the database host. The approach works, but it leaves three critical gaps. First, the credential lives in clear text inside build artefacts, creating a high-value target for attackers. Second, every query runs with the same privileged role, making it impossible to enforce least-privilege per request. Third, because the connection bypasses any control layer, there is no central audit log, no inline masking of sensitive columns, and no opportunity to pause a risky statement for human approval.
Addressing the identity problem alone does not close those gaps. Even when you switch to a non-human identity managed by your OIDC provider, the request still travels straight to PostgreSQL. The database sees a regular client connection, and the gateway that could enforce policies, record each statement, and redact PII never sees the traffic. In other words, the setup provides authentication but no enforcement.
Enter hoop.dev. By placing hoop.dev’s Layer 7 gateway between the MCP server and PostgreSQL, every packet passes through a data‑path that can apply the missing controls. hoop.dev authenticates the MCP server with a non-human identity token, then proxies the wire‑protocol connection to the database. Because the gateway owns the database credential, the server does not have access to the password. More importantly, hoop.dev can record each SQL statement, mask configured sensitive fields in result sets, and block or route dangerous commands for manual approval before they reach the database engine.
Why non-human identity needs a gateway
Non-human identities, service accounts, bots, or CI runners, are designed for automation, not for human oversight. Without a dedicated enforcement point, they inherit all the privileges of the underlying database user. This creates a blast radius problem: a compromised CI token can dump entire tables or alter schema. Moreover, compliance regimes often require evidence that every automated query was reviewed or at least logged. When the connection goes straight to PostgreSQL, the only audit source is the database’s own log, which typically does not include the originating service identity or masking actions.
How hoop.dev enforces non-human identity for Postgres
hoop.dev’s architecture separates three concerns:
- Setup: An OIDC or SAML provider issues a token that represents the MCP server. The token carries the non-human identity and any group membership needed for policy decisions.
- The data path: The hoop.dev gateway receives the token, validates it, and then establishes a native PostgreSQL wire‑protocol session on behalf of the server. Because the gateway is the only point that can speak to the database, it is the sole place where enforcement can happen.
- Enforcement outcomes: While the session is active, hoop.dev records every SQL statement with the originating non-human identity, applies column‑level masking to redact PII, and evaluates guardrails that can block statements such as DROP DATABASE or DELETE FROM users WHERE. If a statement matches a high‑risk policy, hoop.dev routes it to an approval workflow before forwarding it to PostgreSQL.
The result is a complete audit trail that shows who (the service account), what (the exact query), and when (timestamped session). Because masking occurs inline, downstream consumers never see raw sensitive data, satisfying privacy requirements without additional application code.
Getting started with hoop.dev and PostgreSQL
To adopt this pattern, follow the high‑level steps outlined in the official getting‑started guide. Deploy the hoop.dev gateway using the provided Docker Compose file or your preferred orchestration platform. Register a PostgreSQL connection in the gateway, supplying the database host and a credential that the gateway will manage. Finally, configure an OIDC client for your MCP server so it can obtain a non-human identity token and connect through the gateway’s address instead of the database directly.
The documentation walks you through each of these phases, from installing the gateway to defining masking rules for specific columns. Because the process is declarative, you can version‑control the policy definitions and roll them out across environments without touching application code.
FAQ
Do I still need to rotate the PostgreSQL password?
Yes, but rotation happens in the gateway’s secret store, not in every CI pipeline. The MCP server never receives the password, so rotation does not require a code change.
Can I use existing IAM roles for RDS instead of a static DB user?
Absolutely. hoop.dev supports per‑user IAM authentication for Amazon RDS, allowing the gateway to obtain short‑lived tokens on behalf of the non-human identity.
Masking is performed at the protocol layer after the database returns the result set. In most workloads the overhead is negligible, and you gain the security benefit of never exposing raw PII to downstream services.
Ready to try it? Clone the open‑source repository and start the quick‑start: https://github.com/hoophq/hoop. For deeper guidance, see the getting‑started guide and the learn section for detailed feature explanations.
