When a CI pipeline spins up an AI coding agent on GCP, ensuring a proper non-human identity for these agents is critical. The only credential it carries is a long‑lived service‑account key that grants broad access across projects, violating the principle of non-human identity.
Most teams rely on this static credential because it is simple to inject into scripts and the agents can reach any Google Cloud API without additional plumbing. The reality is that the identity used by the agent is human‑like in scope, making it impossible to enforce least‑privilege policies, request approvals, or generate meaningful audit trails.
What organizations really need is a non-human identity model that limits each AI agent to the exact resources it must touch, while still allowing the agent to run autonomously. The missing piece is a control point that can inspect every API call, enforce policies, and record activity before the request reaches the target service. Without that control point, the request still travels directly to GCP, bypassing any real guardrails.
hoop.dev provides that control point. It acts as a Layer 7 gateway that sits between the AI agent and Google Cloud services. The gateway authenticates the agent via OIDC, forwards the request to the appropriate GCP endpoint, and applies masking, just‑in‑time approval, and session recording on the fly.
Why non-human identity matters for AI coding agents on GCP
AI agents are designed to write, test, and refactor code without human intervention. Because they operate at scale, a single over‑privileged credential can amplify risk across dozens of projects. Enforcing non-human identity means each agent receives a scoped token that only allows the specific API methods required for its task. This reduces the blast radius of a compromised agent and aligns with the principle of least privilege.
Architectural pattern with hoop.dev as the gateway
The recommended architecture separates three responsibilities:
Setup – provisioning service accounts and OIDC tokens
First, create a dedicated service account for the AI agent in each GCP project. Grant that account only the IAM roles needed for the agent’s job, such as roles/cloudfunctions.invoker or roles/datastore.viewer. Then configure an OIDC identity provider (for example, Google Workload Identity Federation) that can issue short‑lived tokens on behalf of the service account. The token is presented to the gateway, not to the GCP APIs directly.
Data path – placing hoop.dev between the agent and GCP services
Deploy the hoop.dev gateway close to the GCP resources, typically as a Docker Compose service or a Kubernetes sidecar. The gateway runs an agent inside the same network as the target services, so all traffic flows through it. When the AI agent initiates a request, it connects to the gateway using its OIDC token. The gateway validates the token, extracts the identity, and then proxies the request to the GCP endpoint.
Enforcement outcomes you gain
- hoop.dev records every API call made by the AI agent, creating a replayable session log for audit and forensic analysis.
- Sensitive fields in responses, such as API keys or personal data, can be masked in real time, preventing the agent from leaking secrets.
- Commands that match risky patterns are blocked before they reach GCP, reducing the chance of accidental destructive actions.
- Requests that exceed the agent’s privilege scope trigger a just‑in‑time approval workflow, ensuring a human reviews elevated operations.
- The gateway never exposes the underlying service‑account key to the agent, keeping credentials out of the runtime environment.
FAQ
How does hoop.dev verify the agent’s identity? The gateway acts as an OIDC relying party. It validates the signed token, extracts group membership, and maps those groups to the policies you define for each AI workload.
Can existing CI pipelines use this without code changes? Yes. The pipeline only needs to point its client (for example, the gcloud CLI or the REST API) at the gateway’s address. The underlying request format stays the same.
What happens to the service‑account key? The key lives only in the gateway’s secure store. The AI agent never receives it, eliminating the risk of accidental key leakage.
For a step‑by‑step walkthrough, see the getting started guide. Detailed feature documentation is available on the learn page. When you are ready to explore the code or contribute, explore the source on GitHub.
