A freelance data scientist was granted a temporary token so a GitHub Copilot‑driven CI job could seed a test database, creating an uncontrolled database access path. The token was a broad‑scope service account key that lived in the repository’s secret store. When the job finished, the key remained, and a later pull‑request unintentionally ran a migration that exposed customer PII to an external API.
This scenario illustrates a growing blind spot: AI coding assistants can issue database queries on behalf of developers, but organizations often treat the assistant as just another client. The usual setup relies on static credentials stored in CI pipelines, and there is little visibility into which statements the model actually sent, whether sensitive columns were returned, or if an out‑of‑policy operation was performed.
What is missing is a control plane that knows *who* the request originates from (a service account, an AI‑generated token, or a human), but also a point in the traffic flow where policies can be enforced. Identity federation and least‑privilege grants are essential – they decide which identities are allowed to start a connection – yet they do not stop a privileged identity from running a destructive query, nor do they provide an audit trail of the exact SQL that was executed.
Enter a Layer 7 gateway that sits between the AI agent and the database. The gateway becomes the only place where enforcement can happen, and it can apply just‑in‑time approval, inline masking, command‑level audit, and session recording.
Enforcing database access for AI agents
hoop.dev acts as an identity‑aware proxy. The setup phase registers a GCP Cloud SQL instance as a connection and ties it to an OIDC identity provider such as Google Workspace or a SAML‑compatible IdP. When Copilot or a CI job attempts to open a database session, it presents an OIDC token. The gateway validates the token, extracts group membership, and determines whether the request is allowed to proceed.
Because the gateway holds the actual database credentials, the AI agent does not obtain the database credential. The request is then forwarded through the data path where hoop.dev can:
- Require a human approver before executing statements that match a risky pattern, for example DROP TABLE or SELECT * FROM users.
- Mask columns that contain personally identifiable information in query results, ensuring that downstream logs do not leak raw data.
- Record the full session, including every statement and response, for later replay and forensic analysis.
- Block commands that exceed a predefined cost threshold, preventing runaway queries that could exhaust a database.
All of these outcomes exist only because hoop.dev sits in the data path. If the same OIDC token were sent directly to Cloud SQL, none of the masking, approval, or recording would occur.
Architectural flow
1. Setup: An administrator creates a service account with read‑only rights on the target database and registers it in hoop.dev. The service account is never exposed to developers or AI agents.