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

Many assume that AI coding assistants such as GitHub Copilot automatically log every database query they generate. In reality, Copilot runs as a normal client, uses the same credentials you would give a developer, and leaves the database unaware of who or what asked for the data. Without an explicit control plane, there is no audit trail, no way to mask sensitive columns, and no gatekeeper to stop risky statements.

When a team lets Copilot write SQL against a production Postgres instance, the typical workflow looks like this: a developer enables the Copilot extension, the extension sends generated statements to the local client, the client authenticates with a static password or a service account, and the query reaches the database directly. The database sees a trusted connection and executes the statement, while the organization loses visibility into which AI‑generated statements were run, when, and by which user. The result is a blind spot that makes forensic analysis, compliance reporting, and incident response difficult.

Why the existing identity setup is not enough

Modern environments already use OIDC or SAML providers to issue short‑lived tokens for humans and service accounts. Those tokens decide whether a request may start, but they do not inspect the traffic that follows. In the Copilot scenario, the token proves that the request originates from an authorized identity, yet the request still travels straight to Postgres without any intermediate enforcement. No command‑level audit, no inline masking, and no just‑in‑time approval are applied. The identity layer alone cannot guarantee that every generated statement is recorded or that sensitive fields are hidden.

How audit trails are enforced with hoop.dev

hoop.dev is a Layer 7 gateway that sits between the AI agent and the database. It receives the OIDC‑validated identity, then proxies the connection to Postgres. Because the gateway sits in the data path, it can inspect each SQL command before it reaches the server. At that point hoop.dev records the statement, the identity that issued it, and the response. The recorded session becomes an audit trail that can be replayed later for investigation or compliance purposes.

In addition to recording, hoop.dev can mask sensitive columns in query results, ensuring that even if Copilot receives a row containing passwords or tokens, those fields are redacted before they reach the client. The gateway can also enforce just‑in‑time approvals for high‑risk operations such as schema changes or bulk deletes, routing those requests to a human approver before they are allowed to execute. All of these enforcement outcomes exist because hoop.dev is the only component that sits in the data path; the identity provider and the database remain unaware of the additional controls.

Architectural steps to protect Copilot’s Postgres access

• Deploy the hoop.dev gateway in the same network segment as the Postgres instance. The quick‑start Docker Compose file provides a ready‑made deployment that includes OIDC authentication, masking, and guardrails out of the box.
• Register the Postgres connection in the gateway configuration, supplying the host, port, and a service‑level credential that the gateway will use. Users and agents never see this credential.
• Configure GitHub Copilot (or the development environment that hosts it) to point its database client at the hoop.dev endpoint instead of the raw Postgres address. From the client’s perspective the connection works exactly the same, but the traffic now flows through the gateway.
• Define the audit policy in hoop.dev to record every statement, mask fields such as password or api_key, and require approval for DDL commands. The policy is expressed in the gateway’s declarative configuration.
• Enable session replay in hoop.dev so that any recorded interaction can be streamed back to a reviewer, providing a complete forensic record of what the AI agent did.

Because hoop.dev handles the proxying, masking, and recording, the organization gains a single source of truth for who ran which AI‑generated query and what data was returned. The audit trail can be exported to SIEMs or log stores for long‑term retention, satisfying internal governance and external audit requirements.

Getting started

The easiest way to try this approach is to follow the getting‑started guide. It walks you through deploying the gateway, configuring OIDC, and registering a Postgres target. For deeper customization, the learn section explains how to write masking rules, set up approval workflows, and enable session replay.

The full source code and contribution guidelines are available on GitHub. Explore the repository to see how the gateway is built and to contribute improvements.

FAQ

Does hoop.dev store any database credentials?

No. The gateway holds the credential only for the duration of the proxied connection. Users and AI agents never receive the raw password or IAM key.

Can I still use existing monitoring tools with hoop.dev?

Yes. hoop.dev emits audit events in standard JSON format, which can be forwarded to existing log aggregators, SIEMs, or monitoring pipelines.

What happens if an AI‑generated query tries to exfiltrate data?

hoop.dev can mask the sensitive columns before they leave the gateway, and it can block the command entirely if the policy marks the operation as disallowed. The attempt is still recorded in the audit trail.