Putting access controls around GitHub Copilot: database access for AI coding agents (on on-prem)

Why database access needs strict controls for AI coding agents

A newly hired contractor receives a GitHub Copilot token that suggests code snippets while they work on a feature branch. We configure the token with a service‑account credential that also grants read‑only access to the production PostgreSQL instance. The contractor’s local IDE now issues queries indirectly through Copilot, and the organization loses visibility into which tables are inspected or whether sensitive columns are exposed. Because the credential is static, the same token can be reused across multiple machines, and any compromised workstation instantly inherits full database visibility.

Even when the token is scoped to a specific repository, the underlying AI service can request data from the database to improve suggestion quality. Without a guardrail, developers may inadvertently expose personally identifiable information or proprietary business logic to the AI model. The result is a widening attack surface, a lack of auditability, and an inability to enforce least‑privilege principles for an autonomous coding assistant.

What organizations really need is a way to treat the AI‑driven request as any other user‑initiated database connection: the request must be authenticated, authorized, recorded, and, where appropriate, have sensitive fields masked before they are returned. The control point must sit where the request travels, not merely at the identity provider or in the application code.

Desired security posture for AI‑generated queries

The security model should provide three core guarantees:

• Just‑in‑time authorization: each query evaluates against a policy that reflects the current role of the requesting identity. Approvers review high‑risk statements such as a full table scan or a drop command before execution.
• Inline data masking: columns marked as sensitive, such as SSN, credit‑card numbers, or internal API keys, are redacted in the response before they ever reach the AI model.
• Full session audit: every request and response logs the originating identity, the exact statement, and a timestamp, enabling forensic replay and compliance reporting.

These guarantees cannot be achieved by merely configuring the identity provider or by relying on the CI pipeline to “trust” the Copilot token. Enforcement must happen where the traffic flows – at the protocol layer that carries the database wire protocol.

Architectural pattern that isolates enforcement

To satisfy the three guarantees, we introduce a dedicated gateway that sits between the AI coding agent and the database. The gateway performs the following steps for each connection:

1. Validate the OIDC or SAML token presented by the Copilot client. The token proves who originates the request and carries group membership that we map to a policy.
2. Consult a policy engine to decide whether the statement is allowed, whether it needs a human approver, or whether we block it outright.
3. If the statement is permitted, inspect the result set and apply field‑level masking rules before forwarding the data back to the AI service.
4. Record the full request and masked response in an audit store, tagging it with the identity, the policy decision, and any approval metadata.

This pattern makes the gateway the sole point of control, the data path. All enforcement outcomes derive from the gateway’s actions, not from the upstream identity system or from the database itself.

Introducing hoop.dev as the data‑path gateway

hoop.dev implements exactly this data‑path gateway. It runs a network‑resident agent close to the target database and proxies every database wire‑protocol request. Because hoop.dev sits in the protocol layer, it can mask fields, block disallowed statements, route risky queries for manual approval, and record each session for replay. The product does not replace the identity provider; instead, it consumes OIDC/SAML tokens to make real‑time authorization decisions.

When a Copilot instance attempts to run a query, hoop.dev validates the token, checks the request against the configured policy, applies inline masking, and stores an audit record. The AI service never sees raw sensitive data, and any deviation from the policy halts or escalates to a human approver.

Because hoop.dev is open source and MIT‑licensed, teams deploy it on‑premises behind their own firewalls, ensuring that no third‑party cloud can intercept the data path. The gateway’s architecture also supports just‑in‑time access: credentials for the underlying database reside only inside hoop.dev and never expose themselves to the Copilot client or the developer’s workstation.

High‑level steps to get started

1. Follow the getting‑started guide to deploy the hoop.dev gateway and its agent in the same network segment as your PostgreSQL or MySQL instance.

2. Register the database as a connection in hoop.dev, supplying the service‑account credential that the gateway will use to authenticate to the database.

3. Configure OIDC or SAML as the identity source. Map GitHub Copilot’s service account to the appropriate groups that define its baseline permissions.

4. Define masking rules for columns that contain PII or other sensitive data. The gateway evaluates these rules on every response that passes through hoop.dev.

5. Set up policy rules that require manual approval for high‑risk statements. hoop.dev presents an approval request to a designated reviewer before forwarding the query.

6. Enable session recording. hoop.dev stores each request and masked response, making it possible to replay a session for audit or forensic analysis.

The documentation describes all of these configuration steps in the learn section, which walks through policy definition, masking syntax, and approval workflow design.

FAQ

Q: Does hoop.dev replace my existing IAM roles?
A: No. hoop.dev consumes the identity token issued by your IdP and uses it to enforce policies. The underlying database still uses its own service‑account credential, which the gateway stores securely.

Q: Will masking affect query performance?
A: The gateway applies masking to the result set after the database returns it, so the impact is limited to the size of the response. In practice the overhead remains negligible for typical query volumes.

Q: How can I prove compliance to auditors?
A: hoop.dev generates a complete audit trail for every session, including who approved a high‑risk query and what data was masked. Teams export these logs for SOC 2, ISO 27001, or any internal compliance review.

Next steps

Explore the open‑source repository on GitHub to see the code, contribute improvements, or file an issue: https://github.com/hoophq/hoop. With hoop.dev in place, your organization lets AI coding assistants like GitHub Copilot help developers while keeping database access tightly controlled, fully auditable, and protected against accidental data leakage.