Non-human identity vs shared service accounts: which actually controls AI agent risk (on GCP)

When a contractor leaves a project, the CI pipeline they built often continues to run using a long‑lived service‑account key that was checked into the repository. An internal AI‑driven automation later picks up that key, authenticates to GCP as a non-human identity, and starts provisioning resources without any human oversight. The organization now has a hidden, high‑privilege identity that can act anywhere the original contractor could.

The problem with shared service accounts

Shared service accounts are attractive because they provide a single credential that many jobs can reuse. In practice they become a single point of failure: the private key is copied to developer laptops, stored in CI secret stores, and sometimes even embedded in container images. When an AI agent or a compromised build server accesses that key, it inherits every permission granted to the account. Because the credential is static, there is no built‑in expiration, no context about who is invoking the request, and no audit trail that ties an action to a specific user or process. The result is a blind spot where privileged operations can be performed without visibility, approval, or any form of data protection.

Non-human identity improves credential hygiene, but leaves a gap

Adopting non-human identity, workload‑identity bindings, OIDC tokens, or short‑lived service‑account impersonation, eliminates the need to distribute long‑lived keys. Each workload receives a token that is scoped to its identity and expires automatically. This change solves the credential‑sprawl problem and reduces the risk of key leakage.

However, the token still travels directly from the workload to the target GCP service. The request bypasses any enforcement point that could record the operation, mask sensitive response fields, or require a human approval for risky actions. Non-human identity alone does not give you a central place to apply command‑level policies, capture a replayable session, or enforce inline data redaction. In other words, the request reaches the target unobserved, and the organization loses the same audit and control benefits it had when using shared service accounts.

Putting enforcement in the data path with hoop.dev

hoop.dev is a Layer 7 gateway that sits between identities and GCP resources. By proxying connections to databases, Kubernetes clusters, SSH endpoints, and HTTP APIs, hoop.dev becomes the only place where traffic can be inspected and controlled.

When a workload presents a non-human identity token, hoop.dev validates the token, extracts the identity, and then applies a set of guardrails:

• Session recording: hoop.dev captures every request and response, storing a replayable log that ties the action to the presenting identity.
• Inline masking: Sensitive fields, such as API keys returned in a JSON payload, are redacted in real time before they reach the calling process.
• Just‑in‑time approval: High‑risk commands trigger an approval workflow, pausing execution until an authorized reviewer grants permission.
• Command blocking: Dangerous operations (for example, dropping a production database) are blocked outright based on policy.

Because hoop.dev is the sole gateway, all enforcement outcomes exist only because it sits in the data path. The non-human identity token determines who is making the request, but hoop.dev is the mechanism that records, masks, and controls that request.

To get started, follow the getting‑started guide and explore the feature documentation on the learn site. The open‑source repository on GitHub provides the full implementation and examples for integrating with GCP workloads.

FAQ

Q: How does hoop.dev differ from simply using workload identity?
A: Workload identity limits credential exposure, but it does not provide a place to observe or intervene in a request. hoop.dev adds that observation layer, turning every connection into an auditable, policy‑enforced session.

Q: Will routing traffic through hoop.dev add noticeable latency?
A: hoop.dev operates at the protocol layer and adds only the processing needed for inspection, masking, and logging. In most environments the added latency is measured in milliseconds and is outweighed by the security benefits.

Q: Can I keep my existing CI pipelines and simply point them at hoop.dev?
A: Yes. CI jobs that currently connect directly to GCP services can be reconfigured to use the hoop.dev endpoint. The underlying credentials remain managed by hoop.dev, so no code changes are required beyond the endpoint update.

Explore the open‑source code on GitHub to see how hoop.dev can become the enforcement point that truly controls AI agent risk on GCP.