Without a non-human identity model, AI agents expose your data to uncontrolled risk, and a single static key can be copied, leaked, or abused without any trace. The cost is not just a data breach; it is the loss of trust in automated decision‑making and the expense of remediation, compliance gaps, and downstream business impact.
A proper non-human identity strategy is essential for controlling AI risk.
Current practice: shared service accounts for AI agents
Most organizations hand an AI service a service‑account key that lives in a secret store, a CI/CD pipeline, or even a container image. The agent presents that key to BigQuery on every request. Because the key is shared across many jobs, revoking a single compromised token requires rotating the entire credential set, a painful operation that often gets delayed. Auditing is limited to the BigQuery audit log, which shows the service‑account name but not which job or which piece of code issued the query. There is no inline protection against accidental data exposure, and no way to pause a runaway query before it consumes excessive resources.
Why non-human identity alone isn’t enough
Moving to a non-human identity model, issuing short‑lived OIDC tokens to each AI job, addresses the credential‑sprawl problem. Each token is scoped to the exact dataset and role required for that job, and the token expires quickly, reducing the blast radius of a leak. However, the token still travels directly to BigQuery. The gateway that inspects the request is missing, so the following gaps remain:
- There is no real‑time approval step for queries that touch sensitive columns.
- Responses that contain personally identifiable information are sent back to the agent unfiltered.
- If a bug generates a massive scan, the query runs to completion before anyone notices.
- Session data is not recorded in a place that is independent of the AI workload, making forensic analysis difficult.
These gaps are all the result of the enforcement point being absent from the data path. The setup, identity providers, token issuance, and role bindings, decides who may start a request, but it cannot enforce policy on the request itself.
Putting the gateway in the data path
hoop.dev inserts a Layer 7 gateway between the AI agent and BigQuery. The gateway receives the non-human identity token, validates it against the IdP, and then proxies the query to BigQuery. Because hoop.dev sits in the data path, it can apply the missing controls directly on the wire.
How hoop.dev enforces the missing controls
- It records every query session, storing a replayable log that lives outside the AI workload.
- It masks sensitive fields in query results according to policy, preventing PII from reaching the agent.
- It requires just‑in‑time approval for queries that match a high‑risk pattern, such as full‑table scans on regulated datasets.
- It blocks dangerous commands, like DROP TABLE, before they reach BigQuery, reducing accidental damage.
- It ties each recorded session to the original non-human identity, giving a clear audit trail that satisfies regulator demands.
All of these enforcement outcomes exist because hoop.dev is the only component that sits on the data path. The identity setup remains responsible for authentication, but the gateway is the place where policy enforcement happens.
Getting started with hoop.dev
To adopt this model, provision the hoop.dev gateway in your network, configure a BigQuery connection, and point your AI jobs to the gateway endpoint instead of the raw BigQuery endpoint. The gateway holds the service credential, so the AI code never sees it. Detailed steps are covered in the getting‑started guide and the broader learn section. The full source code and contribution guidelines are available on the GitHub repository.
FAQ
What is a non-human identity?
A non-human identity is an OIDC or SAML principal that represents a software component rather than a person. It can be issued for a specific job, scoped to particular resources, and have a short lifespan.
Can I keep using shared service accounts and still be safe?
Shared accounts can be wrapped in hoop.dev, but the risk of credential leakage remains because the same secret is reused across many jobs. Non-human identities provide isolation at the token level, and hoop.dev adds the enforcement needed to protect data.
Does hoop.dev add latency to queries?
Because hoop.dev operates at the protocol layer, the added round‑trip is typically a few milliseconds, which is negligible compared with the cost of a potential data breach or uncontrolled query.
