Agentic workflow identity assumptions are collapsing in GitHub to GCP flows

At a glance

What this is: This research shows how an attacker-controlled GitHub issue could drive an agentic CI workflow from code execution to cloud privilege escalation through exposed OIDC material and overbroad service account permissions.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern the identity chain around agentic workflows, not just the cloud account or the agent prompt itself.

👉 Read Pillar Security's analysis of the Gemini CLI issue chain and GCP compromise path

Context

Agentic workflows change the identity problem because the system itself can interpret untrusted input and then act on infrastructure with inherited permissions. In this case, the primary issue is not a classic application bug alone, but a governance gap around what the workflow identity, the agent tools, and the surrounding cloud permissions are allowed to touch.

The article shows a path from public GitHub content to CI execution, then to OIDC credentials on disk, then to service account impersonation in GCP. That is an NHI governance problem first, and an agentic workflow problem second, because the attacker only needs one weak link in the identity chain to convert prompt influence into cloud access.

Key questions

Q: How should teams prevent agentic CI workflows from turning issue content into cloud access?

A: Teams should keep untrusted repository content, agent tool execution, and cloud authentication in separate trust zones. If the same workflow can read attacker-controlled input and also reach cloud identities, then the workflow itself becomes an escalation path. Limit command execution, restrict file reads, and ensure cloud access is only available to narrowly scoped runtime identities.

Q: Why do short-lived cloud credentials still fail in agentic workflows?

A: Short-lived credentials still fail when the agent or runner can read them from disk, memory, or logs before they expire. The problem is not token lifetime alone. It is whether the runtime environment allows the credentials to be observed, relayed, or replayed during the job's active window.

Q: What breaks when service account impersonation is granted too broadly?

A: Broad impersonation turns a workflow identity into a bridge account. Once one service account can mint tokens for others across the project, compromise of a low-value workflow can become access to far more sensitive systems. The control that fails is delegation scoping, not authentication itself.

Q: What should security teams review first after an agentic workflow compromise?

A: Start with the workflow identity, the exact tools exposed to the agent, the location of any credential files, and the downstream service account permissions. Then trace whether the workflow can impersonate other identities, because that is where a small exposure becomes a large breach.

Technical breakdown

How a GitHub issue becomes a CI execution path

The first stage is trust transference from untrusted repository input into an automated workflow that can execute commands. Once an agentic step is wired to read or process issue content, the issue body becomes an attack vector rather than mere text. The research shows that when the workflow can be induced to run shell commands, the boundary between application input and infrastructure control collapses. That is why CI jobs with agent assistance must be treated as identity-bearing execution environments, not passive build steps.

Practical implication: isolate agent-driven CI jobs from repository content that can influence execution paths.

OIDC credentials files and workload identity federation

Workload Identity Federation replaces static cloud keys with short-lived tokens, but it still depends on where the OIDC material lives and who can read it. In the reported setup, the credentials file was written to disk on the runner, which means confidentiality now depends on runtime file exposure controls and not only on token expiration. If an agent can read files and echo content back into logs, the supposed keyless model still leaves a recoverable secret path. The control plane is safer only if the runtime surface is equally constrained.

Practical implication: treat OIDC artifacts on runners as sensitive runtime secrets, not harmless setup output.

Why project-wide token creator permissions are the escalation point

The decisive escalation came from granting serviceAccountTokenCreator at project scope rather than limiting it to a single service account. That role lets one service account impersonate others, so a compromised workflow identity can become a bridge into higher-privilege identities across the project. In NHI terms, this is a standing delegation problem, not a one-off misconfiguration. Once a workflow identity can mint or impersonate other service accounts broadly, the blast radius is defined by the permission graph, not the original task scope.

Practical implication: constrain impersonation to the narrowest possible service account boundary and review all delegation paths.

Threat narrative

Attacker objective: The attacker wanted to turn untrusted repository content into privileged access inside the affected GCP project.

1. Entry began with attacker-controlled GitHub issue content reaching an agentic CI workflow that could be influenced into executing commands.
2. Escalation followed when the workflow exposed an OIDC credentials file on the runner and the service account held project-wide token creator permission.
3. Impact was GCP project compromise through service account impersonation and editor-level access, turning content injection into cloud control.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

Agentic workflow security is now an identity governance problem, not just a prompt-safety problem. The article shows that untrusted input only becomes dangerous when it is paired with a workflow identity that can read files, execute commands, and inherit cloud permissions. That means security teams must govern the whole runtime identity chain, from the agent toolset to the cloud delegation model. The practitioner conclusion is that prompt controls alone do not bound the attack surface.

Standing delegation is the failure mode that makes these workflows fragile. The service account chain depended on permissions that outlived the specific task and extended beyond the minimum runtime need. In NHI governance terms, the broken premise is that an automation identity can be safely trusted because it was created for a narrow workflow. The practitioner conclusion is that project-wide impersonation rights are a governance defect, not an implementation detail.

Ephemeral credentials do not eliminate runtime exposure if the agent can still read and relay them. The article demonstrates that short-lived OIDC tokens can be recovered from disk or logs when the surrounding control plane allows read access. This is the point where secrets management, agent tool scope, and CI observability intersect. The practitioner conclusion is that runtime file access is part of identity control, not separate from it.

Agentic AI requires a new concept we can call runtime identity blast radius. The blast radius is not just the permissions attached to the service account, but the combination of tool access, token placement, log exposure, and impersonation scope available during execution. That combination can convert a small workflow mistake into project-wide compromise. The practitioner conclusion is that identity reviews must model the whole execution path, not individual entitlements in isolation.

Agentic workflows expose a blind spot in conventional access review cadences. Reviews can validate who owns the workflow identity, but they often miss what the agent can read, what it can echo, and what downstream identities it can mint in real time. That matters because the attack chain is assembled within a single run, before periodic governance catches up. The practitioner conclusion is that lifecycle controls must move into runtime design.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• The governance answer is to pair runtime visibility with lifecycle control, which is why 52 NHI Breaches Analysis is the right next resource for teams mapping real-world failure patterns.

What this signals

Runtime identity blast radius is the right lens for this class of incident because the useful unit of control is no longer the service account alone. It is the combination of agent tool scope, file exposure, token placement, and impersonation rights inside the execution window. That is why teams should align this topic with the OWASP NHI Top 10 and, where agent behaviour is part of the threat model, the OWASP Agentic AI Top 10.

With 80% of organisations already reporting agent behaviour beyond intended scope, the governance gap is no longer hypothetical. The issue for practitioners is whether their CI and cloud identity model assumes agent compliance, or whether it assumes the agent may eventually read, echo, and relay sensitive material.

The next programme decision is whether workflow identities are being reviewed like ordinary service accounts or treated as high-risk execution identities. Teams that still separate agent oversight from IAM, PAM, and secrets governance will keep missing the place where the attack chain actually forms.

For practitioners

• Constrain workflow identities to single-purpose permissions Remove project-wide impersonation rights and scope serviceAccountTokenCreator to the narrowest service account or task boundary. Review every GitHub Actions or CI identity that can authenticate into cloud projects and map its actual downstream reach.
• Treat runner-local OIDC artifacts as sensitive secrets Prevent OIDC credential files, token material, and setup output from being written to disk or exposed to agent-readable paths. Apply file-level controls and runner hardening so runtime reads cannot become log exfiltration.
• Separate agent tool access from repository input processing Do not let an agent that processes untrusted issues or pull requests also have unrestricted read_file or shell execution paths. If an agent must inspect inputs, keep tool scopes minimal and non-overlapping.
• Add runtime checks for secret relay behavior Monitor for workflows that read sensitive files and then emit chunked or partial output into logs, because that is a common exfiltration pattern when masking is in place. Use detection logic that looks for read-and-echo chains inside CI jobs.

Key takeaways

• Agentic CI workflows can turn attacker-controlled content into cloud privilege escalation when tool scope, file access, and delegation rights line up badly.
• The breach path depended on exposed OIDC material and overly broad service account impersonation, which made the workflow identity itself the escalation bridge.
• Teams should treat runtime identity scope, secret placement, and impersonation boundaries as one control problem, not three separate ones.

Key terms

• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
• Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
• Service Account Impersonation: A pattern where a workload receives permission to act as a cloud service account without possessing the account's long-lived key. It reduces secret exposure but still requires tight scope, clear subject mapping, and strong lifecycle control.
• 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.

What's in the full report

Pillar Security's full research covers the operational detail this post intentionally leaves for the source:

• The exact GitHub issue and workflow chain used to move from untrusted content to CI execution.
• The step-by-step OIDC and service account impersonation path that led into GCP.
• The log masking and output-chunking behaviour used to turn partial token disclosure into a usable credential path.
• The remediation changes made to tool scoping and credential handling in the workflow.

👉 Pillar Security's full research covers the workflow exploit chain, credential exposure, and GCP escalation details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 lifecycle governance in your organisation, it is worth exploring.