# Leaked GCP Service Account Key? Delete It, Check Logs > GCP service account JSON key exposed on GitHub? Delete the key, check Cloud Audit Logs and block key creation. Step-by-step guide. Source: https://leakwatch.net/secrets/gcp-service-account-key --- [LeakWatch](/) [Product](/product)[Live feed](/leaks)[Guides](/secrets)[Blog](/blog)[Free scan](/) 1. [Home](/) 2. [Secrets](/secrets) 3. GCP Service Account Key Cloud · Secret guide # Leaked GCP Service Account Key: what to do in the first hour Critical severityDetected onlyLast verified October 2, 2026 · 5 min read A GCP service account key is a JSON file that lets a program authenticate as a service account in Google Cloud. Whoever holds the file does not need a password, a second factor or your network: they sign in as that service account from anywhere and get every IAM role it has been granted. That can mean storage buckets, databases, compute instances or the ability to create more credentials. Delete the key first, then work out what the service account could reach. [Check your GitHub account for leaked secrets — free](/) Provider Google Cloud Severity Critical Impact Cloud infrastructure access Checked live by LeakWatch No Revoke at [Google Cloud](https://console.cloud.google.com/iam-admin/serviceaccounts) ## What a GCP service account key looks like The key is a small JSON document downloaded once, when the key is created. It contains the service account’s email, the project ID and a PEM private key stored as a single string with escaped line breaks: ```text { "type": "service_account", "project_id": "", "private_key_id": "…XXXX", "private_key": "", "client_email": "@.iam.gserviceaccount.com" } ``` The private key is the secret. The email and project ID are identifiers: they tell an attacker where to point, but they do not grant access alone. The `private_key_id` is what you will match in the console to find the right key to delete. Two things are *not* this secret. A Google API key (`AIza…`) is a different, much weaker credential: see the [Google API key](/secrets/google-api-key) guide. A service account key is also different from the short-lived tokens Google issues to workloads running on its own infrastructure, which are never written to a file and cannot be committed. ## How GCP service account keys get leaked - **The downloaded JSON file in the repository.** The console offers the file once, and it often lands in the project folder next to the code, then gets committed with a broad `git add`. - **Application config.** Key contents pasted into `.env`, Terraform variables, Kubernetes secrets manifests or CI configuration files, usually as a single-line string. - **Container images.** A key copied into a Docker image with `COPY` so the app can authenticate, and the image then published to a public registry. - **Notebooks and tutorials.** A Colab or Jupyter cell that loads the key inline, saved with its outputs. - **Shared archives and support threads.** A zipped project or a log attached to a ticket, with the file still inside. ## What to do in the first hour 1. **Find the service account and the key.** In the Google Cloud console open *IAM & Admin* → *Service Accounts*, select the account named in `client_email`, and open its *Keys* tab. The `private_key_id` from the leaked file tells you which entry it is. 2. **Create the replacement only if you must.** If the workload runs on Google Cloud, prefer attaching the service account to the resource, or using Workload Identity Federation from outside, so no key file exists at all. If a key is unavoidable, create a new one and deploy it before step 3. 3. **Delete the exposed key.** On the *Keys* tab delete it. Deleting ends the exposure; disabling the whole service account is an option if you cannot tell which keys were copied. 4. **Audit what it did.** Open *Logging* → *Logs Explorer* and look at Cloud Audit Logs for the service account’s email, covering the period since the exposure. Admin Activity logs are on by default. Data Access logs often are not, so a quiet log is not proof that no data was read. 5. **Look for new credentials and resources.** Check *IAM* for new members or roles, and the service account’s *Keys* tab for keys you did not create. Review compute instances, Cloud Run services, scheduled jobs and storage buckets you do not recognize. Not sure what else leaked? [Run a free scan](/). 6. **Reduce its power.** Open *IAM* and remove roles the service account does not need. Roles such as Owner or Editor on a service account turn one leaked file into a project-wide incident. 7. **Prevent a repeat.** Under *IAM & Admin* → *Organization Policies*, the constraint that disables service account key creation can be enforced for a project or organization. Then remove the file from the repository and rewrite history if you want to. See [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github). [Not sure what else leaked? Run a free scan.](/) ## Revoke it at Google Cloud Open [console.cloud.google.com/iam-admin/serviceaccounts](https://console.cloud.google.com/iam-admin/serviceaccounts), choose the project the key belongs to (the `project_id` in the file), select the service account, and delete the key on its *Keys* tab. Keys belong to the project that owns the service account, so a key you cannot find is usually in another project. Once deleted, requests signed with it are rejected, although access tokens already issued from it may keep working for a short time, up to about an hour. ## How LeakWatch detects it The rule is called GCP Service Account. LeakWatch looks for the `private_key` field of a service account JSON file whose value is a PEM private key, with the line breaks written as escaped `\n` sequences as Google produces them. That is why a plain private key block in a `.pem` file is handled by a different rule. LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it. LeakWatch detects this format but does **not** check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it. ## FAQ I deleted the key. Is the service account safe? The key is dead, but anything the attacker did while it was valid stays. Check for new keys, new IAM bindings and new resources, because those can persist after the original key is gone. Can I find out who used the key? Cloud Audit Logs record the service account’s email and often the caller’s IP address and user agent for each call. They show which API calls were made, but they cannot show data reads unless Data Access logging was enabled for that service. Should I stop using service account keys altogether? Where you can, yes. Attached service accounts and Workload Identity Federation remove the file, and an organization policy can block new keys. A key that never exists cannot be committed. ## Related - [AWS access key](/secrets/aws-access-key) - [Azure Client Secret](/secrets/azure-client-secret) - [Terraform Cloud API Token](/secrets/terraform-cloud-api-token) - [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github) - [Which vendors leak most this week](/leaks/trends) - [All secret guides](/secrets) [Get alerted next time a secret leaks — create a free account](/) LeakWatch is not affiliated with Google Cloud. ![Gabriel Diyan, founder of LeakWatch](/brand/Photo-Gabriel-Diyan.webp) Gabriel Diyan (0xCr0c0) Cybersecurity student, founder of LeakWatch. I built and run the scanner described here — the detection patterns, the false-positive classifier and the provider validators are mine. [More about who I am](/about). [GitHub](https://github.com/Leakwatch-Scan) · [X](https://x.com/LeakwatchScan) · [LinkedIn](https://www.linkedin.com/in/gabriel-diyan-80a378375) · [GitHub (personal)](https://github.com/crocogab) LeakWatch Secrets leak into public commits every minute. This watches the forges for yours. Built and run by [Gabriel Diyan](/about), a cybersecurity student — [why LeakWatch exists](/about). Scan - [Product](/product) - [Live feed](/leaks) - [Trends](/leaks/trends) - [API docs](/docs) - [CI/CD](/docs?tab=ci) Read - [Blog](/blog) - [Secret guides](/secrets) - [Changelog](/changelog) - [About](/about) Verify - [Security](/security) - [Privacy](/privacy) - [Terms](/terms) - [Legal](/legal) - [Contact](/contact) - [Status](https://status.leakwatch.net) © 2026 LeakWatch [GitHub](https://github.com/Leakwatch-Scan)[X](https://x.com/LeakwatchScan)