An AI‑driven code‑generation agent runs nightly, using a service account that has permanent read/write rights to a GCP Cloud SQL instance. The agent can push schema changes, back‑fill data, and even delete tables if a bug slips into its prompt. Because the credential never expires, the organization assumes the risk is bounded by the service account’s limited scope.
In practice, that assumption falls apart the moment the agent is repurposed, the model is updated, or a malicious prompt is injected. The core question becomes: does standing access really protect the database, or does just-in-time access provide the missing guardrails?
Why standing access feels safe but leaves risk unchecked
Standing access is the default pattern for most AI‑driven workloads. The setup phase creates a service account, grants it a role that includes the required Cloud SQL permissions, and stores the credential in a secret manager. Identity providers (OIDC, SAML) verify the caller, and the service account determines whether the request can start. This is the Setup layer: it decides who the request is and whether it may begin.
What standing access does not provide is any enforcement on the actual data path. The request travels directly from the agent to the database over the cloud network. No component inspects the SQL statements, no approval workflow intercepts risky commands, and no session is recorded for later review. The result is a blind tunnel where the agent can execute any statement the role permits, including destructive ones, without a single audit entry.
Because the enforcement outcomes, query‑level audit, inline masking, just‑in‑time approval, command blocking, session recording, are absent, the organization cannot prove that the agent behaved as intended. If a breach occurs, the evidence trail is empty.
The missing piece: a data‑path gateway
To close the gap, the control surface must sit where the traffic actually flows. That is the role of a Layer 7 gateway that proxies every connection between the AI agent and the target resource. The gateway becomes the Data Path component, the only place enforcement can happen.
hoop.dev fulfills that role. It sits between identities and infrastructure, receiving the agent’s request, authenticating the caller via OIDC, and then applying policy before the traffic reaches Cloud SQL. Because the gateway controls the data path, it can enforce the outcomes that standing access alone cannot provide.
When the agent initiates a query, hoop.dev records the entire session, creating a replayable audit log. If the query contains a column that holds personally identifiable information, hoop.dev masks the field in real time, ensuring that downstream logs never expose raw data. For operations that modify schema or delete data, hoop.dev can require a human approver before the command is sent to the database, turning an implicit risk into an explicit, auditable decision. Finally, if a command matches a deny‑list, such as DROP DATABASE, hoop.dev blocks it outright, preventing accidental or malicious destruction.
All of these enforcement outcomes exist only because the gateway sits in the data path. The underlying identity system still decides who can start a request, but the real protection happens after the request reaches the gateway.
How the gateway works with AI agents on GCP
- Setup: Create an OIDC client in the organization’s IdP, grant the AI service account the minimal role needed to request a token, and configure the gateway with the Cloud SQL credentials it will use on behalf of callers.
- Data Path: The agent connects to hoop.dev using its standard client (for example, the psql CLI). The gateway terminates the protocol, inspects each statement, and forwards it only after policy checks succeed.
- Enforcement outcomes: Session recording, inline masking, just‑in‑time approval prompts, and command blocking are applied automatically. The audit log lives outside the agent’s process, providing the security team with reliable evidence.
This architecture flips the risk model. Instead of trusting a long‑lived credential to behave, the organization trusts a short‑lived, policy‑driven gateway to enforce the correct behavior every time.
Comparison summary
| Aspect |
Standing access |
just-in-time access via hoop.dev |
| Credential lifespan |
Static, often months long |
Transient token validated at each request |
| Visibility of actions |
None unless external logging is added |
Full session recording and replay |
| Data leakage protection |
Depends on downstream logging configuration |
Inline masking of sensitive fields |
| Risk of destructive commands |
Unblocked, relies on role limits |
Block list and just‑in‑time human approval |
| Audit evidence for compliance |
Sparse, often incomplete |
Comprehensive logs that generate evidence for security standards |
In short, standing access gives you a way in, but just‑in‑time access gives you control over what happens once you’re inside. For AI agents that operate autonomously, that control is the decisive factor.
FAQ
Does just‑in‑time access eliminate the need for IAM roles?
No. IAM roles still define the maximum permissions an identity can request. The gateway enforces finer‑grained policies on top of those roles.
Can I use the same gateway for human engineers and AI agents?
Yes. Because enforcement lives in the data path, the same policy set can protect both human‑initiated sessions and automated agents.
What happens if the gateway is unavailable?
Requests are denied until the gateway returns. This fail‑closed behavior ensures that no traffic bypasses policy checks.
For deeper details on policy configuration, see the learn guide. Ready to see the architecture in action? Explore the source code on GitHub and follow the getting‑started guide to deploy the gateway in your GCP environment.
