ConfusedFunction exposes privilege escalation through cloud build identity

At a glance

What this is: ConfusedFunction is a Google Cloud privilege escalation pattern where Cloud Functions deployment activity can elevate access through the default Cloud Build service account.

Why it matters: It matters because IAM teams often review the deploying user but miss the inherited power of automation identities that can reach storage, code, registries, and other project assets.

👉 Read Unosecur's analysis of ConfusedFunction and GCP privilege escalation

Context

ConfusedFunction is a cloud identity problem, not a software bug. The attack path starts when a routine Cloud Functions deployment triggers Cloud Build under a service account that may hold broader permissions than the person or pipeline that initiated the change, which is exactly the kind of inherited access IAM programmes often fail to model.

For practitioners, the governance question is simple: who is actually acting during deployment, and what can that identity reach? In Google Cloud environments, the answer can extend from a developer permission into build-time access to source code, storage, artifact registries, and other project resources.

That makes this a classic non-human identity oversight. A deployment workflow looks ordinary, yet the effective identity on the path is the build service account, not the human requester, and that distinction is where privilege escalation emerges.

Key questions

Q: How should teams reduce privilege escalation risk in Cloud Functions deployments?

A: Teams should treat the deployment workflow as an access boundary, not just the user who clicked deploy. Review the service account that Cloud Build or similar automation will use, remove inherited project-wide roles, and assign only the permissions required for packaging, publishing, and the specific resources the build must touch.

Q: Why do cloud build identities create hidden security risk?

A: Cloud build identities create hidden risk because they often execute with broader permissions than the initiating developer or pipeline. That means a low-risk permission, such as updating a function, can activate a much stronger identity that reaches storage, registries, or code assets the requester should not inherit.

Q: What breaks when service accounts are not reviewed in deployment pipelines?

A: What breaks is the assumption that access reviews capture the identity doing the work. If the platform introduces a build account with unscoped rights, the organisation may approve a harmless deployer while missing the privileged executor behind it.

Q: Which frameworks apply to cloud automation identity governance?

A: NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 are directly relevant because they both emphasise access control, logging, and identity governance. For cloud environments, use them to map which automation identities exist, what they can reach, and how their actions are monitored.

Technical breakdown

How Cloud Functions deployments inherit Cloud Build privilege

When a Cloud Function is created or updated, Google Cloud can automatically start a Cloud Build job to package and deploy the function. That job runs under the default Cloud Build service account, not under the original human or pipeline identity. If that service account has broad project roles, the deployment path becomes an indirect privilege conduit. The security flaw is in the trust boundary between the function update permission and the build identity that the platform introduces on behalf of the requester.

Practical implication: review which service account executes builds and remove any permissions it does not strictly need.

Why indirect privilege escalation evades normal IAM review

Traditional access review often evaluates the initiating user or the explicit role assignment on the application resource. ConfusedFunction exploits a different layer: the platform's own automation identity. Because the build looks legitimate, and because the service account is expected to exist, the escalation is easy to miss in point-in-time reviews. This is a non-human identity problem where privilege is exercised through an approved workflow, not by an obviously malicious login.

Practical implication: include build-triggered identities and their downstream reach in access reviews, not just the developer account.

Where build activity turns into resource exposure

Once the build identity is activated, it can touch project assets that the original deployer should not automatically inherit. In the article's example, that includes Cloud Build resources, storage buckets, function source code, artifact and container registries, and related project services. The risky pattern is cross-service reach created by automation context, not by a direct credential compromise. Monitoring has to correlate Cloud Functions, Cloud Build, and IAM events together or the escalation remains invisible.

Practical implication: centralise logging across deployment, build, and IAM events so cross-service access changes can be detected as a single sequence.

Threat narrative

Attacker objective: The attacker aims to convert a routine deployment permission into broader project access without directly asking for elevated rights.

1. Entry begins with permission to create or update a Cloud Function, which is a common developer-level capability in Google Cloud.
2. Escalation occurs when the deployment triggers Cloud Build, which executes under the default Cloud Build service account and inherits its broader project access.
3. Impact follows when the attacker uses that build-time identity to reach sensitive resources such as source code, storage, and registry data outside the original permission scope.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

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

NHI Mgmt Group analysis

Cloud build identities have become first-class privilege holders, not background infrastructure. ConfusedFunction shows that a deployment workflow can activate an identity with a much larger effective blast radius than the initiating user. The governance mistake is treating build automation as operational plumbing instead of an access-bearing identity subject to the same review, scoping, and monitoring expectations as any other privileged account. Practitioners should stop asking only who can deploy and start asking what identity the platform will silently introduce when deployment begins.

Indirect privilege escalation is now a normal cloud governance failure mode. The article is right to frame this as a tension between routine engineering practice and hidden access paths. That tension matters because cloud platforms increasingly chain services together in ways IAM programmes do not explicitly model. NHI governance has to account for delegated execution paths where permission is exercised through platform mediation, not through the original actor's own role assignment.

ConfusedFunction exposes a reusable concept: deployment-path privilege inheritance. This is the access debt created when an approved workflow activates a service account whose permissions were never re-evaluated in context. The concept is useful because it describes the problem precisely, without collapsing it into generic over-privilege. The practitioner takeaway is that every automated deployment path should be treated as a distinct identity boundary.

Least privilege fails when teams scope the requester but ignore the executor. A developer may have only function-update rights, yet the platform can still execute with a build identity that can reach far more than the developer ever should. That mismatch is the structural issue: the effective identity is not the one the access review captured. Practitioners need to align governance with the identity that actually performs the work.

NIST CSF, OWASP NHI Top 10, and cloud IAM controls all point to the same gap. The article illustrates a combined governance problem across identify, protect, and detect functions: broad service-account permissions, weak cross-service visibility, and limited review of automation identities. The field should treat deployment automation as governed access, not as a bypass from the normal identity model.

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.
• That gap is why readers should also review OWASP NHI Top 10 for the control patterns that fail when identity becomes autonomous.

What this signals

Deployment automation is becoming an identity governance blind spot. As cloud services chain together more tightly, the organisation that only reviews human permissions will miss the executor identity that actually touches data. The practical signal is simple: if you cannot explain which service account runs each deployment path, your programme is already behind the risk curve.

Deployment-path privilege inheritance is the control gap practitioners need to name. Once that concept is explicit, teams can measure it in reviews, logs, and access designs rather than treating it as an abstract cloud concern. The next step for most organisations is to map those identities against the governance model used for other non-human credentials, especially in environments with Google Cloud and other automated build systems.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey, the wider lesson is that inherited access will keep outpacing review cycles unless teams redesign the way automation identities are governed.

For practitioners

• Scope the build identity separately from the deployer Inventory every service account involved in Cloud Functions deployment and compare its permissions with the permissions of the user or pipeline that triggers it. Remove roles that are not required for packaging, publishing, or post-build access.
• Review cross-service access reachable from Cloud Build Map what the default Cloud Build service account can reach in storage, registries, source repositories, and project-level APIs. Treat any access beyond the build's actual task as excess privilege and reduce it with a custom role.
• Correlate deployment, build, and IAM events Alert on unexpected function updates followed by unusual build execution, then check whether IAM policy changes or sensitive resource access followed the same sequence. The correlation matters more than any single log line.
• Replace inherited access with task-scoped service accounts Assign per-trigger or per-pipeline identities where possible so one build path cannot inherit another's permissions. The objective is to keep automation access narrow enough that a deployment cannot become a privilege bridge.

Key takeaways

• ConfusedFunction shows that a routine cloud deployment can turn into privilege escalation when the build identity is broader than the deployer.
• The article highlights a familiar but under-governed pattern: automation identities often inherit access that no human reviewer explicitly approved.
• Teams should model deployment paths as separate identity boundaries and reduce the permissions of every service account involved.

Key terms

• Deployment-path privilege inheritance: A deployment-path privilege inheritance happens when an approved automation workflow activates a service account with broader access than the initiating user expected. The risk is not the deploy action itself but the hidden executor identity that inherits permissions across systems and can reach resources outside the original request scope.
• Automation identity: An automation identity is a non-human account used by a build, pipeline, or deployment system to authenticate and act on resources. In cloud environments, it often has enough power to modify, read, or publish assets, which makes its scoping and monitoring a governance task rather than an infrastructure detail.
• Effective identity: An effective identity is the account that actually performs the sensitive action, even when another user or system initiated the workflow. It matters because access reviews often capture the requester, while the build or runtime account holds the permissions that determine what can really be touched.
• Cross-service access: Cross-service access is the ability of one cloud identity to move between related services, such as build, storage, and registry systems, using the trust created by platform integration. When that access exceeds the task's needs, it becomes a hidden escalation path rather than a useful automation feature.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• A step-by-step explanation of how Cloud Functions deployment triggers Cloud Build in Google Cloud.
• The specific resource classes exposed through the default Cloud Build service account, including buckets, source code, and registries.
• Concrete monitoring signals for unusual build activity and access changes following function updates.
• Practical remediation guidance for re-scoping service accounts and deployment workflows.

👉 Unosecur's full post covers the Cloud Build attack path, exposed resources, and remediation steps

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.