Count the service-account keys in your GCP project that belong to AI agents. Now count the ones you could revoke today without breaking something you cannot name. The gap between those two numbers is your non-human identity problem. Agents have quietly become the largest population of actors in many GCP estates, and they authenticate with the weakest pattern available: a static key, copied into a process, shared across tasks.
Non-human identity for AI agents on GCP is the discipline of giving each agent a real, attributable, short-lived identity instead of a shared secret. This post is about how to get there.
Why a shared key is not an identity
A service-account key answers "what can connect," not "who connected." When several agents share one, the distinction you most need during an incident, which agent did this, is gone. The key has these failure modes baked in:
- It is long-lived, so a leak is valid until someone notices and rotates it.
- It is shared, so actions cannot be attributed to one agent.
- It is portable, so wherever the agent process runs, the full grant travels with it.
An identity, by contrast, is per-actor, short-lived, and attributable. The architectural requirement for non-human identity is that the credential the agent presents resolve to a specific principal and expire on its own, and that the resolution happen somewhere the agent cannot forge.
What non-human identity looks like on GCP
GCP IAM federation lets a connection resolve identity to a per-user short-lived OAuth credential rather than a static service-account file. Applied to agents, that means each agent's access to a GCP-hosted resource is brokered as a scoped, expiring credential tied to a federated identity. The agent does not hold a key; it presents an identity, and the connection mints the short-lived credential behind it.
The piece that makes this enforceable is a broker between the agent and the resource. The agent should never possess the underlying GCP credential. It should authenticate to a gateway, and the gateway should attach the federated, short-lived identity to the connection.
Implementing it with hoop.dev
hoop.dev is an open-source Layer 7 access gateway. It proxies the agent's connection to the GCP-hosted resource and brokers identity on that connection, so the agent carries no standing credential of its own.
- Deploy the gateway and register the GCP-hosted targets your agents use, such as BigQuery or a Cloud SQL instance.
- Configure GCP IAM federation on each connection. Identity resolves to a per-user short-lived OAuth credential instead of a shared service-account key.
- Onboard each agent as its own principal. The agent authenticates to hoop.dev as itself; the gateway attaches the federated identity to the connection.
- Scope each agent's access to only the resources its job requires, so the identity carries least privilege, not a blanket grant.
- Verify: have two agents run the same query, then check the session records show two distinct identities, not one shared key.
One pattern hands every agent the same key and hopes for the best. The other gives every agent a short-lived identity that names it and expires on its own.
Pitfalls to avoid
- Federating identity but leaving a broad IAM role on the connection re-creates the over-grant you were trying to escape. Pair identity with scope.
- Do not let agents cache or persist the short-lived credential. The point is that it expires; defeating that defeats the model.
- Non-human identity is about the connection to GCP-hosted infrastructure, not the GCP admin API. hoop.dev governs the former.
FAQ
How is non-human identity different from a service account?
A service account with a static key is shared and long-lived. Non-human identity here means a per-agent, short-lived credential resolved through GCP IAM federation, so each agent's actions are attributable and the credential expires.
Does the agent ever hold the GCP credential?
No. The agent authenticates to the gateway, and the gateway attaches the federated short-lived credential to the connection. The agent carries no standing GCP key.
Can I scope each agent differently?
Yes. Each agent is its own principal with its own scope, so you grant only what that agent's job needs.
To put non-human identity for AI agents on GCP on a real footing, start with the open-source gateway at github.com/hoophq/hoop, read the access model at hoop.dev/learn, and follow the getting started guide to register your first federated connection.
