Configuring AI coding agents access to Postgres with non-human identity

When an AI coding agent is given unfettered access to a production database, the organization inherits the same risks it faces when a developer checks a shared password into source control. Using a non-human identity for that agent changes the security calculus. Accidental queries can corrupt data, exfiltrate personally identifiable information, or trigger costly compliance violations. The financial and reputational impact of a single rogue query often far exceeds the modest effort required to secure the connection.

Most teams today solve the problem by creating a single database user for the agent, embedding the password in CI pipelines, or granting the agent the same role as a human engineer. Those approaches give the agent more privileges than it needs, leave no trail of what was run, and make it impossible to redact sensitive columns on the fly. In practice the agent reaches PostgreSQL directly, meaning the database itself must enforce all guardrails, masking, and logging.

Introducing a non-human identity changes the first part of the equation. Instead of a static password, the agent authenticates with an OIDC token that represents a service account. The token can be scoped to a specific database schema, a limited time window, or a particular set of tables. This reduces the attack surface and aligns the agent with the principle of least privilege. However, the request still travels straight to the PostgreSQL endpoint, so enforcement must happen before the database sees the command.

That is where a data‑path gateway becomes essential. hoop.dev sits between the identity layer and the PostgreSQL server, acting as a wire‑protocol proxy. By placing enforcement at the gateway, every query passes through a single control surface that can apply policy before the database ever sees the command.

Why non‑human identity matters for AI agents

Non‑human identities give you granular control over who, or what, can talk to PostgreSQL. An AI coding agent can be issued a short‑lived token that only allows SELECT on a reporting schema. When the token expires, the agent loses access without any manual revocation. This model eliminates credential sprawl and makes it easy to rotate secrets centrally.

How hoop.dev enforces policy on the PostgreSQL wire protocol

When the agent presents its OIDC token, hoop.dev validates the token, extracts the group or role information, and maps it to a named identity that the gateway uses to talk to the database. The gateway holds the actual PostgreSQL credentials, so the agent does not obtain the database password directly. As each SQL statement flows through the proxy, hoop.dev can:

• Record the exact query and the identity that issued it, creating a replayable audit trail.
• Mask columns that contain PII or PHI, ensuring that sensitive data never leaves the gateway in clear text.
• Block dangerous statements such as DROP TABLE or ALTER SYSTEM, optionally routing them for human approval before execution.
• Enforce just‑in‑time access windows, denying any request that falls outside the token’s validity period.

All of these controls happen before the command reaches PostgreSQL, guaranteeing that the database sees only vetted, authorized traffic.

Architectural steps to grant AI agents non‑human identity access

Deploy the hoop.dev gateway using the getting‑started guide. Register the PostgreSQL instance as a connection, providing the host, port, and a service‑level credential that the gateway will use. Configure an OIDC provider (Okta, Azure AD, Google Workspace, etc.) so that the gateway can verify tokens issued to the AI agent’s service account. Finally, enable the masking and guardrail policies you need through the feature documentation. The result is a fully audited, policy‑driven path from a non‑human identity to PostgreSQL.

Benefits you gain immediately

With hoop.dev in place, every query from the AI agent is captured in a recorded session log, providing evidence for security reviews and compliance audits. Inline masking ensures that even if the agent is compromised, it cannot exfiltrate raw PII. Guardrails prevent accidental schema changes, and just‑in‑time token scopes keep the agent’s privileges tightly bounded. All of these outcomes rely on the gateway being the sole enforcement point; removing it would eliminate the audit trail, masking, and approval workflow.

FAQ

Can I use existing PostgreSQL roles instead of hoop.dev?

PostgreSQL roles can enforce some permissions, but they cannot provide session‑level recording, inline masking, or dynamic approval workflows. Those capabilities require a proxy that sits in the data path, which is exactly what hoop.dev provides.

What happens if the AI agent’s token is compromised?

The token’s scope and expiration are defined at issuance. Even if an attacker obtains the token, they can only perform the actions allowed by that non‑human identity, and every command will still be logged and subject to masking and guardrails enforced by hoop.dev.

Do I need to change my application code?

No. The AI agent simply points its PostgreSQL client at the hoop.dev endpoint instead of the database host. The proxy speaks the native PostgreSQL wire protocol, so existing tools (psql, pgadmin, ORM libraries) work without modification.

Explore the open‑source repository on GitHub: https://github.com/hoophq/hoop