Claude on Vertex AI authenticates through Application Default Credentials (ADC) — Google's standard mechanism where client libraries automatically discover credentials from the environment instead of taking an API key. During development that usually means gcloud auth application-default login, which borrows your user identity. That is exactly what you do not want in production: when the engineer who set it up leaves, or rotates their password, the pipeline breaks, and audit logs attribute machine traffic to a human. The fix is a service account — a non-human identity that your workload runs as.
Create a dedicated service account
Create one service account per Claude-calling workload (for example claude-support-bot@your-project.iam.gserviceaccount.com), rather than reusing a broad shared account. A dedicated identity gives you three things: least-privilege role bindings scoped to what this workload needs, clean attribution in Cloud Audit Logs, and the ability to revoke one workload without touching others. Service account creation itself is standard Google Cloud IAM work in the console or with gcloud; see Google's IAM documentation for the mechanics.
Bind the right roles — and only those
For a production workload that sends prompts, Google's documentation for partner models is specific: making prompt requests requires the aiplatform.endpoints.predict permission, which is included in the Vertex AI User role (roles/aiplatform.user). Grant it like this:
# One-time grant by a project admin
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=serviceAccount:claude-support-bot@PROJECT_ID.iam.gserviceaccount.com \
--role=roles/aiplatform.userWhat the service account does not need is the Consumer Procurement Entitlement Manager role (roles/consumerprocurement.entitlementManager). That role exists to enable partner models in Model Garden — a one-time administrative act performed by a human. Keeping it off your runtime identity is basic least privilege. For a finer-grained breakdown of who needs which role, see the IAM roles reference.
Key JSON versus impersonation
Once the service account exists, there are two broad ways for code to act as it, and they are not equally safe.
| Approach | How it works | Trade-off |
|---|---|---|
| Downloaded key JSON | Export a long-lived private key file; point ADC at it via GOOGLE_APPLICATION_CREDENTIALS | Works anywhere, including outside Google Cloud — but the file is a permanent secret to store, rotate, and leak |
| Attached identity / impersonation | Run the workload on a Google Cloud service (Cloud Run, GKE, Compute Engine) with the service account attached, or have an authenticated principal impersonate it for short-lived tokens | No file to steal; credentials are short-lived and issued by the platform — but requires running on (or federating into) Google Cloud |
The practical guidance: if your Claude workload runs on Google Cloud compute, attach the service account to the workload and let ADC pick it up automatically — no key file ever exists. Reach for downloaded key JSON only when the caller genuinely lives outside Google Cloud and workload identity federation is not an option, and then treat the file like any other production secret: secret manager storage, scheduled rotation, never in a repository. Consult Google's IAM best-practice documentation for the current recommended patterns.
The application code doesn't change
Whichever credential path you choose, the Python SDK is identical, because AnthropicVertex simply follows the ADC chain:
from anthropic import AnthropicVertex
# Uses whatever ADC finds: attached service account,
# GOOGLE_APPLICATION_CREDENTIALS key file, or impersonated creds.
client = AnthropicVertex(project_id="your-project-id", region="global")
msg = client.messages.create(
model="claude-sonnet-5",
max_tokens=256,
messages=[{"role": "user", "content": "Hello from production."}],
)This separation is a feature: security teams can change how credentials are issued — say, moving from key files to attached identities — without a single code change in the application.
Where to go next
Map out permissions across your whole team with the Vertex IAM roles reference, then verify your setup end to end with the first-API-call walkthrough. For local development credentials, see the ADC guide.