How should security teams investigate service account key usage in Google Cloud?

Start by correlating Cloud Monitoring authentication events with audit logs. Use the key ID or service account ID to identify when the key was used, then review creation logs, caller IP, user agent, and impersonation chains. This helps distinguish human activity from workload activity and supports faster review of exposed or overused keys.

Why This Matters for Security Teams

service account key in Google Cloud are not just “another credential.” They are durable cryptographic proof that can be copied, replayed, and used outside the original workload path, which makes investigation far more important than simple inventory. When a key appears in logs, the real question is whether that usage matches an approved workload, an expected human break-glass event, or an exposed secret that is now being abused. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for logging, accountability, and traceability, but key investigations in cloud environments need more context than control checklists alone.

Security teams often miss that service account key usage can look legitimate even when it is not. A valid key may still signal a compromised host, an over-permissioned pipeline, or a workload that has drifted beyond its intended scope. NHIMG’s State of Non-Human Identity Security shows that lack of credential rotation remains a leading cause of NHI-related attacks, which is why investigation has to include key lifetime, usage patterns, and exposure history, not only the moment of access. In practice, many security teams discover risky key use only after a downstream API call or data access event has already occurred, rather than through intentional monitoring.

How It Works in Practice

Start with a timeline that joins Cloud Monitoring authentication events, Cloud Audit Logs, and the service account key ID or service account ID. The goal is to answer four questions quickly: when was the key created, when was it first seen in use, from where was it used, and what principal or workload preceded the call. A single key may be used by a workload in one region, a deployment pipeline in another, and a human operator during an incident, so the investigation needs to separate normal operational variance from true anomaly.

Google Cloud logs can reveal the surrounding context if investigators look beyond the authentication event itself. Review caller IP, user agent, request metadata, and any impersonation chain to see whether the key authenticated directly or was involved in a chained flow through another identity. That matters because exposed service account keys are often paired with lateral movement, tool chaining, or privilege expansion. NHIMG’s 230M AWS environment compromise and Google API Keys Exposure — Gemini AI both illustrate how quickly exposed credentials can become a broader cloud investigation.

• Correlate the first-seen key usage with key creation and secret distribution events.
• Compare the source IP and user agent against approved workloads, CI/CD runners, and admin jump hosts.
• Check whether the service account was impersonated by another identity or used directly.
• Review the permissions bound to the service account to determine blast radius if the key was stolen.
• Look for follow-on activity such as new token minting, storage access, IAM changes, or cross-project calls.

Current guidance suggests treating key usage as a signal of identity provenance, not just authentication success. In mature environments, teams also compare the event to workload identity claims, such as expected deployment metadata or service mesh identity, because static keys alone do not prove which workload actually executed the request. These controls tend to break down in hybrid environments with shared automation accounts and unmanaged developer laptops because the same key can legitimately appear in too many places.

Common Variations and Edge Cases

Tighter key governance often increases operational friction, requiring organisations to balance investigative certainty against developer velocity and pipeline stability. That tradeoff is especially visible when service account keys are used for legacy integrations, third-party tooling, or air-gapped automation that has not yet moved to workload identity.

There is no universal standard for this yet, but best practice is evolving toward short-lived credentials and keyless patterns wherever possible. In Google Cloud, that usually means reducing reliance on persistent keys and shifting toward workload identity, federated access, or impersonation models with stronger traceability. For agentic or automated systems, the logic is even stricter: static keys are difficult to attribute when tools chain together quickly, which is why The 2026 Infrastructure Identity Survey is relevant here, showing that many security leaders still rely heavily on static credentials despite the risks.

Edge cases deserve special attention. A key used from an unusual IP is not automatically malicious if the workload recently moved regions. Likewise, a key used by a new user agent may reflect a platform upgrade, not compromise. The decisive factor is whether the usage matches the established identity path and change record. When those records are missing, incomplete, or inconsistent across projects, investigations slow down and false positives rise. That is where service account key investigations tend to fail in practice: not in the logs themselves, but in the absence of trustworthy baseline identity context.

Related resources from NHI Mgmt Group

• How should security teams govern access when users can bind the organisation to a cloud security service agreement?
• How should security teams assess privilege escalation risk in Google Cloud environments with hierarchical IAM inheritance?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?