GCP Service Account JSON Key

Detects GCP service-account JSON key files, distinguishing bare type=service_account record markers (discovery only) from complete keys whose object also carries an escaped PEM private_key and a .iam.gserviceaccount.com client_email (enforcing), with project_id/private_key_id as additional high-confidence evidence.

Type: regex
Engine: universal
Confidence: low
Confidence justification: Low confidence: generic pattern format that may match unrelated data. Corroborative evidence keywords are essential for reliable detection. Added context gating and exclusion rules improve precision and reduce incidental matches.
Detection quality: Partial
Jurisdictions: global
Regulations: Criminal Code Act 1995 (Cth)
Frameworks: CIS Controls, ISO 27001, NIST CSF, PCI-DSS, SOC 2
Data categories: credentials, security
Scope: specific
Risk rating: 8
Platform compatibility: Purview: Compatible, GCP DLP: Compatible, Macie: Compatible, Zscaler: Compatible, Palo Alto: Compatible, Netskope: Compatible

Pattern

"type"\s*:\s*"service_account"

Corroborative evidence keywords

api key, api_key, apikey, access key, secret key, private key, auth token, authorization, access token, bearer, conn str, connection string, connectionstring, cookie, credential, database, host, [object Object], oauth, passphrase (+33 more)

Proximity: 300 characters

Should match

"type": "service_account" — GCP service account JSON key marker
"type" : "service_account" — GCP key with extra spaces
"type":"service_account" — GCP key without spaces (marker only - discovery tier)
{"type":"service_account","project_id":"prod-1","private_key_id":"abc9","private_key":"-----BEGIN PRIVATE KEY-----\nMIIEvQIBADANBg...\n-----END PRIVATE KEY-----\n","client_email":"deploy@prod-1.iam.gserviceaccount.com"} — Complete JSON key with PEM private_key, service-account client_email and key identifiers reaches the enforcing tiers
{"type":"service_account","project_id":"prod-1"} — Marker plus project_id without credential material stays discovery-only

Should not match

"type": "user_account" — Wrong account type value (user_account instead of service_account)
"kind": "service_account" — Wrong key name (kind instead of type)
type: service_account — YAML format instead of JSON (no quotes)
template example placeholder record identifier — Template/sample context should be excluded even when anchor words are present
Documentation: {"type":"service_account","private_key":"<redacted>","client_email":"example@demo.iam.gserviceaccount.com"} — Redacted documentation example carries no PEM material and trips the template exclusion at every tier
The cloud team reviewed service-account naming conventions. — Administrative cloud prose contains no JSON service_account marker or key-file structure

Known false positives

Authentication-related terminology in software documentation, security training materials, or system architecture descriptions without actual credentials. Mitigation: Require proximity to credential-specific patterns (API keys, connection strings, tokens) rather than general security terminology.
Code snippets and configuration examples containing credential-related keywords or placeholder values in developer documentation. Mitigation: Check for common placeholder patterns (example.com, localhost, 0000) and documentation file types to reduce false positives from technical writing.