Least-privilege access fails for AI agents in a predictable way: the role grows. An agent's task changes, a query errors out on a permission, an engineer widens the IAM role to make the error go away, and nobody narrows it back. Six months later the agent that was supposed to read one BigQuery dataset can read every dataset in the project. Least-privilege access for AI agents on GCP is less about the initial grant and more about keeping the grant from quietly expanding.
This post covers how to scope agent access to GCP-hosted infrastructure and hold it there.
Why agents drift toward over-privilege
The pressure is structural. An agent runs unattended, so when it hits a permission wall the fix that ships fastest is a broader role. Three forces push the same direction:
- Shared credentials carry the union of everyone's needs. One key for many agents means the widest grant any of them required.
- Standing grants never get reviewed, because nothing forces a review.
- Errors are loud and over-grants are silent, so widening always wins in the moment.
Least privilege done right makes the narrow grant the easy one. The architectural requirement is that scope attach to the connection and the identity, not to a key the agent keeps, and that access be granted in small, reviewable units rather than one permanent role.
Two layers of scope on GCP
Least-privilege access for AI agents on GCP works at two layers, and you need both:
- The GCP grant. The IAM role behind the connection should be the minimum the task needs. Read-only where the agent only reads. One dataset, not the project.
- The access path. Even with a tight role, the agent should reach the resource through a broker that scopes which connections it can open and for how long, so privilege is bounded in time as well as in role.
A tight IAM role with an unbounded standing connection is still over-privileged in time. A time-boxed connection over a broad role is still over-privileged in scope. Least privilege needs both narrowed.
Enforcing it with hoop.dev
hoop.dev is an open-source Layer 7 access gateway that proxies agent connections to GCP-hosted infrastructure. It is where you enforce the access-path layer of least privilege.
- Register each GCP-hosted target as its own connection, with the narrowest IAM role that target's work requires configured on it.
- Enable GCP IAM federation so identity resolves to a per-user short-lived OAuth credential, and access is attributable per agent.
- Scope each agent to only the connections it needs. An agent that reads one dataset gets that connection and no other.
- Make grants just-in-time where you can, so access is bounded in time and falls away after the task instead of standing open.
- Verify: try to reach a resource the agent was not scoped for and confirm the gateway denies it, then review the session records to confirm agents only touched what they were granted.
Reviewing scope before it drifts
Because every connection is recorded and attributed, you can review what each agent actually used versus what it was granted. An agent that was scoped to three datasets but only ever touched one is a candidate to narrow. This turns least privilege from a one-time setup into a thing you can audit and tighten over time.
Pitfalls to avoid
- Do not solve a permission error by widening the IAM role for everyone. Scope the one connection that needs it.
- Do not equate a short-lived credential with least privilege. Short-lived and broad is still broad. Narrow the role too.
- Remember the boundary: hoop.dev scopes connections to GCP-hosted infrastructure, not access to the GCP control plane.
FAQ
Does least privilege mean configuring IAM roles or the gateway?
Both. The IAM role behind the connection sets the GCP-side scope; the gateway sets which connections an agent can open and for how long. Least-privilege access needs the two together.
How do I stop agent roles from drifting wider?
Record and attribute every session, then review what each agent used against what it was granted, and narrow the gap. Just-in-time grants also stop standing access from accumulating.
Is hoop.dev open source?
Yes, it is MIT licensed and you can run it yourself.
To enforce least-privilege access for AI agents on GCP, start from the gateway: clone github.com/hoophq/hoop, follow the getting started guide to scope your first connection, and see hoop.dev/learn for how scope and identity combine.
