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

A contractor who was recently offboarded still has a CI pipeline that invokes GitHub Copilot to generate SQL against a production PostgreSQL cluster. The pipeline runs nightly, and the generated statements are sent directly to the database using a static service‑account password stored in the repository. No one sees the exact queries, no approval step exists, and the credentials never change, even after the contractor leaves.

When an AI coding agent like Copilot is granted production access, it inherits the same risks as any human with a privileged credential: it can unintentionally expose personally identifiable information, run destructive DDL, or create queries that bypass business‑logic constraints. Because the agent’s output is code, the risk surface expands – a single suggestion can translate into dozens of statements that touch sensitive tables. Organizations that treat production data as a high‑value asset need a way to see exactly what an AI writes, to hide columns that should never leave the database, and to require a human sign‑off before dangerous operations are executed.

Production access, in this context, means that every piece of code generated by GitHub Copilot that touches a live PostgreSQL instance is subject to the same guardrails that protect human engineers. The guardrails include real‑time query inspection, inline masking of confidential fields, just‑in‑time (JIT) approval for high‑risk commands, and immutable session logs that can be replayed for audit or forensic analysis.

Most teams today solve the problem by creating a service account, giving it a long‑lived password, and configuring the CI job to use that credential. The identity that launches the job is often a generic CI token, which satisfies the authentication requirement but provides no visibility into which AI‑generated statements actually reach the database. The request still travels straight to PostgreSQL, bypassing any point where policy could be enforced. Even if the CI system integrates with an OIDC provider, the token only decides whether the job may start; it does not mediate the data path.

Enter hoop.dev. hoop.dev is a Layer 7 gateway that sits between the AI agent (or the CI job that invokes it) and the PostgreSQL target. It authenticates callers via OIDC/SAML, holds the database credential itself, and inspects every wire‑protocol message before it reaches the server. Because hoop.dev is the only place the traffic passes, it can apply the full suite of production‑access controls.

How hoop.dev enforces production access for GitHub Copilot

When the CI job asks Copilot to generate a query, the resulting SQL is sent to hoop.dev instead of directly to PostgreSQL. hoop.dev validates the caller’s token, maps the identity to a set of permissions, and then evaluates the query against a policy engine. If the statement attempts to read or write a column marked as sensitive, hoop.dev masks the value in the response so that downstream logs never contain raw data. If the query includes a DDL operation, hoop.dev routes it to a human approver and blocks execution until the approval is recorded. Every command – successful or blocked – is captured in a session record that can be replayed later.

Because hoop.dev holds the database password, the AI agent never sees the credential. The agent only presents a short‑lived OIDC token, which hoop.dev verifies before allowing any traffic. This separation means that revoking the token instantly cuts off access without having to rotate the database password.

In practice, hoop.dev provides four concrete outcomes that satisfy production‑access requirements:

• hoop.dev records each session, providing an audit trail for every AI‑generated statement.
• hoop.dev masks sensitive fields in query results, preventing accidental data leakage.
• hoop.dev blocks dangerous commands and routes them for just‑in‑time human approval.
• hoop.dev enforces least‑privilege scoping by granting the AI agent only the database roles needed for its specific task.

These outcomes exist only because the enforcement point is inside the data path. If the gateway were removed, the same OIDC token would still allow the CI job to connect, but none of the masking, approval, or recording would occur.

Deploying the solution

The deployment model follows the standard hoop.dev quick‑start. A Docker‑Compose file brings up the gateway and a network‑resident agent that lives next to the PostgreSQL instance. The gateway is configured with the PostgreSQL host, port, and a service‑account credential that it alone manages. Identity providers such as Okta, Azure AD, or Google Workspace are added as OIDC sources, allowing the CI job to obtain a short‑lived token for each run.

Once the gateway is running, the CI pipeline is changed to point its database URL at the hoop.dev endpoint instead of the raw PostgreSQL address. From that point forward, every query generated by GitHub Copilot passes through the gateway, where the policies described above are applied automatically.

All of the configuration details – how to define a connection, how to set up OIDC, how to write masking rules – are covered in the official getting‑started guide and the broader learning portal. Those resources walk you through the exact steps without exposing any code snippets here.

Why this matters for compliance and risk management

Regulatory frameworks often require evidence that production data is accessed only by authorized entities and that every access is logged. hoop.dev generates the audit evidence teams need for such programs by capturing full session logs and approval records. Because the masking happens before data leaves the database, the logs themselves do not become a source of leakage, which simplifies the evidentiary trail.

From a risk‑management perspective, the blast radius of a compromised AI token is dramatically reduced. The token can be revoked instantly, and any attempt to run a prohibited command will be stopped at the gateway. This design also makes it easier to enforce separation of duties – for example, allowing the AI to read but never write to certain schemas.

FAQ

Q: Does hoop.dev store the PostgreSQL password?
A: Yes, the gateway stores the credential and presents it to the database on behalf of the caller. The caller never sees the password.

Q: Can I see the raw SQL generated by Copilot?
A: hoop.dev records the exact statements in the session log. If a statement is blocked, the log still shows the attempted query.

Q: How does masking work for column values?
A: When a query returns rows that contain columns marked as sensitive, hoop.dev replaces those values with a placeholder before the response is sent back to the client.

Next steps

Start by reviewing the getting‑started documentation to spin up a test gateway. Then explore the policy language in the learn section to define the masking and approval rules that match your organization’s production‑access standards. The full source code and contribution guide are available in the public repository: github.com/hoophq/hoop. With hoop.dev in place, your GitHub Copilot agents can safely operate against production PostgreSQL while you retain full visibility and control.