An offboarded contractor’s CI token still lives in a shared secret store and can push new container images to a production registry, violating least privilege. A nightly data‑pipeline job runs under a service account that has Owner rights on a whole GCP project, even though it only needs to write to a single BigQuery table. An over‑scoped API key baked into a Helm chart grants any pod the ability to delete Cloud SQL instances.
These patterns are common in fast‑moving teams. Engineers copy‑paste service‑account JSON files into repositories, grant broad IAM roles to keep the CI pipeline moving, and rarely revisit the permissions once the job is working. The result is a landscape where non‑human identities carry more power than they ever need, and there is little visibility into what those identities actually do.
When a service account can delete a database, rotate encryption keys, or modify firewall rules, the principle of least privilege is effectively ignored. An attacker who compromises a CI runner inherits every permission the runner was granted, turning a single breach into a full‑scale compromise of the cloud environment.
Why least privilege matters for non‑human identities
Non‑human identities, service accounts, CI/CD tokens, automation bots, are not tied to a person who can be reminded to rotate credentials or to review access regularly. They exist to perform a specific function, yet they are often given static, high‑privilege credentials that never change. Because the credentials are long‑lived, any compromise is long‑lasting. Because the permissions are broad, the potential blast radius is huge.
Applying least privilege to these identities means giving them only the exact scopes required for the job, rotating the credentials frequently, and ensuring that every request can be traced back to the originating identity. Without a control point that can observe and enforce these rules, the cloud provider’s IAM system alone cannot guarantee that a service account will not exceed its intended purpose.
The missing enforcement layer
Most teams already federate non‑human identities to GCP using OIDC or workload identity pools. That step fixes the authentication problem: the CI job can obtain a short‑lived token instead of a static key. However, the request still travels directly from the runner to the GCP API endpoint. The gateway that sits between the token and the target resource is absent, so there is no place to inspect the request, enforce additional policies, or record the exact command that was executed.
In this configuration, the following gaps remain:
- There is no real‑time audit of each API call made by a service account.
- Sensitive response fields (for example, secret values returned by Secret Manager) cannot be masked before they reach logs or downstream tools.
- Requests that deviate from the approved workflow cannot be paused for human approval.
- Even if a token is revoked, any in‑flight request bypasses additional checks.
All of these gaps can be closed only by placing an enforcement point on the data path.
hoop.dev as the data‑path gateway
hoop.dev is a Layer 7 gateway that sits between the identity provider and the GCP resources that non‑human identities need to reach. The setup phase registers the OIDC federation, defines fine‑grained IAM roles for each service account, and deploys a network‑resident agent near the target resource. Once the gateway is in place, every request from a CI job, automation bot, or service account passes through hoop.dev before it hits the GCP API.
Because hoop.dev occupies the data path, it is the only place where enforcement can happen. It validates the incoming token, checks the request against policy, and then forwards the call. If the request matches an approved pattern, hoop.dev lets it pass; if it violates a least‑privilege rule, hoop.dev can block it, trigger a just‑in‑time approval workflow, or mask sensitive fields in the response.
Enforcement outcomes that protect least privilege
- hoop.dev records each session, providing a complete audit trail that ties every API call to the originating service account.
- It can mask secret fields in responses, ensuring that logs and downstream consumers never see raw credentials.
- It enforces just‑in‑time approval for high‑risk operations, such as deleting a Cloud SQL instance, even when the underlying service account technically has the permission.
- It blocks commands that fall outside the declared intent of the automation, preventing accidental or malicious overreach.
These outcomes exist only because hoop.dev sits in the data path; the same setup without the gateway would leave the requests unchecked.
Putting the pieces together for true least privilege
The overall architecture looks like this:
- Setup: Define OIDC federation, create narrowly scoped IAM roles, and provision service accounts for each automation workload.
- The data path: Deploy hoop.dev as the gateway that all non‑human traffic must traverse.
- Enforcement outcomes: Let hoop.dev record sessions, mask data, require approvals, and block out‑of‑scope calls.
With this pattern, a compromised CI runner cannot automatically delete resources or exfiltrate secrets because hoop.dev will intervene based on the policy you defined. At the same time, you retain the agility of automation because the gateway operates transparently for approved actions.
Getting started
To try this approach, follow the getting started guide to deploy the gateway and configure a GCP workload identity pool. The learn section provides deeper coverage of policy definition, session replay, and inline masking. All configuration details are available in the open‑source repository.
Explore the open‑source code on GitHub to see how the gateway integrates with GCP and to contribute improvements.
FAQ
Do I still need to manage IAM roles for service accounts?
Yes. hoop.dev relies on the underlying IAM permissions to enforce least‑privilege boundaries. The gateway adds an extra layer of verification and audit, but the base role definitions remain essential.
Can hoop.dev work with existing CI pipelines without code changes?
Because hoop.dev operates at the protocol level, you can point your CI tools at the gateway endpoint instead of the raw GCP endpoint. No changes to the build scripts are required beyond updating the target host.
What happens to logs that contain secret values?
hoop.dev can mask those fields before they are written to any downstream log sink, ensuring that secret material never appears in plain text in your logging pipeline.
