TeamPCP shows why long-lived credentials are still the real risk

At a glance

What this is: This is an analysis of the TeamPCP campaign and GitHub’s reported investigation, showing that poisoned trusted tools are still exposing long-lived credentials inside developer and CI environments.

Why it matters: IAM teams should treat this as a governance problem across NHI and developer access, because standing credentials, weak runtime visibility, and incomplete rotation all widen blast radius when trusted tooling is compromised.

By the numbers:

• The attacker claims approximately 3,800 repositories were accessed.

👉 Read Hush Security's analysis of the TeamPCP supply chain attack on GitHub

Context

Long-lived credentials inside trusted execution environments are the governance failure at the center of this story. When a developer workstation, CI runner, or build tool can reach secrets without tighter runtime boundaries, a poisoned extension or compromised binary can turn that trust into internal access.

The article frames this as a repeatable supply chain pattern, not a one-off compromise. That matters to NHI governance because the controls involved are the same ones teams use for service accounts, pipeline tokens, publishing credentials, and other non-human identities that are assumed to be safe simply because they live in a trusted environment.

Key questions

Q: How should security teams reduce secret exposure in CI and developer workflows?

A: They should eliminate long-lived credentials wherever possible, replace them with short-lived or task-scoped access, and make sure secrets are never left on disk or in reusable environment variables. Stronger runtime visibility matters too, because a workflow is only as safe as the credentials it can discover while it is running.

Q: Why do trusted tools and extensions create such high credential risk?

A: Because trust in the tool does not limit what the tool can read once it is running in a privileged environment. If a malicious payload inherits access to files, memory, or configuration that contains secrets, the attacker bypasses normal authentication and steals the credential directly from the operating context.

Q: What breaks when credential rotation is incomplete?

A: The old secret may still exist in overlooked systems, dependent tokens may keep working, and the attacker may already have copied what they need before rotation finished. In practice, incomplete rotation gives a false sense of closure while leaving reachable access paths alive.

Q: Who should be accountable for secrets hidden inside build and release pipelines?

A: Ownership should sit with the teams that operate the workflow and the identity controls that authorize it, not with the security team alone. If a pipeline can reach production systems, package registries, or internal repositories, its credential posture belongs in governance reviews, access recertification, and incident response planning.

Technical breakdown

How trusted extensions become secret-harvesting paths

The mechanism here is not novel malware so much as opportunity. A poisoned extension runs in the same environment as legitimate developer tooling and can read files, process memory, and local configuration that often contain API keys, tokens, and registry credentials. In CI and developer workflows, those secrets are commonly long lived and broadly scoped, so the payload does not need to defeat strong authentication. It only needs to inherit the environment’s trust and wait for credentials to be present.

Practical implication: Treat developer tooling as a secret access surface, not just an execution surface.

Why rotation alone does not stop this supply chain pattern

Credential rotation reduces exposure time, but it does not address the root issue when tokens are still discoverable during runtime. If a build runner or workstation keeps secrets on disk, in environment variables, or in memory, a malicious payload can still extract them before the next rotation cycle. The article also shows why incomplete rotation is dangerous: rotating some credentials after an incident does not remove the underlying dependency on standing access.

Practical implication: Measure whether secrets are discoverable at runtime, not only whether they are rotated on a schedule.

Why ephemeral access changes the attack economics

The article’s architectural contrast is between standing credentials and on-demand credentials. In an ephemeral model, access is minted only when the workload actively needs it and expires quickly after use, which narrows the attacker’s window to weaponise a harvested token. That does not eliminate compromise, but it changes the economics of reuse, lateral movement, and propagation because there is less durable material to steal from runners, memory, or local config.

Practical implication: Shift pipeline and workload access toward short-lived credentials tied to verified identity and task scope.

Threat narrative

Attacker objective: The objective is to extract trusted credentials and use them to expand access across internal repositories, package ecosystems, and connected infrastructure.

1. Entry begins when a poisoned trusted extension runs inside an employee device or pipeline environment that already has access to development and cloud credentials.
2. Escalation occurs as the payload harvests long-lived secrets from files, process memory, and local tooling, then uses publishing tokens to move into downstream package ecosystems.
3. Impact follows when stolen credentials enable internal repository exposure, broader infrastructure access, and repeat propagation through additional poisoned releases.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Standing credential trust debt is the real failure mode here. The article is not mainly about a poisoned extension, it is about the amount of access that extension could inherit from the environment. Long-lived secrets in trusted developer and CI contexts create a hidden debt that attackers can cash out the moment execution is compromised. Practitioners should read this as a governance problem, not a tooling anomaly.

The assumption that trusted tools only expose safe credentials is already broken. That assumption was designed for environments where the tool itself was not the primary adversary surface. It fails when malicious code can run inside the same execution context and harvest tokens, memory-resident secrets, and publishing credentials before defenders can intervene. The implication is that access governance has to stop treating trust in tooling as a proxy for trust in credentials.

Identity blast radius, not just credential age, is the governing metric. A short-lived token is still dangerous if it can reach registries, cloud APIs, or internal repositories with broad scope. The article shows that the issue is how far a credential can reach from the moment it exists, not only how long it lives. Practitioners should use this as a lens for revisiting scope, reach, and runtime discoverability together.

Runtime visibility must exist for non-human identities as well as developer workstations. The campaign crosses the boundary between human-operated tools and machine-used secrets, which is exactly where conventional reviews become blind. If teams cannot see which workloads, agents, or tools are reading which credentials in real time, they will miss the moment trust turns into exfiltration. NHI governance has to include behavior, not just inventory.

Teams are still governing for the previous computing era. Static secrets, broad runner trust, and incomplete rotation all assume access can be managed after the fact. That model breaks when trusted code can consume secrets immediately and repeatedly. The implication for identity governance is that storage, scope, and observability must be rethought as one control plane rather than three separate chores.

From our research:

• The group is believed to have exfiltrated data from more than 500,000 infected machines and harvested over 300 GB of credentials and secrets, 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.
• For a deeper view of how real breaches expose the same credential and trust failures, see 52 NHI Breaches Analysis.

What this signals

Standing credential exposure is now a cross-programme issue. The same pattern that affects developer tools also affects service accounts, workflow runners, and autonomous systems that inherit access from their environment. Teams that still manage these identities separately will keep missing the shared control weakness, which is discovered trust in runtime contexts rather than malicious authentication failures.

With 98% of companies planning to deploy even more AI agents within the next 12 months, per AI Agents: The New Attack Surface report, the forward risk is not just more identities but more runtime paths where secrets can be discovered and misused. That makes identity governance a design problem, not an after-incident cleanup exercise.

For practitioners

• Inventory every standing developer and pipeline credential Map GitHub PATs, npm tokens, PyPI tokens, cloud keys, and internal publishing credentials to a named owner, a purpose, and a known expiry.
• Replace reusable secrets with short-lived access Move build and deployment flows toward OIDC or other task-scoped issuance so a compromised runner has less durable material to steal.
• Pin and validate trusted supply chain components Use commit SHA pinning for third-party actions, verify package provenance where possible, and review any workflow that consumes external extensions or release tags.
• Add runtime visibility to NHI and developer environments Track which workloads, tools, and scripts read credentials, where those credentials live, and whether secrets appear in memory, files, or logs during execution.
• Test rotation completeness after every incident Verify that every exposed secret was actually replaced, every dependent token was reissued, and every downstream system stopped trusting the old credential.

Key takeaways

• Trusted tools are not inherently safe when they can read long-lived credentials from the same environment they operate in.
• The scale of the campaign shows that secret harvesting is already a repeatable pattern, not a theoretical supply chain concern.
• Practitioners should treat runtime secret discoverability, access scope, and credential lifespan as one governance problem.

Key terms

• Standing Credential: A standing credential is any secret that remains usable until it is manually rotated or revoked. In NHI governance, it creates durable access that can be stolen, replayed, or propagated from trusted tooling unless runtime boundaries and expiry are built in.
• Secret Harvesting: Secret harvesting is the extraction of credentials, tokens, or keys from an execution environment rather than from an authentication flow. It often targets files, memory, environment variables, and local configuration, which makes trusted developer and CI contexts high-value targets.
• Identity Blast Radius: Identity blast radius is the amount of infrastructure, data, or downstream tooling reachable from a single credential or identity. For non-human identities, it is shaped by scope, token lifetime, and where the credential can be discovered during runtime.
• Runtime Secret Visibility: Runtime secret visibility is the ability to observe when and where secrets are accessed while systems are actively running. It matters because static inventories alone do not show whether a tool, workflow, or workload is reading credentials in memory, files, or logs.

Deepen your knowledge

Long-lived credential reduction, runtime visibility, and pipeline identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are dealing with trusted tools that can reach production or publishing systems, it is worth exploring.

This post draws on content published by Hush Security covering the TeamPCP supply chain attack and GitHub investigation. Read the original.