Many teams assume that an MCP server can simply be given a database user name and password and that the server will behave like any other application client, but that approach ignores the requirements of non-human identity. The reality is that a static credential shared with a machine‑run process provides no visibility, no revocation on demand, and no protection against accidental data leakage.
When an MCP server talks directly to PostgreSQL, the connection bypasses any policy enforcement layer. The server can issue any SQL statement, read every column, and write without triggering an audit trail. If the server is compromised, the attacker inherits the same unrestricted access. This model also makes compliance reporting painful because there is no per‑request evidence of who queried what and when.
Why non-human identity matters for database access
Non‑human identities, service accounts, automation bots, or AI‑driven agents, need the same least‑privilege guarantees that human engineers receive. The goal is to grant a machine only the permissions required for a specific task, for a limited window, and to capture an audit record of every statement it runs.
In practice, the requirement looks like this:
- Assign a distinct identity to each MCP server instance.
- Scope that identity to the exact schemas, tables, or columns needed.
- Enforce a review step for any privileged command (e.g., DROP DATABASE).
- Mask sensitive columns (PII, PHI) before the data reaches the server.
- Record every query for audit and replay.
Even after these controls are defined, the request still reaches PostgreSQL directly. Without a gateway in the data path, the database itself cannot enforce the masking policy, cannot block the dangerous statement, and cannot guarantee that the recorded query matches the exact bytes that were executed.
hoop.dev as the enforceable data path
hoop.dev provides a Layer 7 gateway that sits between the MCP server and PostgreSQL. The gateway holds the database credentials, so the server does not have direct access to the password. The MCP server authenticates to hoop.dev using an OIDC token, which conveys the non‑human identity and any group memberships. hoop.dev then evaluates each incoming SQL statement against the defined policy.
When a statement arrives, hoop.dev can:
- Check the identity’s scope and reject statements that exceed it.
- Route privileged statements to a human approver before they are forwarded.
- Apply inline data masking to columns marked as sensitive, ensuring the MCP server never receives raw PII.
- Record the full command and the masked result for later replay.
All of these enforcement outcomes happen because hoop.dev is the only component that sits in the data path. The setup (OIDC provider, service‑account provisioning, and role bindings) decides who may start a connection, but the actual guardrails are enforced by hoop.dev.
Architectural walk‑through
1. Provision a service account for each MCP server in your identity provider. The account receives a minimal set of groups that map to the database scopes you intend.