Executive summary

The TeamPCP campaign, observed in March 2026, involved the compromise of widely used GitHub actions and the injection of malicious code into trusted CI/CD workflows. While the technique itself reflects known supply chain attack patterns, the broader implication is frequently overlooked: the real damage was not code-level corruption. It was identity exposure. Attackers gained execution inside pipelines, exfiltrated machine credentials, and converted those credentials into authenticated access across cloud and production environments. This blog examines what the attack reveals about CI/CD as an identity attack surface, why traditional security responses fall short, and what a more complete approach to identity visibility and control looks like.

Background: What the TeamPCP campaign demonstrated

Public reporting on the TeamPCP campaign describes attackers modifying widely used GitHub actions to execute malicious payloads within the CI/CD workflows of downstream organizations. The affected workflows had legitimate access to cloud credentials, GitHub tokens, SSH keys, Kubernetes secrets, and environment variables, all of which were exposed during pipeline execution. Critically, the attack did not rely on novel exploitation techniques. There were no zero-day vulnerabilities involved. The campaign succeeded because trusted workflows were executing trusted actions with access to high-value credentials, and the identities associated with those credentials were weakly governed. What changed was not the privilege level of the environment. What changed was who controlled it.

Key observation: CI/CD pipelines are identity-driven environments

Modern CI/CD pipelines are not passive build systems. They operate at the intersection of source code, cloud infrastructure, secrets management, and deployment automation. They execute using service accounts, API tokens, OAuth credentials, and IAM roles, all of which are non-human identities (NHIs). These identities act without user interaction, maintain persistent or elevated access, and trigger downstream execution across multiple environments. This creates a structural reality that is often underappreciated: the most privileged access paths in many organizations run through automation systems, not through individual users. And in most environments, those automation identities are less governed, less monitored, and less well understood than the human identities they sit alongside. The TeamPCP campaign is significant not because it compromised a GitHub action, but because that compromise provided authenticated, legitimate access to an identity layer that most organizations cannot see clearly.
‍

Where the attack fits: Exploiting the identity layer

Execution Inside Trusted Workflows 
The malicious action executed within workflows that organizations had explicitly trusted and granted broad access. This gave attackers a foothold not just in a build environment but also inside a context that had authenticated relationships with cloud providers, deployment targets, and secrets management systems. There was no need to break through a perimeter. The pipeline itself provided the access.

Credential Exfiltration as Identity Harvesting 
The payloads targeted cloud credentials, tokens, and keys. These are not merely secrets in the conventional sense. They are non-human identities, credentials that authenticate automation systems, authorize deployments, and maintain access to production infrastructure. Harvesting them does not give an attacker a password to reset. It gives them a working identity to use.

Lateral Movement Through Valid Credentials 
Once harvested, these identities allow attackers to move across systems without triggering the anomalies that typically signal a breach. There is no brute force, no unusual authentication pattern, no failed login. Access is exercised through credentials that were issued legitimately and have not been revoked. The movement looks, to most monitoring systems, like normal automation behavior.

Persistence Through Additional Credential Creation 
Observed behavior in similar campaigns includes the creation of new credentials during the window of access. An attacker who can act as a trusted pipeline identity can issue new tokens, modify service account permissions, or embed persistent access mechanisms. Revoking the original compromised credential after the fact does not undo any of this.
‍

Why traditional security models struggle

The TeamPCP campaign does not fit neatly into traditional security categories, and the standard response playbook reflects this mismatch. Disabling the compromised GitHub action addresses the entry point. It does not address the identities that were exposed while the action was running. Rotating credentials is a necessary step, but without visibility into how many identities were affected and what they had access to, rotation is targeted at known exposure rather than actual exposure. Log audits surface what was recorded, but behavioral monitoring of NHIs is not standard practice in most environments, which means the most relevant evidence may never have been captured. The core problem is that CI/CD security has historically been framed as a code integrity challenge. The focus has been on what runs in the pipeline, not on what identities the pipeline uses and what those identities can reach. Attackers have adapted to this framing. They operate through the identity layer precisely because it is where visibility is weakest.

Reframing the Problem: Identity as the Real Security Boundary 
The key takeaway from TeamPCP is not about the specific technique used to compromise the GitHub action. It is about what that compromise unlocked. Modern CI/CD pipelines deploy production systems, manage infrastructure state, and push code to millions of downstream users. They do all of this through NHIs. Yet in many organizations, the NHI inventory is incomplete, permissions are excessive relative to actual operational need, credential lifetimes are long, and behavioral monitoring is minimal. This creates the same asymmetry observed in supply chain attacks more broadly: the most powerful identities in the environment are the least governed.

When an attacker gains execution inside a pipeline, the relevant question is not what code they ran. It is what identities they could reach, what those identities could access, and whether any of that access was used after the compromise. Most organizations cannot answer those questions quickly. Some cannot answer them at all. Security models that focus on code integrity and infrastructure controls without addressing the identity layer will continue to face this gap. Securing the software supply chain requires treating non-human identities as first-class security assets.

Detection considerations

Defenders should orient visibility toward identity usage and automation behavior rather than focusing solely on pipeline configuration or code content. At the identity level, indicators include token usage from unexpected environments or geographic locations, changes in publishing or commit patterns associated with automation accounts, and cross-system reuse of credentials that were intended to be scoped to a specific workflow or environment.

At the system level, indicators include anomalous API calls from pipeline service accounts, unexpected changes in cloud resource configuration following a deployment, and new credential issuance events that do not correspond to a known provisioning workflow. At the pipeline level, defenders should watch for changes in the actions or dependencies a workflow references, deviations from established execution patterns, and secrets access that falls outside the expected scope of a given job.

Mitigation strategies

1. Establish a Complete NHI Inventory 
Organizations should identify all service accounts, tokens, and automation identities associated with CI/CD infrastructure, map where each identity is used, and document what it can access. Without this baseline, exposure assessment after a compromise is guesswork.

2. Reduce Credential Exposure 
Short-lived, scoped credentials should be the standard for pipeline identities. Tokens should be bound to specific environments or workloads, rotated on a defined schedule, and revoked immediately when a workflow or project is deprecated.

3. Apply Least Privilege to Automation 
Pipeline identities are frequently over-permissioned relative to what they actually need. Publishing, deployment, and infrastructure access should be scoped to the minimum required for each workflow, and build, release, and distribution roles should be clearly separated.

4. Monitor Identity Behavior Continuously 
Access controls determine what an identity is permitted to do. Behavioral monitoring determines what it is actually doing. Deviations from established automation patterns, particularly in high-privilege pipeline identities, should be treated as high-priority signals.

5. Validate Third-Party Actions and Dependencies 
Actions referenced in workflows should be pinned to verified commit hashes rather than mutable tags. Changes to pinned versions should require explicit review, and automated scanning should flag updates to referenced actions or dependencies that have not been through a validation process.

How Unosecur helps organizations stay ahead of identity-driven attacks

The TeamPCP campaign reflects a broader shift in how sophisticated attackers operate. Attacks increasingly target the identity layer used by applications and automation systems, because that layer controls access, triggers execution, and enables propagation without requiring user interaction. In cloud and CI/CD environments, this makes NHIs a critical focus for both attack and defense. Unosecur is built to address this gap directly. It provides visibility, control, and continuous validation of identities across cloud and CI/CD environments, with a specific focus on the non-human identities that power modern automation.

Unosecur enables security teams to build and maintain a unified inventory of human and non-human identities across cloud, SaaS, and CI/CD systems, identify overprivileged accounts and risky access configurations before they are exploited, monitor identity behavior in real time and detect anomalous activity even when valid credentials are in use, quantify blast radius immediately when a compromise is detected, and automate containment by revoking access and quarantining compromised identities without requiring manual intervention at each step. By placing identity at the center of security operations, Unosecur allows organizations to detect misuse earlier, reduce the impact of compromised credentials, and limit the ability of attackers to move through the identity layer undetected.

Key Takeaways 
The TeamPCP campaign succeeded without exploiting a software vulnerability. It worked by abusing trusted identities operating inside trusted automation systems. The real attack surface was not the GitHub action that was modified. It was the NHI layer that action could reach. Non-human identities are central to how CI/CD pipelines operate, and they are among the least governed assets in most cloud environments. Organizations that cannot answer basic questions about what their pipeline identities can access and whether those identities were used after a known exposure are operating with a fundamental blind spot. The supply chain is not just code. It is a system of identities acting on behalf of code. Securing it requires treating those identities with the same rigor applied to any other critical security asset.

Conclusion

TeamPCP is not an isolated campaign. It reflects how modern CI/CD environments operate and how attackers have learned to exploit them. Pipelines are automated, identity-driven, and deeply integrated with production infrastructure. Security models that address code integrity and infrastructure hardening without extending to the identity layer miss the core issue. The entry point in an attack like this is a compromised action. The outcome is determined by identity exposure. Organizations that build identity visibility and control into their security posture before an incident occurs are the ones with the tools to contain it after one does. In modern cloud environments, identity is not one part of the security boundary. It is the security boundary.

‍