Use your own login. Google's documentation says service account keys create a security risk and are not recommended, because a stolen key works without any further information. For local work, run gcloud auth application-default login, or impersonate a service account, and leave key files out of projects.
How ADC finds credentials
Application Default Credentials, or ADC, is a strategy the authentication libraries use to find credentials automatically from the application environment. Google's page explains that your code can run in development or production without changing how it authenticates.
ADC searches three places, in this order:
- The
GOOGLE_APPLICATION_CREDENTIALSenvironment variable, which points to a credential JSON file. - A credential file created by the
gcloud auth application-default logincommand. - The attached service account, returned by the metadata server.
Google adds that the order is not a ranking of which location is better. It points to its setup guide for that.
What can be in the JSON file
The file named by the environment variable can be a credential configuration file for Workforce Identity Federation, one for Workload Identity Federation, or a service account key. Of these, the documentation says service account keys create a security risk and are not recommended. Unlike the other file types, a compromised service account key can be used by a bad actor without any additional information.
That is the important distinction for a developer. A federation configuration file points to a way to obtain credentials. A key file is the credential.
The local login option
Running gcloud auth application-default login creates a JSON file containing the credentials you provide, either from your user account or from impersonating a service account. On Linux and macOS it is written under $HOME/.config/gcloud/application_default_credentials.json. On Windows it goes to %APPDATA%\gcloud\application_default_credentials.json.
The documentation notes that the credentials you provide to ADC this way are distinct from the credentials the gcloud CLI itself uses. So logging in to the CLI does not by itself set up ADC for your code. Run the ADC login separately.
A safer local setup
| Goal | Approach |
|---|---|
| Run your own code against cloud APIs | ADC login with your user account |
| Test with a service account's permissions | ADC login with impersonation, using the account's email address |
| Run on a cloud workload | Attached service account, no file at all |
| Run from an external system | Workload Identity Federation configuration |
The documentation says you can impersonate a service account by providing its email address to the login command. That lets you try its permissions without ever downloading a key.
If a key file already exists
Find where it lives, check whether GOOGLE_APPLICATION_CREDENTIALS points to it in your shell profile or project files, and replace it with the ADC login. Then ask your cloud administrator to disable and delete the key. Because the JSON file is the credential, treat copies in old backups, container images and chat messages as exposed.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Does gcloud auth login set up ADC?
The documentation says ADC credentials are distinct from the credentials gcloud uses. Run the application default login to create the ADC file.
Where does the ADC login file go?
Under .config/gcloud in your home directory on Linux and macOS, and under APPDATA on Windows, per the documentation.
Is a service account key ever required?
Google says keys are not recommended. If a tool truly needs one, scope it narrowly and rotate it.
Sources
Last reviewed: 19 October 2026.
