An AI agent that holds a standing Google service-account key is a 24/7 liability. It can reach BigQuery and your GKE-hosted databases at 3am with no human in the loop, and the credential it carries outlives every task it was built for. Just-in-time access flips that default: the agent holds nothing until it asks, gets a scoped grant for the work in front of it, and loses the grant when the task ends.
This post covers how to give AI agents just-in-time access to GCP-hosted infrastructure without scattering long-lived keys across your fleet. The mechanism that makes it work is a gateway that brokers each connection against Google identity, not a vault of secrets you rotate on a calendar.
What standing access to GCP actually costs you
Most agent deployments start the same way. Someone mints a service-account key, drops it in the agent's environment, and grants it enough IAM roles to stop the task from failing. That key now sits in a process you do not fully control, valid until a human remembers to revoke it. If the agent is compromised or simply prompted into doing something nobody intended, the blast radius is everything that key can touch, for as long as the key lives.
The agent does not need permanent reach. It needs to run one query against a Cloud SQL instance, or read a single BigQuery dataset, for the duration of one job. Standing access trades that narrow need for a wide, always-on grant.
What just-in-time access means for an agent on GCP
Just-in-time access means the connection to the GCP-hosted resource does not exist until the agent requests it, the identity on that connection is short-lived, and the grant expires on its own. Concretely, on GCP that looks like:
- The agent authenticates as itself, not as a shared key. With GCP IAM federation in front of the connection, identity resolves to a per-user short-lived OAuth credential rather than a static service-account file.
- Access is granted for a window tied to the task, then it falls away. Nothing to rotate, nothing left behind.
- Every action inside that window is attributed to the requesting identity, so a grant is never anonymous.
The requirement underneath all three points is that the thing deciding whether to grant access has to sit outside the agent. If the agent can mint or extend its own credential, just-in-time is a label, not a control. The grant authority must live where the agent cannot reconfigure it.
Setting it up through hoop.dev
hoop.dev is an open-source Layer 7 access gateway. It proxies the agent's connection to the GCP-hosted resource through an agent that runs inside your network, and applies the just-in-time grant on that connection. The agent never holds the underlying credential.
- Run the hoop.dev gateway and register a connection for the GCP-hosted target, for example a BigQuery dataset or a Cloud SQL Postgres instance. Configure GCP IAM federation on the connection so identity resolves to per-user short-lived OAuth credentials instead of a shared key.
- Point the AI agent at the gateway rather than at GCP directly. The agent calls hoop.dev as its access path; hoop.dev holds the connection details, the agent holds none.
- Set the access policy so the connection requires a just-in-time grant. A request opens a scoped, time-boxed session; when it ends, the access is gone.
- Verify by inspecting the session record. Run a query through the agent, then confirm the session shows the requesting identity, the commands, and an expiry, with no residual standing grant afterward.
One model leaves a key in the agent forever. The other opens a scoped connection only when there is a task and a verified identity to attach it to.
Pitfalls to avoid
- Do not federate identity and then leave a wide IAM role on the connection. Short-lived credentials scoped to a broad role still over-grant. Pair just-in-time with least privilege.
- Do not treat the agent's own logs as the access record. If the audit lives inside the process that holds the access, a compromised agent edits both.
- Do not confuse this with fronting the GCP admin API. hoop.dev governs connections to GCP-hosted infrastructure, not the GCP control plane.
FAQ
Does just-in-time access slow the agent down?
A grant takes effect when the agent opens a session and expires when the task ends. For routine work the policy can auto-grant within scope; sensitive operations can route for approval. The latency is a policy decision, not a fixed cost.
What identity does the agent use on GCP?
With GCP IAM federation configured on the connection, the connection resolves to a per-user short-lived OAuth credential. The agent authenticates through the gateway and never handles a static service-account key.
Is hoop.dev open source?
Yes, hoop.dev is open source under the MIT license. You can read the code and run it yourself.
If you are giving AI agents just-in-time access to GCP-hosted infrastructure, start from the gateway model. Clone the repo at github.com/hoophq/hoop, stand up a connection, and see the getting started guide to wire your first GCP target. The access model explained at hoop.dev/learn covers how identity, scope, and recording fit together.
