Non-human identity: what it means for your prompt-injection risk (on BigQuery)

Are you confident that your AI‑driven queries to BigQuery can’t be hijacked by a malicious prompt? prompt-injection risk is a real threat when large language models generate SQL on behalf of a service account.

Most teams that let models build queries rely on a single service account that lives in a secret manager or a CI pipeline. The model receives a user’s natural‑language request, builds a query string, and sends it straight to BigQuery using the stored credential. If an attacker can influence the prompt – for example by inserting a hidden instruction or by feeding crafted user input – the model may produce a query that exfiltrates data, drops tables, or modifies billing settings. Because the request travels directly from the model to the data warehouse, there is no visibility into what was actually run, and no chance to stop a dangerous statement before it reaches the database.

This situation illustrates the first beat of the problem: a real, unsanitized state where a non‑human identity (the service account) is the only gatekeeper. The credential is static, shared across many jobs, and never rotates automatically. Engineers trust the model’s output, but the underlying connection provides no audit trail, no inline data protection, and no way to require a human to approve high‑impact statements. The result is a high‑impact prompt‑injection risk that can go unnoticed until damage is done.

Understanding prompt‑injection risk with non‑human identities

Introducing a non‑human identity does solve one piece of the puzzle. By moving from a human‑owned key to a service account, you can enforce least‑privilege scopes, limit the data that the model can touch, and rotate the secret on a schedule. That is the second beat: the precondition that the post is about. The service account now defines who the request is – a machine identity – and what it may do. However, the request still reaches BigQuery directly. The gateway that could inspect the SQL, mask sensitive literals, or pause the execution for an analyst is missing. In other words, the fix stops the credential from being exposed to developers, but it leaves the data path completely open, with no real guardrails.

Because the enforcement point is absent, the following gaps remain:

• There is no session‑level record of which prompt produced which query.
• Dangerous commands such as drop table or delete from execute without a checkpoint.
• Result sets that contain personally identifiable information are streamed back to the model unfiltered.
• Any accidental or malicious change to billing or dataset permissions goes unchecked.

All of these gaps are precisely what a data‑path gateway is built to address. The gateway must sit between the service account and BigQuery, inspect each wire‑level request, and apply policy before the query touches the warehouse.

Why a gateway in the data path is essential

Enter hoop.dev. hoop.dev is a Layer 7 gateway that proxies connections to infrastructure such as BigQuery. It runs an agent inside the network, receives the request from the AI‑driven process, and then forwards it to the target only after applying the configured controls. Because hoop.dev sits in the data path, it is the only place where enforcement can happen.

When a prompt‑generated query arrives, hoop.dev can:

• Record the entire session, linking the originating service account to the exact SQL that was sent.
• Apply inline masking to any column that matches a sensitive pattern, ensuring that the model never sees raw PII.
• Block statements that match a dangerous pattern – for example drop, alter, or delete – before they reach BigQuery.
• Route high‑risk queries to a human approver, turning a potentially destructive operation into a controlled workflow.
• Replay the session later for forensic analysis, giving auditors a complete picture of what the model attempted.

Each of those outcomes exists only because hoop.dev is the enforcement point. If the service account were used without hoop.dev, none of the above would be guaranteed.

How the architecture aligns with the three required categories

Setup. You still configure OIDC or SAML so that the AI service authenticates as a specific non‑human identity. The identity decides who may start a session and what scopes are attached.

The data path. hoop.dev sits between that identity and BigQuery. It is the only component that can inspect, transform, or block the traffic.

Enforcement outcomes. Because hoop.dev controls the data path, it records every session, masks sensitive fields, enforces just‑in‑time approvals, and blocks disallowed commands. Those outcomes would disappear the moment hoop.dev is removed.

Getting started with hoop.dev for BigQuery

To protect your AI‑driven analytics pipeline, deploy the gateway using the official getting‑started guide. Register BigQuery as a connection, bind the service account credential to the gateway, and define policies that match your organization’s risk tolerance. The documentation walks you through creating masking rules, approval workflows, and session‑recording settings without exposing any code snippets.

Because the solution is open source, you can review the implementation, contribute improvements, or fork the repository to suit your internal compliance needs.

FAQ

Does hoop.dev replace the service account?

No. The service account remains the identity that authenticates to the gateway. hoop.dev simply mediates the request, adding guardrails on the way to BigQuery.

Can hoop.dev mask data that the model would otherwise see?

Yes. By defining inline masking rules, hoop.dev rewrites result sets before they leave the warehouse, preventing the model from receiving raw sensitive values.

Is session replay safe for privacy?

Session logs are stored with the same access controls applied to the gateway itself. Only authorized personnel can replay a session, and the logs never contain the original service account secret.

Ready to see the code in action? Explore the repository on GitHub and start hardening your AI‑driven BigQuery workloads today.