A common misconception is that any service account used by a GCP agent automatically inherits the permissions shown in access reviews. In reality, the agent can be instructed to act as a different identity, and the audit logs that feed review tools may no longer reflect the true source of each request.
Agent impersonation occurs when a process that holds a credential for a service account is configured – often via the impersonate‑service‑account flag or equivalent API – to issue calls on behalf of another account. The original credential remains valid, but the downstream calls appear under the impersonated identity. From a reviewer’s perspective, the activity looks legitimate because the service account is listed as an approved holder of the required roles. The nuance – who actually issued the request – is hidden.
Why agent impersonation breaks access reviews
Access reviews rely on three pillars: a clear mapping between an identity and its granted permissions, trustworthy logs that capture every action, and a process to verify that the observed behavior matches the declared intent. Impersonation erodes each pillar:
- Identity mapping: The review system sees the impersonated service account, not the originating process. If the impersonated account has broader scopes, the reviewer may approve it without realizing the underlying agent can exceed its original purpose.
- Log integrity: GCP audit logs record the principalEmail of the impersonated identity. The original credential that performed the impersonation is only visible in a separate field that many review pipelines ignore. Consequently, the audit trail appears clean while the true actor remains invisible.
- Intent verification: Policies that grant “least‑privilege” to a service account become ineffective because the agent can silently assume a more privileged identity for a single operation. Reviewers cannot detect this deviation without a deeper, per‑request inspection.
When an organization runs periodic access reviews for GCP workloads, these hidden impersonations can cause two dangerous outcomes. First, reviewers may mistakenly certify a service account as safe, granting it to additional projects or teams. Second, any breach that exploits the impersonation path will leave a misleading forensic record, making post‑incident analysis harder.
Server‑side enforcement as the missing control
The root of the problem is that the decision to allow or deny an impersonated request happens inside the client or the agent process. That location is under the same control plane that can be compromised, so any policy enforcement there can be bypassed. To restore confidence in access reviews, the enforcement point must sit outside the agent, on a server that the agent cannot modify.
Placing a Layer 7 gateway in front of every GCP service call creates a single, immutable authority that can:
- Inspect each request before it reaches the target API and verify that the caller’s original identity matches the policy for the requested operation.
- Record the full request and response, preserving the true source of the call for later review.
- Reject or flag any attempt to use impersonation when it violates the organization’s least‑privilege rules.
This server‑side approach ensures that the data feeding access reviews is trustworthy because the gateway logs every transaction and never hands the underlying credential to the client.
How hoop.dev provides the gateway
hoop.dev implements exactly the architecture described above. It runs as a network‑resident agent that proxies connections to GCP services such as Cloud APIs, Cloud SQL, or Kubernetes clusters. Because hoop.dev sits on the data path, it can enforce policies on every request, regardless of whether the upstream client tries to impersonate another service account.
When a request arrives, hoop.dev validates the OIDC token presented by the user or automation, extracts the original identity, and then checks the request against a policy that disallows unauthorized impersonation. If the request passes, hoop.dev forwards it to the GCP endpoint using its own managed credential, ensuring the target never sees the original token. Simultaneously, hoop.dev records the full request and response, making the information available for audit and for future access reviews. Because the gateway is the only point that can approve or block an impersonated call, any attempt to bypass the policy is impossible without compromising the gateway itself.
For teams that want to start quickly, the getting‑started guide walks through deploying the gateway with Docker Compose, configuring OIDC authentication, and defining policies that prevent unauthorized impersonation. The broader feature set – including real‑time data masking and just‑in‑time approval – is documented in the learn section.
Practical steps to tighten access reviews
Even with a server‑side gateway, organizations should follow a disciplined process to keep access reviews effective:
- Catalog every service account used by automation and record the intended scope for each.
- Enable gateway logging for all GCP service calls and centralize those logs in a SIEM or audit repository.
- Define a policy in hoop.dev that rejects any request that includes an impersonation flag unless explicitly approved.
- During each review cycle, pull the gateway’s audit logs and compare the observed usage against the documented intent.
- Revoke any service account that shows unexpected impersonation activity and update the policy accordingly.
By making the gateway the authoritative source of truth, reviewers can trust that the logs they examine reflect the real actor, not a masked identity.
Conclusion
Agent impersonation on GCP is a subtle but powerful way to undermine the integrity of access reviews. Because the impersonation decision occurs inside the client, traditional review processes can be fooled. A server‑side gateway that sits on the data path restores visibility, enforces least‑privilege policies, and records a complete audit trail for every request. hoop.dev is built precisely for that role, providing a single control surface that protects the audit trail and keeps access reviews reliable.
Explore the source code and start contributing at GitHub.
