An engineer wires a GitHub Copilot agent to run migrations against staging, and three weeks later it is reading from the production primary because someone reused the same connection string. Nobody decided that. It happened because the agent inherited a credential that never narrowed.
The control people skip when they grant database access to a GitHub Copilot agent is the one that matters most: a boundary that sits outside the agent and decides, per query, what it may touch. Not a prompt rule. Not a config file the agent can read and edit. A separate enforcement point.
To be precise about scope, hoop.dev does not read or govern what GitHub Copilot generates, the prompt, or the model's reasoning. It governs the database connection the agent drives. The SQL that leaves the agent and hits Postgres or MySQL is the thing under control here.
Why database access is the control teams skip
Teams put effort into the visible parts: which repos the agent can see, what tools it can call. The database connection underneath gets a static set of credentials and is forgotten. That standing access is the blast radius. An over-scoped agent with a long-lived password can read every row in every table the moment a prompt goes sideways or a dependency is compromised.
The fix is to treat the agent like any other identity that reaches your data, and to make database access something the agent requests and the gateway grants, scoped and timed, never something it holds by default.
There is a second reason this control gets skipped. A coding agent feels like part of the development toolchain, not like a user with a login, so teams reason about it the way they reason about a library or a CI job. But a library does not run arbitrary SQL against your customer tables at runtime. A coding agent does. The right mental model is a contractor with a keycard, and the question for a contractor is always the same: which doors, for how long, and is there a log.
Route the connection through an identity-aware proxy
hoop.dev is an open-source Layer 7 access gateway. An agent runs near your database and opens an outbound connection to the gateway, so nothing on the database is exposed inbound. The GitHub Copilot agent connects to hoop.dev instead of straight to Postgres, and every query passes through the proxy at the wire-protocol level.
That placement is the whole point. The record of what the agent did, and the policy that decides what it may do, live outside the process the agent controls. The agent cannot rewrite the rule that governs it. This is the difference between a control and a preference. A preference is something you ask the agent to respect. A control is something the agent runs into whether it intends to or not.
A worked example
Say the agent's task is to find slow queries in a reporting database and propose indexes. It needs read access to the schema and the query stats, nothing more. Through the gateway, you register that database with a role that can run SELECT and read the statistics views, and you grant the agent access for the duration of the task. The agent connects as a named identity, reads what it needs, and proposes changes. When it suggests an index, that DDL routes to an approver rather than executing. The agent did useful work, touched only what the task required, and left a complete record, all without holding a credential a minute longer than the task lasted.
Steps to scope database access for a Copilot agent
- Register the database as a connection. Configure the Postgres or MySQL connection on hoop.dev with a least-privilege role, not the admin user. The credential lives on the connection, not in the agent.
- Give the agent a named identity. The agent authenticates to the gateway through your OIDC provider, so its actions attribute to a distinct principal, not a shared service account.
- Set just-in-time scope. Grant access for the task window, not forever. When the task ends, the access ends.
- Require approval for writes. Route writes or schema changes to a human approver before they execute.
- Verify. Run a query through the agent and confirm it appears in the session record tied to that identity.
# the agent points at the gateway, not the database directly
psql "host=gateway.internal port=5432 dbname=app user=copilot-agent"
# the gateway authenticates the agent, applies policy, then proxies to Postgres
Pitfalls that quietly reopen the boundary
- A shared connection string. If the agent and a human use the same credential, you lose attribution. Give the agent its own.
- Read access that drifts into write. Pin the database role to read-only unless a task genuinely needs writes, then gate those.
- Standing grants. Access that outlives the task is the thing that bites you later. Keep it scoped to the work.
FAQ
Does hoop.dev see what GitHub Copilot generates?
No. hoop.dev governs the database connection the agent uses. It does not read the prompt, the completion, or the model's reasoning. It records and controls the queries that reach your database.
Can I mask sensitive columns in the results?
On supported database connections, hoop.dev can send returned data to a configured DLP provider and redact sensitive fields before they reach the agent. See the docs for which connectors support inline masking.
Scope the connection once and every query an agent runs inherits the boundary. Start from the open-source project on GitHub, read the getting started guide, or see how the model works on hoop.dev.
