AI coding agents: what they mean for your access reviews (on Postgres)

A newly hired contractor leaves the company, but the CI pipeline she helped build an AI coding agent that drafts SQL statements for performance‑tuned reporting. The agent pulls credentials from a shared configuration file and talks directly to the production Postgres cluster. When the contractor’s account is disabled, the agent continues to execute queries because it never authenticates as a person.

It also shows why access reviews must account for non‑human actors that inherit privileged credentials.

That pattern is becoming common. Teams embed large‑language‑model assistants in their development workflow: an IDE plugin suggests a query, a CI job asks the model to generate migration scripts, or an automated bot writes data‑access code. The model itself does not have a human identity, yet it inherits whatever permissions the underlying service account possesses. For anyone responsible for access reviews, the question is no longer "who can run psql?" but "what does an autonomous agent do with the rights it inherits?"

Why traditional access reviews miss AI‑driven activity

Conventional access reviews focus on static identities, users, service accounts, and groups. Reviewers look at role assignments, expiration dates, and the resources those roles cover. An AI coding agent sidesteps that model in two ways. First, the agent is not a distinct identity; it runs under an existing service account that may have broad database privileges. Second, the agent’s behavior changes at runtime: a single request can produce a complex series of DDL and DML commands that were never anticipated when the original role was granted.

The result is a blind spot. Even if you prune user accounts regularly, the underlying service account remains untouched, and the agent continues to act with the same level of access. Auditors who rely on static permission matrices will see a clean sheet, while the actual data‑plane activity tells a different story.

What to watch for in access reviews when AI agents touch Postgres

• Identify the execution context. Trace every CI job, bot, or IDE extension that can invoke the language model. Record the service account or credential it uses.
• Map generated queries to risk categories. Not all SELECTs are equal. Look for DML, DDL, or queries that reference sensitive columns such as SSN, credit‑card numbers, or PII.
• Enforce just‑in‑time (JIT) temporary write permission. Instead of granting permanent write access, require an explicit approval step each time the agent attempts a high‑risk operation.
• Capture a complete audit trail. Session‑level logs that include the exact query text, timestamps, and the originating request ID are essential for downstream review.
• Apply inline data masking. When the agent reads rows that contain regulated data, mask those fields before they reach downstream tools or logs.

These controls shift the focus from static role inventories to dynamic, request‑level enforcement. They also create evidence that satisfies auditors looking for “who did what, when, and why.”

How hoop.dev provides the missing enforcement layer

hoop.dev is a Layer 7 gateway that sits between identities, human users, CI pipelines, and AI coding agents, and the Postgres database. The gateway is the only place where enforcement can happen. It verifies OIDC or SAML tokens to decide who is making a request (the setup step), then inspects every SQL packet before it reaches the database.

Because hoop.dev controls the data path, it can:

• Record each session, preserving the full query stream for replay and audit.
• Preserve logs in an immutable store that prevents any post‑creation modification.
• Mask sensitive columns in real time, ensuring that downstream logs never expose raw PII.
• Require just‑in‑time approval for DML or DDL statements that match a risk policy.
• Block commands that violate predefined guardrails, such as DROP DATABASE or ALTER USER.

All of these outcomes exist only because hoop.dev sits in the data path. If you removed the gateway but kept the same OIDC configuration, the service account would still have unchecked access, and none of the above protections would apply.

Integrating hoop.dev into an existing Postgres environment

Deploy the gateway close to the database, either via Docker Compose for a quick start or as a sidecar in Kubernetes for production workloads. Register the PostgreSQL target in the gateway, supplying the host, port, and a credential that the gateway alone can use. Users and agents then connect through hoop.dev using their normal client tools (psql, pgAdmin, or any library) without any code changes.

The gateway reads the caller’s OIDC token, extracts group membership, and applies the policy you have defined. For AI coding agents, you typically grant a minimal read‑only role at the token level and let hoop.dev grant temporary write access when an approved JIT request arrives. This pattern keeps the service account’s baseline privileges low while still enabling the agent to perform its job when needed.

For step‑by‑step guidance, see the getting started guide and the broader runtime governance documentation. Both resources explain how to configure PostgreSQL connections, define masking rules, and set up approval workflows.

Conclusion

AI coding agents expand the attack surface of your PostgreSQL deployments by introducing dynamic, credential‑driven behavior that traditional access reviews do not capture. To keep reviews meaningful, you must add request‑level controls, real‑time masking, and immutable session logs. hoop.dev supplies exactly that enforcement layer, turning the gateway into the single point where every query can be inspected, approved, or blocked.

Explore the open‑source implementation on GitHub: hoop.dev repository.