An offboarded contractor’s CI pipeline still pushes queries to your Postgres instance through an MCP gateway, exposing prompt-injection risk. The pipeline reuses a service‑account token that was never rotated, and the queries contain dynamically generated prompts that are fed to a large language model for code suggestions. Because the gateway simply forwards the traffic, a malicious prompt can cause the model to retrieve or modify data it should never see. The organization relies on the fact that the database itself enforces row‑level permissions, but the prompt-injection vector bypasses those checks, leaking sensitive columns in model responses. Without a control point that can inspect and filter the content flowing through the gateway, the risk remains invisible until an audit discovers unexpected data exfiltration.
Why prompt‑injection risk matters for MCP gateways
Prompt‑injection risk is the possibility that an adversary can influence the text sent to a language model in a way that causes the model to reveal or act on data it should not. In an MCP gateway scenario the model sits downstream of the gateway, so any prompt that reaches it originates from the client side of the connection. If the gateway does not examine the payload, an attacker who gains the ability to craft a query can embed malicious instructions that cause the model to output confidential schema, passwords, or business logic.
The missing enforcement layer
Most organizations rely on three pieces of setup: an identity provider that issues OIDC or SAML tokens, a service account that holds static credentials for the database, and network rules that allow the MCP gateway to reach Postgres. This setup decides who may start a session, but it does not enforce what the session can do once the traffic reaches the gateway. The request still travels directly to the database and then to the model without any intermediate inspection. Consequently, there is no audit of the exact prompts, no real‑time masking of sensitive fields, and no way to require a human to approve risky queries.
hoop.dev as the data‑path gateway
hoop.dev is a Layer 7 gateway that sits in the data path between the client and Postgres. By placing the enforcement point in the gateway, hoop.dev becomes the only component that can inspect, transform, and log the traffic before it reaches the database or the model. The gateway integrates with existing identity providers, so the setup stage still determines who may connect, but all policy decisions happen inside hoop.dev.