Google Cloud IAM works by binding roles (bundles of permissions) to principals (users, groups, service accounts, or whole domains) on a project. For Claude on Vertex AI, the good news is that the permission surface is small — but the roles involved come from three different Google services (Vertex AI, procurement, and service usage), which is where teams get confused. This reference maps each role to the job function that actually needs it.
The roles Google documents for Claude
| Role | What it grants | Who needs it |
|---|---|---|
roles/aiplatform.user(Vertex AI User) | Includes aiplatform.endpoints.predict — the permission required to make prompt requests to partner models | Developers, CI pipelines, and production service accounts that call Claude |
roles/consumerprocurement.entitlementManager(Consumer Procurement Entitlement Manager) | Enabling partner models in Model Garden — the terms-acceptance step | A platform admin, once per model per project; not runtime identities |
roles/serviceusage.serviceUsageAdmin(Service Usage Admin) | Contains serviceusage.services.enable, needed to switch on the Vertex AI API itself | Whoever bootstraps the project |
roles/logging.viewer(Logs Viewer) | Read Admin Activity, Policy Denied, and System Event audit logs | Ops and security staff doing routine review |
roles/logging.privateLogViewer(Private Logs Viewer) | Additionally read Data Access audit logs — where Claude prediction calls are recorded | Compliance reviewers and incident responders |
Bindings are granted the same way regardless of role, and the principal can be a person, a group, a service account, or a domain:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=group:claude-devs@example.com \
--role=roles/aiplatform.userRead-only and custom roles
Google also ships narrower Vertex AI roles, such as a viewer-level role for people who need console visibility (model cards, quota pages, dashboards) without the ability to send prompts. If someone's job is to observe — a FinOps analyst checking usage, an auditor confirming which models are enabled — prefer a viewer-level role over aiplatform.user; check the current Vertex AI access-control documentation for the exact permission list, since predefined role contents evolve.
For the tightest possible production identity, you can define a custom role containing little more than aiplatform.endpoints.predict, the one permission Google documents as required for prompt requests. That removes every other capability that rides along in the predefined Vertex AI User role. The trade-off is maintenance: custom roles do not pick up new permissions automatically, so when you adopt a new Vertex feature you may need to amend the role. Many teams settle on the predefined role for developers and a custom role for internet-facing production workloads.
Mapping roles to job functions
- Platform admin (one person or small group):
serviceusage.serviceUsageAdminto enable the API,consumerprocurement.entitlementManagerto accept Claude's terms in Model Garden. These are setup-time powers; consider granting them temporarily. - Developers:
aiplatform.user, ideally bound to a Google group rather than individuals so onboarding and offboarding is a group-membership change. - CI pipelines: a dedicated service account with
aiplatform.user(or a predict-only custom role). CI needs to call the model to run evaluations — it never needs to enable models or read audit logs. - Production jobs: one dedicated service account per workload with the predict permission only, per the pattern in service account authentication.
- Security and compliance:
logging.viewerfor routine checks,logging.privateLogViewerfor the reviewers who must see Data Access logs — details in the audit logs deep dive.
Finally, remember that project boundaries are part of the permission model too. All of these bindings are per project, so giving a team its own project for Claude experiments — with aiplatform.user bound broadly there and tightly in production — is often simpler and safer than engineering elaborate custom roles inside a single shared project.
Where to go next
See how these roles fit the broader setup sequence in the project preflight checklist, and read IAM least privilege for the cross-platform principles.