GCP security best practices still fail without identity controls

At a glance

What this is: This is a practical guide to reducing GCP attack surface, with a clear finding that cloud-native security is insufficient without stronger access and secrets governance.

Why it matters: It matters because GCP security failures often stem from identity sprawl, standing privilege, and unmanaged secrets rather than from the platform itself.

👉 Read Britive Team's guide to GCP security best practices and attack surface reduction

Context

GCP security is not just a platform question, because the shared responsibility model leaves customers accountable for how identities, permissions, and secrets are configured. In practice, that means the attack surface grows when teams rely on native controls without continuous visibility into service accounts, keys, and policy drift.

For IAM and NHI teams, the central issue is that cloud resources can be easy to create and hard to govern at scale. The article reflects a common starting position: organisations often treat cloud security as a tooling problem first, when the deeper issue is access discipline across human and synthetic identities.

Key questions

Q: How should teams reduce attack surface in GCP without losing operational speed?

A: Use least privilege, dynamic permissioning, and continuous visibility together. The practical goal is to remove standing access where possible, keep hierarchy ownership clear, and treat service accounts and automation as first-class identities. If a control slows work without reducing blast radius, redesign it rather than relaxing governance.

Q: What is the difference between least privilege and dynamic permissioning in cloud IAM?

A: Least privilege defines the minimum access a principal should have, while dynamic permissioning defines how long that access should exist. In cloud environments, both matter. Least privilege limits scope, and dynamic permissioning limits duration. Together they reduce the chance that an exposed credential or compromised account can be reused.

Q: Why do service accounts create more risk than many teams assume?

A: Service accounts often hold durable access, broad scopes, and weak human ownership. That makes them easy to forget and hard to review. If a service identity is compromised, it can move through cloud resources with far less friction than a person would have under stronger session controls.

Q: Should organisations prioritise secrets rotation before access cleanup?

A: No. Secrets rotation helps, but access cleanup usually delivers faster risk reduction because it removes unnecessary paths in the first place. Teams should first identify where credentials are over-scoped, then rotate or retire the remaining secrets according to business criticality and exposure level.

Technical breakdown

Shared responsibility in GCP and the identity gap

GCP’s shared responsibility model separates platform security from customer configuration. Google secures the underlying cloud service, but customers must set permissions, hierarchy, logging, and secret handling correctly. That distinction matters because most real exposure comes from mis-scoped identity, not from the cloud service itself. When teams create projects, service accounts, and storage permissions without strong governance, the result is a growing set of resources that can be reached, misused, or forgotten. For NHI governance, the key point is that workload and synthetic identities need the same control discipline as human users, often with stricter limits.

Practical implication: map who owns each GCP identity and require configuration reviews for every permission-bearing object.

Dynamic permissioning versus standing privilege

Dynamic permissioning means granting access only for the duration of a task, then removing it when the work is complete. In GCP environments, this addresses a familiar problem: standing privileges become attractive targets because they remain valid long after the operational need has passed. The article’s emphasis on dynamic permissioning applies equally to applications and scripts, which are often treated as lower-risk even though they can move quickly across cloud resources. For NHI programmes, this is the closest practical control to just-in-time access for synthetic identities.

Practical implication: replace persistent elevation with task-scoped access windows for both users and service identities.

Secrets governance for API keys and dynamic credentials

Secrets governance covers how API keys, tokens, and other credentials are created, monitored, rotated, and revoked. The article notes a core cloud problem: some GCP keys are not programmatically tracked, so teams may not know when they were used or whether they still exist. That creates audit gaps and increases the chance of long-lived credentials becoming reusable attack paths. A stronger model inventories secrets continuously and issues time-limited credentials where possible, reducing the value of compromise. For NHI security, the lesson is that credential lifecycle control is as important as initial authentication.

Practical implication: inventory all cloud secrets, remove orphaned keys, and move high-risk credentials to time-limited issuance.

Threat narrative

Attacker objective: The attacker aims to turn cloud misconfiguration and excessive privilege into durable access and data exposure across GCP resources.

1. Entry occurs through over-permissioned identities, exposed API keys, or misconfigured cloud resources that grant more access than intended.
2. Escalation follows when standing privileges or weak hierarchy design let a compromised identity move across projects, buckets, or workloads.
3. Impact is data exposure, unauthorized resource use, or broader compromise of cloud-held systems and secrets.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

GCP attack surface reduction is fundamentally an identity problem. Cloud platforms can expose resources quickly, but the failure mode usually sits in how access is designed, not in the existence of cloud controls. When permissions accumulate across users, workloads, and automation, the effective blast radius expands faster than teams can review it. Practitioners should treat cloud security as continuous identity governance, not periodic configuration cleanup.

Dynamic permissioning is the right pattern, but only when it reaches synthetic identities. Many teams narrow privilege for people while leaving service accounts, scripts, and automation with long-lived entitlements. That creates a split model where the most active actors are often the least governed. NHI programmes should extend task-scoped access to every identity that can act on cloud resources.

Secrets governance must move from inventory to lifecycle control. Knowing that keys exist is not enough if teams cannot see when they are created, used, or retired. Cloud environments with weak secret observability turn every forgotten key into latent access debt. Security teams should set ownership, expiration, and revocation rules that make stale credentials difficult to keep alive.

Resource hierarchy is a control plane for blast-radius management. The article’s warning about disorganised GCP structures points to a broader governance lesson: when nesting and permission boundaries are unclear, policy reviews become guesswork. A disciplined hierarchy does not eliminate risk, but it makes containment and review possible. Practitioners should align hierarchy design with organisational ownership and incident response needs.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For a deeper control baseline, see OWASP NHI Top 10 for the agentic access risks that overlap with cloud identity governance.

What this signals

Identity blast radius: cloud programmes are now judged by how quickly they can shrink the reach of a compromised identity, not by how many security features the platform exposes. When access is spread across projects, service accounts, and automation, remediation lags behind actual exposure. Teams should align GCP controls to zero standing privilege principles and validate them against NIST Cybersecurity Framework 2.0.

The governance signal for practitioners is clear: cloud security operations need better ownership of synthetic identities, not just better tooling. With 52% of security leaders already seeing AI security decision-making shift toward platform and infrastructure teams, per the 2026 Infrastructure Identity Survey, cloud access reviews will increasingly sit alongside platform engineering workflows rather than separate from them.

If your GCP posture still relies on static credentials and ad hoc project structures, the next control gap will be policy drift, not missing dashboards. Map cloud identities to named owners, wire logs into detection workflows, and compare privilege scopes against the access actually needed for the workload's job.

For practitioners

• Implement unified asset visibility Build a cross-cloud inventory for GCP users, service accounts, buckets, workloads, and keys so teams can spot drift before it becomes exposure.
• Convert standing privileges to task-scoped access Use dynamic permissioning for both people and automation, and require access removal immediately after the task window closes.
• Tighten secrets lifecycle controls Track creation, use, and deletion for API keys, then replace reusable credentials with time-limited issuance wherever the application pattern allows it.
• Review resource hierarchy ownership Document which team owns each project, folder, and policy boundary, then verify that permissions are inherited intentionally rather than by accident.
• Monitor logs for identity drift Feed Admin Activity Logs and Data Access Logs into SIEM or UEBA workflows to detect suspicious access changes and unusual secret use.

Key takeaways

• GCP attack surface is driven as much by identity design as by cloud configuration, so access governance must be treated as a core security control.
• Standing privilege, unmanaged secrets, and unclear resource ownership create the conditions for cloud compromise even when native platform security is enabled.
• The strongest reduction in risk comes from combining least privilege, dynamic access, and continuous visibility across human and synthetic identities.

Key terms

• Shared Responsibility Model: A cloud security model that divides platform security from customer configuration responsibility. The provider secures the underlying service, while the customer governs identity, permissions, data protection, and workload settings. In GCP, the model means exposure often comes from how resources are configured, not from the platform itself.
• Dynamic Permissioning: An access pattern where privileges are granted only for the time needed to complete a task, then removed. It reduces the value of stolen credentials and limits how far a compromised identity can move. In NHI governance, it is a practical way to replace standing access with time-bound control.
• Secrets Governance: The discipline of controlling credentials, tokens, API keys, and certificates across their full lifecycle. It includes inventory, creation, usage tracking, rotation, expiration, and revocation. For cloud environments, strong secrets governance prevents dormant keys from becoming long-lived entry points for attackers.
• Resource Hierarchy: The structure that determines how cloud objects are nested and how permissions are inherited across projects, folders, and policies. A disciplined hierarchy makes ownership clearer and reduces accidental access expansion. In practice, it is a control layer for limiting blast radius and simplifying review.

Deepen your knowledge

GCP identity governance and dynamic permissioning are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are tightening cloud access controls across service accounts and automation, it is worth exploring.

This post draws on content published by Britive Team: Fundamental GCP Security Best Practices to Reduce Your Attack Surface. Read the original.