nullcipher

Google Cloud service-account key files ("type": "service_account")

A service-account JSON key file: the -----BEGIN PRIVATE KEY----- block is masked as a private key, the 40-hex-digit private_key_id as a key ID, and client_email as an e-mail address. Below: the exact rule, a live check, why it matters, and what to do if one already leaked.

Live check: Google Cloud service-account key

What an AI chat would receive after masking

{
  "type": "service_account",
  "project_id": "example-project",
  "private_key_id": "[GCP_SA_KEY_ID_1]",
  "private_key": "[PRIVATE_KEY_1]\n",
  "client_email": "[EMAIL_1]"
}

1 × Google Cloud service-account key found and masked, plus 2 other findings.

How nullcipher recognises it

The 40 hex digits after "private_key_id" in a service-account JSON key file. The key file's private key itself is masked by the private-key block rule, and its client_email by the e-mail rule.

This is the rule text of the “Google Cloud service-account key ID” detector in the masking engine, copied from the engine when this page was built. Detectors run in a fixed order and, where two overlap, the earlier one wins.

Example (fake)

{
  "type": "service_account",
  "project_id": "example-project",
  "private_key_id": "0123456789abcdef0123456789abcdef01234567",
  "private_key": "-----BEGIN PRIVATE KEY-----\nEXAMPLEnotARealKey\n-----END PRIVATE KEY-----\n",
  "client_email": "ci-deployer@example-project.iam.gserviceaccount.com"
}

nullcipher replaces it with [GCP_SA_KEY_ID_1]. A shortened key file for a project called example-project: the key ID is the hex digits 0-f repeated, and the private key body is the text EXAMPLEnotARealKey. Google never issued it.

Why it matters in an AI chat

The private key in the file is the credential: whoever has the file can authenticate as the service account and get whatever IAM roles it holds — often broad ones on CI deployer accounts. Google does not expire these keys by default.

The private_key_id is not secret by itself, but it names exactly which key to delete, and together with client_email it tells anyone reading your chat which account and project the key opens. nullcipher masks both, so the AI still sees the file's structure but not whose it is.

Key files are pasted whole into AI chats when a deployment fails with a permission error, because the error message points at the credentials.

If it already leaked

  1. Delete the key, not just the file: in the Google Cloud console open IAM & Admin → Service accounts, click the service account's e-mail, open the Keys tab and click Delete for the leaked key. Google says deleting a key permanently prevents it from authenticating and cannot be undone. [1]
  2. With gcloud: gcloud iam service-accounts keys delete KEY_ID --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com, where KEY_ID is the private_key_id from the file. [1]
  3. Google's usual advice is to disable a key first and wait before deleting it, so you can undo a mistake. That advice is for routine clean-up; for a key that has leaked, deleting it at once is what stops its use.

Sources

  1. Create and delete service account keys — Google Cloud IAM docs — checked 2026-09-25.

Open the full masking tool to mask a whole log, .env file or e-mail — every type at once — and restore the values in the AI's answer. Or see all 229 detectors, with a page for 46 secret types, and how to delete a chat you already sent.