AI coding agents: what they mean for your prompt-injection risk (on Postgres)

An offboarded contractor leaves behind a CI job that runs an AI coding agent, creating a prompt-injection risk. The agent keeps generating SQL snippets based on vague prompts and pushes them straight to the production Postgres cluster. Because the job uses a long‑lived service account credential, the queries execute with full read‑write rights, and no human ever sees the generated statements.

That pattern is becoming common: teams hand a language model access to a database so it can autocomplete queries, refactor schemas, or even write migration scripts. The appeal is obvious, speed, fewer manual errors, and a perception that the model will only produce safe code. In practice the model can be coaxed into emitting statements that leak data, drop tables, or exfiltrate credentials, all under the guise of a legitimate request.

Current practice with AI coding agents and Postgres

Most organizations treat the AI agent like any other application. They create a dedicated database user, store the password in a secret manager, and let the agent connect with a standard client library. The connection is direct, meaning the traffic travels from the agent process straight to the Postgres port. Auditing is limited to the database’s own log, which records the final statement but not the prompt that produced it. Masking, approval workflows, or real‑time command blocking are rarely in place because they require additional infrastructure that teams consider optional.

Because the credential is static, any compromise of the CI runner or the secret store instantly grants the attacker the same level of access. The model itself can be tricked, prompt injection, by feeding it a crafted instruction that makes it reveal internal data or execute destructive commands. The database sees only the resulting SQL, so the root cause is hidden.

Why prompt‑injection risk remains unchecked

The core of the problem is that the enforcement point sits on the wrong side of the connection. Identity and token validation happen before the request reaches Postgres, but no policy engine examines the payload. The system therefore fixes credential distribution (the agent no longer needs a human‑centered password) yet leaves the request path wide open. Without a gateway that can inspect, approve, or redact the query, the following gaps persist:

• There is no real‑time audit of which prompt produced which statement.
• Sensitive result fields cannot be masked before they reach the agent.
• Dangerous commands cannot be blocked or routed for manual approval.
• Session replay is impossible because the raw traffic is never recorded.

All of these gaps disappear the moment a layer‑7 proxy sits between the AI agent and Postgres and enforces policy on each request.

hoop.dev as the enforcement point

hoop.dev provides exactly the data‑path control that eliminates the unchecked prompt‑injection surface. By deploying the gateway inside the same network as the Postgres instance, every SQL request must pass through hoop.dev before reaching the database. The gateway reads the user’s OIDC token, determines the caller’s groups, and then applies a series of guardrails:

• Session recording: hoop.dev records the full request and response stream, creating an immutable audit trail that ties each SQL statement back to the original prompt.
• Inline masking: fields such as credit‑card numbers or personally identifiable information are redacted in the response before they ever reach the AI agent.
• Just‑in‑time approval: when a query matches a risky pattern, e.g., DROP, ALTER, or a SELECT that touches a protected table, hoop.dev routes the request to an approver instead of executing it automatically.
• Command blocking: policies can outright reject statements that exceed a defined blast radius, preventing accidental data loss.

Because hoop.dev is the only component that can see both the prompt‑derived query and the database response, it is the sole source of truth for enforcement outcomes. Removing hoop.dev would immediately restore the original insecure state where the AI agent talks directly to Postgres with no visibility or control.

Deploying hoop.dev is straightforward. The getting‑started guide walks you through a Docker Compose launch, and the learn section details how to define masking rules, approval workflows, and audit retention policies. All of the heavy lifting, credential storage, policy evaluation, and session replay, happens inside the gateway, keeping the AI agent stateless and oblivious to the underlying safeguards.

FAQ

Does hoop.dev stop all prompt‑injection attacks?

hoop.dev blocks or routes any query that matches a configured policy. If a policy does not cover a particular pattern, the query will pass through, so policy design remains critical.

Can I still use existing CI pipelines?

Yes. The CI job points its database client at the hoop.dev endpoint instead of the raw Postgres address. No code changes are required beyond the connection string.

Is the audit data stored securely?

hoop.dev writes session logs to a storage backend you configure. The logs are immutable from the perspective of the agent, and you can apply your own encryption or retention policies in that backend.

By inserting a Layer 7 gateway between AI coding agents and Postgres, you turn an open‑ended prompt‑injection problem into a set of enforceable policies. hoop.dev is the architecture that makes that possible.

Explore the open‑source repository on GitHub to see the code, contribute, or spin up your own instance.