An offboarded contractor’s service account key still lives in a CI pipeline, and a newly created Cloud Build job automatically picks it up. When that service account is impersonated, the promise of least privilege evaporates. The job then talks to Cloud SQL, pulls production data, and pushes it to an external bucket. No one on the team noticed because the service account has the broad "Cloud SQL Admin" role, and the pipeline’s logs show only a generic "cloudsql.googleapis.com" request.
In many GCP environments, engineers grant service accounts wide IAM roles to simplify automation. Those accounts are then impersonated by scripts, bots, or other services. The practice looks convenient, but it creates a single credential that can be reused across dozens of workloads. When an attacker compromises one workload, they inherit every permission that the impersonated account holds. The result is a loss of the least privilege guarantee that IAM is supposed to provide.
At this point the organization typically relies on GCP’s IAM policies alone. The policies decide who can request a token and whether the token can be exchanged for another identity. They do not inspect the actual traffic that flows to the target service, nor do they record each command or query that passes through. The request still reaches Cloud SQL directly, with no inline validation, no masking of sensitive columns, and no way to block a dangerous statement before it executes.
What is missing is a control surface that sits in the data path. The gateway must be the only place where enforcement can happen, because only there can it see the full request, apply just‑in‑time approval, mask fields in responses, and record the session for later replay. Without that, the organization’s reliance on IAM alone leaves a blind spot: every privileged operation is invisible until after the fact.
hoop.dev places a Layer 7 gateway between the identity provider and the GCP resource. The gateway proxies connections to databases, Kubernetes clusters, SSH servers, and HTTP services. Because the gateway sits in the data path, it can enforce least privilege controls on every request, regardless of how the upstream token was obtained.
hoop.dev records each session, masks sensitive fields in query results, and blocks commands that violate policy before they reach the backend. It also requires just‑in‑time approval for high‑risk operations, ensuring that a privileged action cannot be executed silently. By acting as the sole enforcement point, hoop.dev guarantees that the least privilege model is enforced at runtime, not just at token issuance.
The result is a concrete audit trail that shows who ran what, when, and against which resource. If a compromised service account tries to exfiltrate data, hoop.dev can redact the secret columns in the response and terminate the session. This reduces blast radius, provides evidence for auditors, and restores confidence that the organization’s least‑privilege posture is truly enforced.