Skip to main content
The permission list below is authoritative — it’s reproduced verbatim from the onboarding module’s main.tf. It is the complete, exact set of read-only permissions the 0Labs scanner role grants. There are zero write/mutate verbs. A security team can diff this directly against the running custom role.

​
The keyless, broker-based model

0Labs never holds keys. The scanner service account lives in your project; the only trust you grant is roles/iam.serviceAccountTokenCreator for 0Labs’ published broker principal on that scanner SA — i.e. permission to mint a short-lived token as the read-only scanner SA, nothing else. Broker principal (stable, publishable):
Customers grant token-creator to this principal once; 0Labs’ per-environment workers reach your scanner by delegating through it. Revoke anytime by removing that single binding.

​
Read permissions (all scopes)

These apply to every connector — organization or project scope.

​
Organization-scope extras

When you onboard at organization scope, the role additionally includes resource-hierarchy enumeration so 0Labs can discover all current and future projects to scan. These are added only for org scope — GCP rejects folder/org-level permissions inside a project-level custom role.

​
The standalone security-reviewer reference

If a security reviewer wants the canonical source rather than this table, the list is curated and least-privilege in the module itself:
  • File: main.tf in terraform-google-zerolabs-connector
  • Locals: read_permissions (all scopes) and org_only_permissions (org scope only)
  • Custom role title: Agent0 Read-Only Scanner
The custom role description states it plainly: “Read-only config/IAM access for 0Labs posture scanning. No write permissions.”