TL;DR: Unosecur shows how routine Cloud Functions deployments can trigger Cloud Build under a more powerful default service account, creating indirect privilege escalation and access to sensitive project resources. The case shows that automated deployment identities need the same governance discipline as human and workload accounts.
At a glance
What this is: This analysis explains how a routine Google Cloud Functions deployment can be used to piggyback on Cloud Build service account privilege and reach resources outside the deploying identity's intended scope.
Why it matters: It matters because cloud deployment automation is itself an identity surface, and IAM teams need to govern build-time permissions with the same discipline they apply to human access and workload credentials.
👉 Read Unosecur's analysis of ConfusedFunction and cloud build identity escalation
Context
ConfusedFunction is a cloud identity governance problem, not a software defect. The issue appears when a normal deployment action in Google Cloud triggers a build identity with broader permissions than the user who started the change.
That pattern matters because cloud teams often review the initiating identity and miss the service account that actually executes the build. When build and deployment workflows can reach source code, storage, or registry resources, least privilege at the request level is not enough.
For IAM and NHI programmes, the lesson is straightforward: automated deployment paths must be governed as active identities with scoped access, not as invisible infrastructure.
Key questions
Q: What breaks when a cloud deployment trigger can run under a more privileged service account?
A: The control boundary breaks between the person who initiates the change and the identity that actually executes it. In that situation, a normal deployment can become an indirect privilege escalation path, because the platform introduces broader access during automation. Teams need to treat the triggered service account as a separate principal with its own risk and entitlement review.
Q: Why do routine function deployments create privilege escalation risk in cloud environments?
A: They create risk because deployment workflows often call other services on the user's behalf, and those downstream identities can hold broader permissions than the original developer account. If that executor identity is over-scoped, an ordinary update can expose storage, source code, or registry resources that were never intended for the initiating user.
Q: What are the signs that deployment automation has become overprivileged?
A: Look for build identities that can reach more resources than the deployment truly requires, especially when those rights are broader than the permissions held by the initiating user. Repeated build executions, IAM changes after deployments, and access to sensitive resources during normal packaging steps are all signals that the automation boundary is too loose.
Q: Should teams separate human deployer access from build executor access?
A: Yes. The deployer should be able to request a change without automatically inheriting the permissions of the build identity that executes it. That separation limits blast radius, preserves accountability, and prevents a legitimate automation path from becoming a privilege escalation channel. It also makes access review more meaningful because the executor's rights are explicitly governed.
Technical breakdown
How Cloud Functions deployment can shift identity boundaries
In this pattern, the user does not directly acquire elevated rights. Instead, the platform starts a Cloud Build job when a function is created or updated, and that job runs under the default Cloud Build service account. The important mechanism is the identity handoff: the initiating user and the executing build identity are not the same principal, and their permissions are not automatically aligned. That creates a hidden privilege bridge in the deployment pipeline. If the service account is broader than the deployer, the build process can reach resources that the original identity could not.
Practical implication: Treat deployment triggers as identity transitions and review the permissions of the build principal, not only the user who opened the change.
Why indirect privilege escalation is harder to detect than direct abuse
Direct privilege escalation usually looks like a user trying to grant itself access. ConfusedFunction is different because the platform itself introduces the higher-privilege identity during normal automation. That makes the activity look legitimate in Cloud Build, IAM, and Cloud Functions logs unless those events are correlated. Security teams that monitor each service in isolation will often miss the chain. The risk is not merely that the build account is privileged, but that the privilege is exercised inside expected automation and therefore blends into ordinary change traffic.
Practical implication: Correlate deployment, build, and IAM telemetry so a legitimate automation path cannot hide a privilege jump.
Which cloud resources become reachable through build identity abuse
Once the build service account is over-privileged, the exposure can extend beyond the function itself. The article describes access to Cloud Build resources, storage buckets, function source code, artifact and container registries, and other sensitive project resources. That breadth matters because build identities often sit close to code, artifacts, and data paths at the same time. The attack value comes from that adjacency: a single deployment workflow can become a stepping stone into multiple resource classes if the service account was granted broad project-level rights.
Practical implication: Scope build service accounts to the smallest resource set required for packaging, publishing, and deployment.
Threat narrative
Attacker objective: The attacker wants to use a normal deployment action to inherit broader cloud access and reach sensitive project assets without directly escalating their own account.
- Entry begins when an attacker gains permission to create or update a Cloud Function, which is a common developer-level capability in GCP environments.
- Credential access occurs indirectly when the deployment automatically triggers Cloud Build under the default service account rather than the attacker's own identity.
- Escalation follows because that build identity can interact with broader cloud resources, letting the attacker reach storage, source code, and registry assets outside the original scope.
- Impact is the exposure or modification of sensitive project resources through a trusted deployment workflow that appears legitimate in isolation.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
ConfusedFunction exposes a deployment identity gap, not a cloud bug. The security failure sits in the assumption that the identity initiating a change is the identity exercising the resulting access. Cloud automation breaks that assumption when Cloud Build runs under a different service account with broader rights. The practitioner consequence is that build-time identity and deploy-time identity must be governed as separate principals, not collapsed into one access review.
Build automation is now part of the privilege model. Teams that treat build pipelines as operational plumbing are missing where effective access is actually exercised. Once a function deployment can trigger a more powerful service account, the build workflow becomes an access path in its own right. That means cloud governance has to cover service account scope, workflow-triggered permissions, and the resource adjacency created by packaging and deployment jobs.
Identity blast radius is the right concept for this class of exposure. The risk is not just that a service account exists, but that its permissions determine how far a routine deployment can move if the initiating user is compromised or misused. In practice, the blast radius is created by the intersection of developer permissions, default build identities, and project-wide access. Practitioners should evaluate cloud deployment chains as a single governance surface.
Least privilege must be enforced at the automation boundary, not only at the human boundary. A human access review can be clean while the automated build identity remains over-scoped. That leaves a gap between who may request a deployment and what the platform can do on their behalf. The lesson for IAM and NHI programmes is that lifecycle governance has to include deployment-triggered service accounts as first-class identities.
ConfusedFunction is a repeatable cloud control pattern, not an isolated case. The article's broader point is that interconnected cloud services create hidden privilege paths whenever one identity can invoke another with stronger rights. That pattern will keep reappearing wherever platform-managed service accounts sit downstream of ordinary user actions. The control problem is visibility into delegated access chains, because that is where effective privilege accumulates.
From our research library:
- 83% of privilege escalation incidents involved no CVE exploitation, according to Verizon's 2026 Data Breach Investigations Report.
What this signals
Cloud deployment automation is now part of the identity perimeter, because the effective access path can belong to the service account that runs the build rather than the human who requested it. That shifts governance attention from request authorization to executor identity scope, which is where indirect escalation is actually created.
Identity blast radius: when a platform introduces a stronger service account during an otherwise routine workflow, the practical risk is not just exposure of one secret or one bucket. The real issue is that one deployment action can open access to code, artefacts, and data in the same trust boundary, so build identities need lifecycle governance, entitlement review, and logging equal to any other high-risk account.
For practitioners
- Review deployment-triggered service accounts Map which service accounts are activated by Cloud Functions deployment and update workflows, then compare their effective permissions with the permissions held by the initiating developers.
- Reduce default Cloud Build scope Replace broad project-level permissions with custom roles that only cover the build, package, and publish actions required for each pipeline.
- Correlate build and IAM logs Monitor Cloud Build executions alongside IAM policy changes and Cloud Functions updates so indirect escalation is visible in one investigation path.
- Separate deployer rights from executor rights Ensure the identity allowed to trigger a function change cannot automatically inherit the broader access of the build identity used to execute that change.
Key takeaways
- ConfusedFunction shows that cloud privilege escalation can occur through ordinary deployment automation rather than through obvious account takeover or CVE exploitation.
- The exposure is driven by build-time identity scope, and the article describes reach into source code, storage, and registry resources when the default service account is too broad.
- The most effective control is to govern deployment-triggered service accounts as first-class identities, with least privilege and correlated logging across build and IAM activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centers on a default build service account with more privilege than the deployment needs. |
| NHI-04 — Insecure Authentication | The executor identity is introduced automatically during deployment, creating an unsafe trust boundary. | |
| Recommendation — Audit build and deployment identities for overprivileged access and replace broad roles with scoped custom permissions. Review how deployment workflows authenticate downstream service accounts and remove implicit trust between principals. | ||
| MITRE ATT&CK | TA0004;TA0008 — Privilege Escalation; Lateral Movement | The article describes privilege gain through a trusted workflow and movement into broader cloud resources. |
| Recommendation — Map deployment-triggered access to escalation and movement tactics, then hunt for unusual build paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Service account credential and entitlement scope determine whether the build identity can be abused. |
| Recommendation — Apply authenticator and credential lifecycle controls to the service accounts used in deployment automation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is excessive permissions granted to the automation identity. |
| Recommendation — Limit entitlements for deployment identities and continuously review whether access matches the workflow. | ||
Key terms
- Cloud Build Service Account: A Cloud Build service account is the identity a build system uses to perform actions during automated CI/CD execution. If that account has broad permissions, any attacker who can trigger builds may inherit those privileges within the build context and use them against connected cloud resources.
- Deployment-triggered Identity: A non-human identity that is activated automatically when a deployment or update begins. It is governed differently from the person who initiated the action because its effective access is determined by the platform workflow, not by the requestor's own permissions.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of how Cloud Functions deployment invokes Cloud Build under the default service account
- Specific monitoring points for Cloud Build, IAM, and Cloud Functions events that help surface indirect escalation
- Guidance on tightening service account permissions for build and deployment workflows in GCP
- The article's full remediation sequence for replacing broad roles with scoped custom access
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.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org