AI coding agents: what they mean for your least privilege (on Postgres)

AI coding agents can break least privilege in your Postgres environment with a single request.

Most teams hand a service account a static username and password, then let the agent run any query it wants. The credential is stored in a CI secret store, checked out by the pipeline, and shared across dozens of jobs. Because the agent authenticates directly to the database, the database sees only a single user identity and cannot distinguish which job issued which statement. There is no per‑request audit, no real‑time approval, and no way to hide sensitive columns from the agent.

That approach looks convenient. The pipeline runs faster, the developers do not have to manage multiple keys, and the ops team believes the static account is “locked down enough.” In practice the static account often has read‑write rights on every schema, full access to system tables, and the ability to export whole tables. When an AI agent generates a query to refactor code, it may also pull customer PII, credit‑card numbers, or internal secrets without anyone noticing.

Why AI coding agents break least privilege

AI agents are non‑human identities. They do not have a job title, a manager, or a time‑boxed task. When you grant them a broad database role, you are effectively giving a bot the same level of access you would give a senior DBA. The agent can run DDL, drop tables, or grant its own privileges to other roles. Because the database does not see the original requestor, any downstream breach looks like a normal query from the service account.

Least privilege means each identity can perform only the actions required for its specific job, and only for the time that job is active. With a static credential, the agent violates that principle in three ways: (1) it holds more permissions than necessary, (2) it holds them indefinitely, and (3) the database cannot attribute actions to a human reviewer. The result is a larger blast radius and no evidence for auditors.

Restoring true least privilege with a data‑path gateway

Enter a Layer 7 gateway that sits between the AI agent and Postgres. hoop.dev acts as the only point where traffic is inspected, approved, and recorded. The gateway receives the agent’s OIDC token, validates the identity, and then decides whether the request may proceed. All enforcement happens inside the gateway, never inside the database or the agent process.

Setup – You provision a non‑human OIDC client for the AI service and assign it a minimal role in your identity provider. The token tells hoop.dev who the requester is, but the token alone does not grant any database rights.

The data path – The gateway terminates the Postgres wire protocol, injects its own short‑lived database credential, and forwards the request to the target. Because the gateway is the only component that can speak the database protocol, it is the sole place where policy can be enforced.

Enforcement outcomes – hoop.dev records every session, so you have a complete audit trail that ties each query back to the originating AI token. It can mask columns that contain PII in real time, ensuring the agent never sees raw sensitive data. If a query attempts a privileged operation, hoop.dev blocks it or routes it for human approval before execution. All of these controls exist because the gateway sits in the data path.

With this architecture, the AI agent never holds a static database password. The credential lives inside the gateway and is rotated automatically. The agent presents a short‑lived token, the gateway checks the token against your identity provider, and then decides – based on a policy that enforces least privilege – whether to allow the query, mask the response, or require approval.

Because enforcement is centralized, you can change policies without redeploying every pipeline. Adding a new masking rule or tightening a role is a single configuration change in the gateway, and it takes effect for all agents immediately.

For teams that want to get started quickly, the getting‑started guide shows how to deploy the gateway with Docker Compose and connect an OIDC provider. The learn section dives deeper into masking, approval workflows, and session replay. Both resources assume you already have an identity provider and a Postgres cluster ready to be protected.

By moving the enforcement point to the data path, you finally achieve true least privilege for AI coding agents: the agent only gets the exact permissions it needs for the moment it needs them, and every action is captured for audit and replay.

Explore the open‑source repository on GitHub to try it yourself: github.com/hoophq/hoop.