Teams arriving at Vertex AI from API-key providers often stall on the same question: "where do I get the key?" The answer — you don't — is the most important thing to understand about Claude on Google Cloud. Requests authenticate through Application Default Credentials (ADC), Google's standard mechanism for all of its cloud services. Once you see how it works, it is both simpler and safer than key management.
What ADC actually is
ADC is not a credential; it is a discovery convention. When your code creates a client, the underlying Google auth library looks for credentials in a defined order of places — an explicitly configured credential file if one is set, a developer's locally stored login, or the identity attached to the cloud environment the code is running in. The first one found wins. Your application code is identical everywhere; only the environment differs.
The consequence worth repeating to your security team: correctly configured code contains no secret at all. There is nothing to accidentally commit to a repository, nothing to paste into a ticket, and — for workloads running on GCP — often nothing to rotate manually, because the platform issues short-lived credentials automatically.
Setting up developers
On a laptop, a developer authenticates once using the gcloud command-line tool's application-default login flow, which opens a browser, has them sign in with their normal corporate Google identity, and stores a local credential that ADC then discovers. From that point, code using the Vertex client just works. Two practical notes: the developer's own identity must have permission to invoke Vertex models in the target project (access control still applies — ADC is authentication, not authorization), and local credentials expire, so "it worked last month and now returns an auth error" usually just means logging in again.
Setting up services
Production workloads should never use a human's credentials or a downloaded key file. Instead, attach a service account — a machine identity — to the compute the workload runs on, and grant that service account the narrowest role that permits invoking the models it needs, in the project it needs. ADC discovers the attached identity automatically; the deployment contains no credential artifact. For workloads running outside Google Cloud, prefer workload identity federation (which exchanges your existing environment's identity for GCP access) over exported key files; exported keys are the pattern to treat as a last resort, because they are long-lived secrets you must then store, rotate, and eventually leak.
What the SDK sees
The official Python client for Vertex (pip install -U "anthropic[vertex]") takes no credential parameter at all — just the project and region. Everything auth-related happens through ADC underneath.
from anthropic import AnthropicVertex
# No API key, no credential path: ADC finds the right identity
# for this environment (developer login or attached service account).
client = AnthropicVertex(project_id="my-gcp-project", region="global")
message = client.messages.create(
model="claude-sonnet-5",
max_tokens=512,
messages=[{"role": "user", "content": "Reply with OK if auth works."}],
)
print(message.content)The failures you will actually hit
Three cover most support tickets. Permission denied: ADC found an identity, but that identity lacks invoke rights in the project — fix the role grant, not the login. Wrong project: the credentials are valid but your client points at a project where the model is not enabled or the identity has no access; check the project_id argument before anything else. Expired developer credentials: local logins age out; re-running the login flow resolves it. When debugging, always ask the two questions separately — "which identity did ADC pick up?" and "what is that identity allowed to do?" — because conflating them is what makes auth issues feel mysterious.
Where to go next
With authentication settled, Your First Claude Call on Google Vertex AI completes the loop to a working response, and the Vertex enterprise primer covers projects, the global endpoint, and governance. For the cross-cloud view of credential hygiene, see Keeping API Keys and Credentials Out of Your Code.