Many assume that service accounts are just another kind of user and that reviewing them is no different from reviewing human accounts, this is wrong. Access reviews for non‑human identities require a different approach because the credentials are often long‑lived, embedded in code, and used by automated workloads that bypass traditional human‑centric controls.
Why access reviews matter for non‑human identities
On Google Cloud Platform (GCP), a non‑human identity can be a service account, a workload‑identity federation token, or an AI‑driven agent that authenticates via OIDC. These identities are the workhorses of CI/CD pipelines, data‑processing jobs, and backend services. Because they run without a person at the keyboard, they tend to be granted broad permissions that are rarely revisited. When a breach occurs, the attacker can hijack a service account and move laterally with the same privileges the original workload enjoyed.
Traditional access‑review cycles focus on human users: checking group membership, last login, and role appropriateness. Applying the same checklist to a service account often misses two critical facts. First, the account may never log in interactively, so “last login” provides no signal. Second, the permissions are usually inherited from project‑level IAM bindings, making it easy for a single service account to inherit more rights than it truly needs.
The unsanitized starting state
In many organizations, the default workflow is to create a service account, assign it a role like Editor or Owner, and embed its JSON key in a repository or CI secret store. The key is then checked into pipelines, shared across teams, and rarely rotated. No central log records which pipeline invoked the account, which API calls were made, or whether the response contained sensitive data. When a security audit asks for evidence of who accessed a database or a Kubernetes cluster via a service account, the answer is often “we don’t know.”
This state violates the principle of least privilege and makes access reviews ineffective. The review process ends up being a checkbox exercise rather than a risk‑based assessment.
Adding proper non‑human identity without solving the review problem
Organizations that recognize the issue may start by moving to workload‑identity federation, where workloads obtain short‑lived tokens from an identity provider instead of long‑lived keys. They also tighten IAM bindings, granting only the specific permissions a workload needs. While these steps improve the setup, they define who the request is and whether it may start, they do not address the core gap: there is still no enforcement point that records each request, masks sensitive fields, or requires a human approval before a risky operation proceeds.
In this configuration, a pipeline still connects directly to the target service, be it Cloud SQL, GKE, or Cloud Storage, using the federated token. The token proves the workload’s identity, but the data path is completely open. No audit trail is captured, no inline masking of secrets occurs, and no just‑in‑time (JIT) approval can be injected. Consequently, access reviews remain blind to the actual usage patterns of non‑human identities.
Why a data‑path gateway is the missing piece
This is where a Layer 7 gateway that sits in the data path becomes essential. By proxying every connection between a non‑human identity and the target resource, the gateway can enforce the controls that make access reviews meaningful.