TL;DR: TeamPCP and related activity turned trusted automation across CI pipelines, registries, IDEs, and AI coding agents into a credential theft path that spread through 37 mapped incidents, according to Pluto Security research. The core lesson is that supply-chain defence now depends on constraining identity, execution, and egress at build time, not only on package integrity.
At a glance
What this is: This analysis maps how TeamPCP-style supply-chain attacks used trusted automation to steal credentials, pivot between victims, and turn CI and developer tooling into an attack path.
Why it matters: It matters because IAM, PAM, and NHI teams now have to govern build runners, publishing tokens, IDE hooks, and agent configuration as part of the identity perimeter.
Context
The security gap here is not just malicious code in packages, but over-trusted automation that can execute code, reach secrets, and pass access onward without enough friction. In that model, the control failure is identity governance around pipelines, developer tooling, and release workflows, not only software provenance.
TeamPCP showed how a compromised build or developer workflow can become a credential distribution mechanism when runners, plugins, and release jobs inherit broad permissions. That makes CI/CD identity security, secrets containment, and execution control part of the same problem space rather than separate disciplines.
The article focuses on supply-chain compromise, but the deeper issue is how quickly trusted automation can be turned into an identity path. CI/CD pipeline identity security is the cleanest way to frame that failure mode before thinking about specific controls.
Key questions
Q: What breaks when CI runners have broad access to publishing tokens and cloud credentials?
A: Broad runner access turns a build environment into a high-value identity target. If untrusted code executes inside the same boundary as release credentials, attackers can steal secrets, sign artifacts, and move laterally through downstream systems. The control failure is excessive trust in a temporary runtime that behaves like production.
Q: Why do mutable action tags create such a high supply chain risk in CI/CD?
A: Mutable tags let the referenced code change without any workflow file edits, review, or alert to the consumer. That means a trusted reference like @v5 can be redirected to malicious code after publication. In CI/CD, this bypasses the normal change-control process and turns a routine version shortcut into a high-impact attack path.
Q: How should teams treat credential rotation after a build or developer-tool compromise?
A: Rotation has to be treated as incident containment, not a simple password change. Teams should isolate the affected host, revoke old credentials, verify the revocation status through provider APIs, and then rotate every credential the compromised process could reach. Anything less leaves live access behind.
Q: How should security teams govern coding agents that can execute repository instructions?
A: Treat repository instruction files as executable input, not documentation. Review AGENTS.md and similar artefacts before unsupervised execution, scan them for shell commands and credential-path access, and enforce allow or block decisions outside the model. The control objective is to prevent untrusted repository content from becoming trusted pre-task execution.
Technical breakdown
Why CI runners become high-value identity targets
A CI runner is not a throwaway box when it can reach package registries, cloud accounts, source control, SSH keys, and release tooling. In practice, it acts like a privileged execution tier with a short lifetime, which makes it attractive to attackers who want immediate credential access rather than long-term persistence. The key failure is not just code execution, but the fact that untrusted code often runs inside a trust boundary that also contains publish rights, signing rights, and internal secrets. Once that boundary is crossed, the runner becomes a bridge into other systems. Practical implication: separate build, test, and release trust zones so untrusted code cannot inherit release-grade identity.
Practical implication: Separate build, test, and release trust zones so untrusted code cannot inherit release-grade identity.
Why mutable references turn trusted automation into remote code execution
Tags, branch names, and publisher labels are not immutable trust anchors. If a workflow references a moving target such as latest, v1, or an unpinned action reference, then the executed code can change while the reference looks stable to reviewers. That is how supply-chain attackers get their payload into otherwise normal automation. The issue is not just dependency management; it is executable indirection inside privileged environments. Pinning to a commit SHA, digest, or hash forces a reviewable change when code changes. Practical implication: treat every mutable execution reference as a governance defect, not a convenience feature. See the AI Coding Agents Security Guide.
Practical implication: Treat every mutable execution reference as a governance defect, not a convenience feature.
Why identity provenance still needs policy enforcement
A valid attestation only proves that a build happened under a particular identity and workflow. It does not prove that the build was safe, authorised, or produced from the intended branch and context. That distinction matters in supply-chain attacks because compromised publishing identities can generate perfectly valid provenance for malicious artifacts. Provenance therefore answers one question, while policy answers the more important one: whether the build path itself was acceptable. Practical implication: verify the source ref, workflow scope, and release context before accepting attestation as evidence of trust. See the SaaS-to-SaaS and OAuth App Governance Guide.
Practical implication: Verify the source ref, workflow scope, and release context before accepting attestation as evidence of trust.
Threat narrative
Attacker objective: The attacker objective was to harvest trusted identities from development and build environments, then reuse them to compromise more systems and keep the campaign moving.
- Entry occurred through trusted package, workflow, IDE, or agent paths that developers and build systems already allowed to execute.
- Credential access followed when the compromised process reached tokens, keys, histories, and other secrets available in the same execution boundary.
- Escalation came from reusing stolen identities to move into publishing, release, or downstream victim environments.
- Impact landed as lateral compromise across organisations, with stolen credentials enabling the next victim and extending the campaign.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity governance for software delivery is now a runtime control problem, not a release checklist. The article shows that pipelines, registries, IDEs, and AI coding agents were all part of the same trust chain. That means identity scope, execution permissions, and network reach all shape breach exposure before a package is ever published. The practitioner lesson is to govern software delivery as an identity environment with explicit boundaries, not as a neutral automation layer.
Mutable execution references create identity risk because they let trusted names point to untrusted code. A tag, branch, or auto-updating extension does not preserve trust if the underlying object can change after review. That is a governance failure, not just a software hygiene issue. Teams should treat pinned references as a control for identity stability, because the real problem is who or what can speak with the authority of a known name.
Credential containment is the decisive control when supply-chain attacks become identity attacks. The campaign did not need to own every victim permanently; it only needed enough access to move laterally through the next set of trusted credentials. That makes short-lived identities, narrow publish permissions, and restricted runner egress more central than broader detection narratives. The practitioner takeaway is that blast radius, not just detection speed, defines whether the compromise stops or propagates.
AI supply chain governance matters because AI coding agents can execute repository instructions as if they were operational guidance. Once an agent can read workspace files and act on them, malicious instructions can become both prompt injection and code execution. That collapses the old assumption that repository content is passive until a human notices it. The implication is that agent configuration must be governed as executable input, not merely developer preference.
From our research library:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
The next phase of supply-chain defence is likely to move from binary trust decisions toward scoped execution, because a compromised build job can behave like an identity broker. Teams that still separate CI hardening from IAM governance will keep missing the same failure mode in different places.
Credential blast radius: the practical question is no longer whether an attacker can execute code, but how far one stolen build or developer identity can travel before containment. That shift pushes programmes toward shorter-lived permissions, tighter approval boundaries, and stronger separation between development and release authority.
Security teams should expect more scrutiny of IDE plugins, agent instructions, and workflow files as attackers continue to target whatever tooling can reach secrets without human review. The governance model has to follow the execution path, not just the package registry.
For practitioners
- Constrain build and release trust boundaries Separate build, test, and publish workflows so untrusted code never reaches release credentials or signing paths.
- Pin every executable reference Lock actions, container images, package versions, and extension references to immutable hashes, SHAs, or digests.
- Reduce runner network reach Allow package installs and build jobs to reach only the registries and services they genuinely need.
- Treat IDE and agent settings as code Require review for workflow files, IDE configuration, agent instructions, and any auto-run hooks added to repositories.
- Make credential rotation a containment process Isolate the affected host first, verify revocation through provider APIs, and rotate every credential the process could access.
Key takeaways
- TeamPCP-style attacks show that supply-chain compromise is often an identity problem disguised as a software problem.
- The main weakness is not a single vulnerable package, but excessive trust across build jobs, developer tools, and release workflows.
- Containment depends on smaller permissions, immutable references, restricted egress, and rotation that actually revokes live access.
Related NHI Mgmt Group resources: CI/CD Pipeline Identity Security Guide · AI Coding Agents Security Guide · AI Supply Chain Security and AI-BOM Guide · SaaS-to-SaaS and OAuth App Governance Guide
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets exposed through CI runners, developer tools, and compromised workflows. |
| NHI-05 — Overprivileged NHI | Build runners and publishing identities are described as having access far beyond their necessary scope. | |
| NHI-07 — Long-Lived Secrets | The article recommends short-lived identities and rotation because persistent credentials extended the impact. | |
| Recommendation — Reduce secret exposure in CI and developer tooling by removing reusable credentials from build-time execution paths. Apply least-privilege scoping to runners, release jobs, and publishing tokens so compromise cannot spread easily. Replace long-lived tokens with short-lived credentials and verify revocation before treating rotation as complete. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article focuses on credential lifecycle, rotation, and revocation after compromise. |
| Recommendation — Enforce authenticator lifecycle controls that revoke and replace compromised tokens before restoring service. | ||
Key terms
- CI runner: A CI runner is the execution environment that processes build, test, and deployment jobs. In NHI terms, it often holds privileged automation access, temporary credentials, and environment context that can be harvested if a malicious dependency or script executes during the pipeline.
- Mutable reference: A mutable reference is a tag, branch, or alias that can point to different code over time. In GitHub Actions, mutable references increase supply chain risk because the code you trusted yesterday may no longer be the code you execute today.
- Credential containment: Credential containment is the practice of preventing end users from handling the secrets that unlock backend systems. It reduces exposure by keeping passwords, keys, and tokens out of operator workflows, but it only works when revocation and logging are tied to the same control plane.
- Agent Configuration: The settings and instructions that define how an autonomous agent behaves, what tools it can use, and what commands it may run. In security terms, configuration often determines effective authority, so it must be reviewed and controlled like code rather than treated as simple metadata.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org