Networking, Identity & Private Connectivity

The Two IAM Roles Every Vertex AI Claude Deployment Needs

Claude on Vertex AI is a partner model, and partner models have a two-step permission story: one role to turn the model on, a different role to call it. Teams that grant only one of the two spend an afternoon staring at 403s.

Claude 3P 101 · Updated July 2026 · Unofficial guide

On Google Cloud, Claude is delivered through Vertex AI's Model Garden as a partner model: a model published by a third party (Anthropic) but served and billed by Google. That partnership is exactly why the IAM setup involves two distinct roles. Enabling a partner model is legally and commercially a procurement act — you are accepting Anthropic's terms through Google's commerce machinery — while calling the model afterward is an ordinary Vertex AI inference call. Google keeps those two acts behind two different roles, and both must be in place before your first successful request.

Role one: turning the model on

To enable a Claude model, someone opens its Model Garden model card and clicks Enable, accepting the Terms of Service in the process. That someone needs the Consumer Procurement Entitlement Manager role, roles/consumerprocurement.entitlementManager. The name gives away the mechanics: behind the scenes, enabling a partner model creates a commerce entitlement through the Cloud Commerce Consumer Procurement API (cloudcommerceconsumerprocurement.googleapis.com), which your organization policy must also allow.

This is a one-time, per-model, per-project action. The natural holder is whoever handles cloud procurement or platform administration — not your application service accounts. Once each Claude model you plan to use is enabled, this role has done its job.

Role two: calling the model

Actually sending prompts requires the aiplatform.endpoints.predict permission, which comes bundled in the Vertex AI User role, roles/aiplatform.user. This is the role your production workloads need, and IAM bindings accept user:, group:, serviceAccount:, or domain: principals — so in practice you grant it to the service account your application runs as, not to individual humans.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:claude-app@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/aiplatform.user"

The same gcloud projects add-iam-policy-binding command with --role=roles/consumerprocurement.entitlementManager grants the procurement role to your admin persona.

The prerequisite people forget: enabling the API itself

Before either role matters, the Vertex AI API (aiplatform.googleapis.com) must be enabled in the project, and that requires a third role: Service Usage Admin, roles/serviceusage.serviceUsageAdmin, which contains the serviceusage.services.enable permission. In many organizations, project creators hold broad roles that include this implicitly, so it goes unnoticed — until a locked-down project fails at step zero.

Rule of thumb: three personas, three roles. Platform admin enables the API (serviceUsageAdmin), procurement or an admin enables each Claude model in Model Garden (entitlementManager), and the workload's service account calls the model (aiplatform.user). No single principal needs all three in production.

What failure looks like

The failure modes map cleanly onto the missing role. If the model was never enabled — or the enabler lacked the entitlement role — requests fail even though your service account's aiplatform.user binding is correct. If the model is enabled but the caller lacks aiplatform.endpoints.predict, you get a permission-denied error on the predict call itself. And if the Vertex AI API was never enabled, nothing works at all. When triaging a 403, check in that order: API enabled, model enabled, caller role bound. Our 403 diagnosis guide walks the same tree in more detail.

Two more procurement wrinkles worth knowing. Google's docs note that Anthropic prohibits certain resellers from reselling its products — if your billing account is managed by a prohibited reseller, you cannot accept the Terms of Service or enable Claude models at all. And inside an Assured Workloads boundary, enabling Claude via Marketplace may require violation exceptions for cloudcommerceconsumerprocurement.googleapis.com and commerceagreement.googleapis.com. Both are worth surfacing to your platform team before the day you plan to go live.

Where to go next

For the enablement clicks themselves, see the Model Garden setup walkthrough; for running workloads as service accounts, see service account auth on Vertex. The broader role catalog lives in the Vertex IAM roles reference.

Sources