Google Cloud shared responsibility gaps still create avoidable exposure

At a glance

What this is: This is an analysis of where Google Cloud security responsibility ends and customer control begins, with the key finding that most exposure comes from mis-scoped access, public storage, and unmanaged guest OS risk.

Why it matters: It matters because IAM, cloud security, and NHI teams must treat service accounts, public resources, and patch ownership as customer-controlled risks, not provider-managed defaults.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.

👉 Read Intruder's guide to Google Cloud shared responsibility and exposure risks

Context

Google Cloud’s shared responsibility model is a reminder that cloud security failures often start with ownership confusion rather than platform defects. In practice, the hardest problems sit at the boundary between provider-managed infrastructure and customer-managed identity, configuration, and data exposure, especially in Google Cloud environments where IAM, service accounts, and public storage are easy to mis-scope.

For IAM and NHI programmes, this is not just a cloud posture issue. Service accounts, access policies, and deployment-time permissions act like machine identities with standing reach, so the same governance discipline used for human access reviews, privilege scoping, and offboarding has to extend into cloud operations. The article’s examples are typical of enterprise cloud use, not edge cases.

Key questions

Q: What breaks when service accounts have more privilege than the workload needs?

A: Excessive service-account privilege turns a single compromise into broad cloud access, because the attacker inherits the workload’s permissions instead of having to escalate. In Google Cloud environments, that means a stolen secret, compromised host, or abused pipeline can become immediate administrative control. The fix is not just rotation. It is minimum privilege, scoped roles, and ownership tied to the workload’s lifecycle.

Q: Why do cloud teams still need least privilege if the provider secures the platform?

A: Because platform security does not decide who may read data, administer resources, or expose services. Those are customer choices expressed through IAM, resource policies, and network settings. Least privilege matters because it limits what a legitimate identity can do when credentials are stolen or a workload is misused, which is exactly where many cloud incidents begin.

Q: How do security teams know whether cloud exposure is actually under control?

A: They need evidence that internet-facing assets, IAM permissions, logging, and segmentation are monitored continuously, not only at audit time. If those controls drift between reviews, the programme is reacting too late. Strong control means the environment stays aligned with policy after normal operational change, not just after a checklist review.

Q: Who is accountable when a Google Cloud workload is exposed by misconfiguration?

A: Accountability sits with the organisation that defined the access, published the resource, or failed to patch the guest OS, even when the provider supplied the capability. Cloud providers secure the underlying service boundary, but customers own the configuration choices that create public exposure. That makes governance, not blame shifting, the operational response.

Technical breakdown

Shared responsibility in Google Cloud: where the control boundary really sits

Shared responsibility is not a fixed line drawn by the provider. It changes by service model, because SaaS, PaaS, and IaaS allocate different layers of protection to the customer and the cloud provider. Google can secure the underlying platform, but it cannot know whether a bucket, service account, or VM should be public, privileged, or patched on your behalf. That makes identity and configuration ownership the critical control plane, not the cloud brand name.

Practical implication: Map each Google Cloud service to a named owner for IAM, data exposure, and patching before workloads go live.

Why service accounts become high-risk machine identities

Service accounts are non-human identities, and in cloud environments they often accumulate standing privilege because they are created for convenience rather than lifecycle control. When a service account is over-permissioned, compromise of the host, pipeline, or secret store immediately becomes privilege escalation. The failure is not the existence of the account, but the absence of least privilege, scoped role design, and revocation discipline tied to its actual workload purpose.

Practical implication: Treat every service account as a governed identity with a minimum-access role, expiry review, and revocation path.

Public storage and exposed networks turn configuration into access

Cloud storage and firewall settings can be technically valid while still being operationally unsafe. A public bucket or wide-open firewall does not violate the platform model, because the provider cannot infer whether the workload contains sensitive data or should be internet-reachable. This is why exposure management in cloud depends on policy, classification, and continuous verification, not on assuming the provider will prevent dangerous publication decisions.

Practical implication: Continuously scan for public access paths and internet exposure, then tie remediation to data sensitivity and business intent.

NHI Mgmt Group analysis

Google Cloud shared responsibility is really an identity responsibility problem. The article correctly shows that provider controls stop where customer intent begins, but that boundary is usually enforced through IAM, service account design, and access policy. When those controls are vague, teams inherit a false sense of safety from the platform. The practical conclusion is that cloud governance fails when ownership of machine identities is not explicit.

Service accounts are the cloud equivalent of standing privileged access if they are not lifecycle-governed. The article’s administrator example is a classic failure mode: a workload identity holds more power than the task requires, so compromise becomes immediate privilege abuse. That maps directly to NHI governance, where lifecycle review, privilege scoping, and revocation are the real controls. The conclusion is to treat every service account as a high-risk identity, not a technical afterthought.

Public exposure and firewall sprawl show why configuration and access control must be assessed together. A bucket that is intentionally public and a VM that is unintentionally open can look similar from the outside, but the governance failure is different. The useful concept here is cloud identity exposure drift: the gap between intended access and effective access as permissions, resources, and network paths change. The conclusion is to verify effective exposure continuously, not periodically.

Least privilege remains the only durable way to reduce blast radius in cloud operations. The article’s examples all collapse into the same pattern: when scope is too broad, every compromise has a larger downstream impact. That is true for human IAM, service accounts, and automation alike. The conclusion is that cloud security should be measured by how little access a workload can get away with, not by how much functionality it can preserve.

What this signals

Cloud governance will increasingly be judged by identity observability, not provider feature lists. Teams that cannot inventory service accounts, map public exposure, and prove ownership of guest OS patching will keep discovering that their real risk sits outside the provider’s boundary. The practical shift is to make entitlement records and exposure scans part of the same operating rhythm as workload delivery.

Cloud identity exposure drift is the control problem practitioners should watch most closely. As infrastructure becomes more ephemeral, the gap between intended access and effective access widens unless identity, configuration, and patch evidence are tied together. That is where current cloud programmes fail, and it is where NHI governance methods can add structure without adding operational noise.

The most durable response is to treat cloud resources as governed identities with lifecycle obligations. That means continuous review of service-account access, explicit ownership of public resources, and patch accountability for every guest OS that the provider does not manage.

For practitioners

• Define service-account ownership by workload Assign a named business and technical owner to every Google Cloud service account, with documented purpose, maximum privilege, and revocation criteria for each identity.
• Audit for public storage exposure Scan buckets for anonymous read or write access, then classify any public object store against its data sensitivity and approved use case before leaving it internet reachable.
• Separate guest OS patch ownership from platform ownership Track which teams patch the guest OS and application stack in IaaS, and require evidence of patch status alongside cloud posture review results.
• Review firewall rules as identity-adjacent controls Treat public IPs, open ports, and permissive firewall rules as access decisions, then remove exposures that are not tied to a documented business need.

Key takeaways

• The article shows that Google Cloud security problems usually arise at the customer-managed boundary, not in the provider’s core platform.
• Service accounts, public buckets, and guest OS patching are all identity or configuration decisions that can expand blast radius when left unmanaged.
• Continuous ownership, privilege scoping, and exposure review are the controls that change cloud risk more than any single provider feature.

Key terms

• Shared Responsibility Model: A shared responsibility model divides security duties between the cloud provider and the customer. For NHI governance, the provider supplies the platform controls, but the organisation still owns configuration, privilege review, secret handling, monitoring, and lifecycle management of its identities.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Guest OS: The operating system running inside a virtual machine that the customer controls in an IaaS environment. The cloud provider manages the underlying hardware and host layer, but the customer is responsible for patching and securing the guest OS and its software stack.
• Exposure Drift: Exposure drift is the gap between the state a security team last validated and the state the environment has reached since then. In fast-changing cloud and identity-heavy environments, that gap can be large enough to make a previous pentest result unreliable for operational decisions.

What's in the full article

Intruder's full guide covers the operational detail this post intentionally leaves for the source:

• A service-by-service breakdown of Google Cloud responsibility splits across SaaS, PaaS, IaaS, and on-prem environments
• Specific examples of insecure permissions, exposed storage, and firewall misconfigurations that practitioners can compare against their own estates
• Operational guidance on scanning cloud posture alongside internal and external exposure to reduce attack surface
• Details on where guest OS patching sits in IaaS and how to keep internal systems aligned with vulnerability findings

👉 The full Intruder guide explains the service-by-service ownership split, cloud exposure examples, and patching responsibilities.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners apply lifecycle control to the identities and access patterns that cloud platforms do not manage for them.