Putting access controls around Devin: audit trails for AI coding agents (on Postgres)

A common misconception is that an AI coding assistant automatically provides reliable audit trails simply because it runs inside a container. In practice, teams often give Devin a static PostgreSQL user and password, store those secrets in a shared vault, and let the agent connect directly to the database. Every SELECT, INSERT, or schema change is executed without any record of which request originated the query, and the database itself is not configured to emit per‑user statements. When a breach occurs, there is no way to trace the exact command that the AI issued, nor to prove which downstream system invoked the agent. The lack of an immutable audit trail makes forensic analysis costly and compliance reporting impossible.

What organizations really need is a mechanism that captures every statement an AI agent sends to PostgreSQL, ties it to the originating identity, and stores the result in a tamper‑resistant log. Adding that capability alone does not solve the whole problem. Even with full query capture, the request still travels straight from the agent to the database server. There is no point where a policy engine can intervene to block dangerous commands, require a human approval for schema changes, or mask sensitive columns before they leave the database. In other words, the audit‑trail requirement is met, but the broader controls, just‑in‑time approval, inline data masking, and session replay, remain missing.

hoop.dev solves this gap by becoming the only point where traffic between an identity and PostgreSQL is inspected. It is a Layer 7 gateway that sits in the data path, proxies the connection, and enforces policy before any packet reaches the database. Because hoop.dev is the gateway, it can record each query, attach the verified user identity from the OIDC token, and write a complete audit entry that includes timestamp, source, and result. The gateway also supports inline masking of columns that contain personal data, routes risky statements to an approval workflow, and captures a full session that can be replayed later for forensic analysis.

Audit trails for AI coding agents on PostgreSQL

The audit‑trail capability works as follows. When a developer or an automated process authenticates to hoop.dev, the gateway validates the OIDC or SAML token, extracts group membership, and creates a short‑lived session context. The request is then forwarded to the PostgreSQL connector that runs inside a network‑resident agent. Before the query reaches the database, hoop.dev logs the full statement together with the identity information. After the database returns a response, hoop.dev can optionally mask fields such as credit‑card numbers or social‑security numbers, ensuring that downstream tools never see raw sensitive data.

Because hoop.dev owns the connection, it can also enforce just‑in‑time (JIT) access. If Devin attempts a destructive command like DROP TABLE or a bulk data export, the gateway can pause execution, raise an approval request to a designated reviewer, and only continue once the reviewer approves. This workflow is recorded alongside the query, giving a complete audit trail that shows who requested the operation, who approved it, and what the final outcome was.

Why the data path matters

All enforcement outcomes, query‑level audit, inline masking, JIT approval, and session recording, exist only because hoop.dev sits in the data path. The identity verification step (the “setup”) decides who may start a session, but without a gateway in the path there is no place to apply the policies. By placing the gateway between the AI agent and PostgreSQL, hoop.dev becomes the authoritative enforcement point.

Deploying the gateway for Devin

The deployment model is straightforward. First, launch the hoop.dev gateway using the Docker Compose quick‑start or a Kubernetes manifest. The gateway runs a network‑resident agent close to the PostgreSQL instance, so latency is minimal. Next, register the PostgreSQL connection in the hoop.dev console, providing the host, port, and a service‑level credential that the gateway will use. Because the credential is stored inside the gateway, Devin never sees the password or TLS key.

Finally, configure the OIDC provider (Okta, Azure AD, Google Workspace, etc.) so that hoop.dev can verify tokens and map groups to access policies. The policies define which users or service accounts may run read‑only queries, which may execute DDL, and which columns must be masked. Once the policies are in place, every session that Devin opens is automatically recorded, every query is logged with the user’s identity, and any attempt to exceed the allowed scope triggers an approval flow.

Getting started and deeper learning

For a step‑by‑step walkthrough of the deployment, refer to the getting started guide. The guide shows how to spin up the gateway, connect it to PostgreSQL, and enable audit‑trail logging. To explore the full set of features, including masking rules, approval workflows, and session replay, visit the learn page. Both resources provide the concrete configuration details you need while keeping the conceptual model clear.

Frequently asked questions

• How does hoop.dev guarantee that audit logs cannot be altered after the fact? hoop.dev writes each session record to a storage backend that is separate from the database process. Because the gateway is the sole writer, any change would require compromising the gateway itself, which is protected by the same identity verification used for access.
• Can I filter audit trails by user or by time range? Yes. Since hoop.dev attaches the verified identity to every logged statement, you can query the audit store for a specific user, role, or time window without needing to instrument the database.
• Will routing traffic through hoop.dev add noticeable latency? The gateway operates at the protocol layer and runs close to the target database, so the added round‑trip is typically only a few milliseconds, which is negligible for most workloads.

By placing a Layer 7 gateway in front of PostgreSQL, hoop.dev turns an uncontrolled AI‑driven connection into a fully observable and controllable data path. The result is a reliable audit‑trail foundation that satisfies forensic, compliance, and security requirements while still enabling Devin to write code efficiently.

Explore the source code, contribute enhancements, and see the full implementation on GitHub.