Putting access controls around GitHub Copilot: session recording for AI coding agents (on Postgres)

A contractor who once had read‑only access to a codebase leaves the organization, but the CI pipeline still runs a GitHub Copilot‑powered assistant that writes SQL against a production PostgreSQL instance. The assistant never logs its queries, and the team has no way to prove what data it touched before the bug was discovered.

When AI coding agents interact with databases, the lack of session recording creates a blind spot for any internal developer who runs Copilot locally. The model can suggest INSERTs, UPDATEs, or SELECTs that expose sensitive rows, and without a reliable audit trail the organization cannot answer compliance questions or investigate incidents. This is where session recording becomes essential.

To mitigate that risk, the control must sit on the data path, not in the client or the AI service. A dedicated gateway can inspect every wire‑level request, enforce policies, and record the full interaction before it reaches PostgreSQL.

Why session recording matters for AI‑driven database access

Session recording captures the complete request‑response exchange, including the exact SQL statements generated by the AI, the parameters supplied, and the results returned. With that evidence you can:

• Demonstrate compliance with internal governance and external audit requirements.
• Identify accidental data exposure or malicious manipulation caused by an AI suggestion.
• Replay a session to reproduce a bug or verify that a remediation step succeeded.
• Provide forensic context for post‑mortem analysis without relying on the AI service’s internal logs.

Because the AI model runs in a separate process, its own logs are not trustworthy for security purposes. Only a component that cannot be tampered with by the client can guarantee an immutable record.

How hoop.dev captures sessions for GitHub Copilot

hoop.dev acts as a Layer 7 gateway that terminates the PostgreSQL protocol on behalf of the client. The flow looks like this:

1. Developers or CI jobs authenticate to hoop.dev using OIDC or SAML tokens issued by the corporate IdP.
2. The gateway validates the token, extracts group membership, and decides whether the request is allowed.
3. When a request is permitted, hoop.dev forwards it to the PostgreSQL server using a credential that only the gateway knows. The client never sees the database password.
4. Before forwarding, hoop.dev records the raw query and, after receiving the response, records the result set. Both are stored in an audit log.
5. If a policy requires inline masking, such as redacting credit‑card numbers, hoop.dev rewrites the response before it reaches the client.

Because hoop.dev is the only component that sees both the inbound query and the outbound response, it is the sole source of truth for session recording. Removing hoop.dev would eliminate the guarantee that every interaction is captured.

Designing the data path for AI agents

The architecture separates three responsibilities:

• Setup: Identity providers, service accounts, and least‑privilege roles determine who may start a connection. This step authenticates the user but does not enforce any data‑level policy.
• The data path: hoop.dev sits between the AI‑enabled client and PostgreSQL. All traffic must traverse this gateway, making it the only place enforcement can happen.
• Enforcement outcomes: hoop.dev records each session, masks sensitive fields, and can require just‑in‑time approval for risky statements. Those outcomes exist solely because the gateway controls the flow.

By placing the gateway inside the same network segment as the database, you eliminate the need for VPNs or bastion hosts while still retaining full audit visibility.

Getting started with hoop.dev

Implementing session recording for GitHub Copilot follows the same steps as any other PostgreSQL connection. Begin with the official getting started guide to deploy the gateway. The guide walks you through:

• Running the Docker Compose quick‑start, which provisions the gateway and an agent near your database.
• Registering the PostgreSQL target and attaching the credential that the gateway will use.
• Configuring OIDC authentication so that developers and CI pipelines can obtain short‑lived tokens.
• Enabling the session‑recording feature in the policy definition.

All of the detailed configuration lives in the documentation and the open‑source repository. For the exact manifest files and policy syntax, see the learn page, which explains how to tailor masking rules and approval workflows to your organization’s risk profile.

FAQ

Does hoop.dev store the recorded sessions?

hoop.dev writes each session to an audit store that you provision. The store can be an object bucket, a database, or any durable backend supported by the platform. The important point is that the storage is external to the client and under your control.

Can I disable recording for low‑risk queries?

Yes. Policies are expressive enough to enable recording only for statements that match certain patterns, such as DDL or data‑exfiltration queries. The default policy records everything, which is the safest baseline.

What happens if an AI‑generated query tries to drop a table?

hoop.dev evaluates the statement against the policy before forwarding it. If the policy blocks destructive commands, the gateway returns an error to the client and logs the attempt, providing both protection and evidence.

By treating the gateway as the single enforcement point, you gain confidence that every AI‑driven interaction with PostgreSQL is observable and controllable.

Explore the source code and contribute on GitHub.