The fastest way to lose sleep over an AI agent is to give it a path to production. A test agent reading a staging dataset is a contained risk. The same agent with a credential that reaches your production Cloud SQL instance is a different category of problem, because now a bad plan or a compromised process touches the systems your customers depend on. Production access control for AI agents on GCP is about making that path deliberate: scoped, identified, gated, and recorded, never a standing key in a process.
Here is how to build that control around agents reaching GCP-hosted production infrastructure.
What makes production access different
Production raises the stakes on every weakness that is tolerable in lower environments:
- A shared, standing credential in staging is sloppy. In production it is an incident waiting for a trigger.
- An unattributed action in staging is annoying. In production it means you cannot tell who broke what.
- An ungated destructive command in staging costs a rebuild. In production it costs customer trust.
So production access control needs four things working as one surface: a real per-agent identity, scope limited to what the task needs, a gate on risky actions, and a record of everything. Assembled separately they leak at the seams. The requirement is one control point the agent must pass through where all four apply together.
The single boundary the agent passes through
If the agent reaches production through one enforced path, you can apply identity, scope, approval, and recording at that path. If it reaches production through a key in its environment, none of those apply and you are trusting the agent. The architectural choice is to put a broker between the agent and production GCP-hosted infrastructure, and to make it the only way through.
hoop.dev is an open-source Layer 7 access gateway built to be that boundary. It proxies the agent's connection to the GCP-hosted production resource and applies access controls on that connection, so the agent never holds a production credential and never reaches production except through the gateway.
Configuring production access control with hoop.dev
- Register your production GCP-hosted targets as connections: the production Cloud SQL instance, the production BigQuery datasets, the GKE-hosted services.
- Enable GCP IAM federation so each connection resolves to a per-user short-lived OAuth credential. Production actions are now attributable per agent, never to a shared key.
- Scope each agent to the minimum production resources its job requires, and prefer just-in-time grants so access does not stand open between tasks.
- Gate destructive and high-risk production actions behind approvals so a human sees them before they run.
- Record every session at the command level, stored outside the agent, so production activity is fully auditable.
- Verify: confirm an agent cannot reach a production resource it was not scoped for, that a destructive action pauses for approval, and that the session record names the identity and the command.
One arrangement trusts a key in the agent to behave in production. The other makes production reachable only through a path that checks identity, scope, and intent on every connection.
Pitfalls to avoid
- Do not reuse a staging credential pattern in production. The standing shared key that was tolerable elsewhere is the main risk here.
- Do not apply only one control. Identity without recording, or scope without approval, leaves a gap that production cannot afford.
- Do not assume this governs GCP itself. Production access control here means connections to GCP-hosted production infrastructure, not the GCP admin API.
FAQ
Does production access control mean agents lose access to production?
No. It means their access is scoped, identified, gated where risky, and recorded, rather than granted through a standing key. Agents still do their work; they just do it through a controlled path.
How is each agent's production activity attributed?
Through GCP IAM federation, each session resolves to a per-user short-lived OAuth identity, so production actions map to a specific agent rather than a shared credential.
Where are production sessions recorded?
At the gateway, outside the agent, at the command level, so the production audit trail cannot be altered by the actor.
To stand up production access control for AI agents on GCP, run the open-source gateway at github.com/hoophq/hoop, read the access model at hoop.dev/learn, and follow the getting started guide before you connect your first production target.
