# IAM User / Member

> IAM members on GCP (human accounts and service accounts alike) carry no charge, but stale identities holding broad roles are the top access-hygiene risk in most projects. ZopNight lists every member from the project-level IAM policy during discovery, distinguishing service accounts deterministically, to power ownership attribution and audit views.

Source: https://zop.dev/integrations/gcp/iam-user
Updated: 2026-08-19

---

An IAM user or member is an identity (user account or service account binding) granted roles in the project. Identities carry no direct cost, but stale accounts with broad roles are the top access-hygiene risk in most projects.

## Identities cost nothing; their access is the risk

No meter attaches to an IAM member. Google charges for what identities do, never for their existence. The value of tracking members is entirely about hygiene and accountability: who can create the resources that do bill, who owns the ones already running, and which credentials would let an attacker or a runaway script spend money in your name. A departed engineer's account still holding roles, or a CI service account whose key leaked to a public repository, costs nothing on the invoice until the day it costs everything.

## Project-scoped discovery of members

ZopDev lists IAM members during discovery to power ownership attribution and access-hygiene checks. The listing reads the project-level IAM policy through Cloud Asset Inventory, and it is deliberately project-scoped: per-resource ACLs on individual buckets or instances, and bindings inherited from folders or the organization, are out of scope, keeping the imported picture to principal-to-role mappings at the level teams actually manage. Each member is recorded under its canonical IAM string (the user: or serviceAccount: form) so identity stays stable across discovery runs. Metadata only; nothing here is schedulable or billable.

## Telling humans from machine identities

The discovery distinguishes service accounts from people deterministically, not by guesswork: emails ending in the gserviceaccount.com suffix are GCP-managed service accounts, and names carrying the svc.id.goog marker are GKE Workload Identity bindings. Everything else is a human on a customer domain. The split matters for review, because the two populations rot differently: humans leave the company while their grants stay, and service accounts multiply per-pipeline until nobody remembers which automation still runs. Both patterns surface in ownership and audit views.

## Where IAM members live in the console

Google Cloud console → IAM & Admin → IAM lists every principal on the project with its granted roles. Filtering the principal column by gserviceaccount.com separates automation from people in 1 click, and any member whose roles nobody can explain is the audit's starting point.