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

At a glance

What this is: This analysis says the TeamPCP pattern shows how trusted tools become breach multipliers when they can reach standing credentials in developer and build environments.

Why it matters: IAM, PAM, and NHI teams need to treat trusted execution environments as credential hunting grounds, because the control failure is the persistence of reusable secrets rather than the initial compromise alone.

By the numbers:

• GitHub said the attacker’s claim of approximately 3,800 repositories was directionally consistent with findings so far.
• The first wave hit Aqua Security’s Trivy on March 19, 2026.

Context

TeamPCP is a supply chain style campaign pattern in which a trusted development tool or package is turned into a credential-harvesting path. In this case, Hush Security says GitHub is investigating unauthorized access after a poisoned VS Code extension reportedly gave an attacker a way into internal repositories and organization data.

For identity teams, the important problem is not just malicious code execution. The security gap is that long-lived credentials remain available in environments where trusted tools, CI runners, and developer devices can read them, reuse them, and move laterally before anyone notices.

Key questions

Q: What breaks when trusted tools can read long-lived credentials on developer machines or CI runners?

A: The boundary between software execution and identity exposure breaks down. A malicious extension or package no longer needs to defeat authentication directly if it can inspect files, memory, and environment variables where reusable secrets already live. That turns routine tool trust into credential harvesting, lateral access, and downstream supply chain propagation.

Q: Why do reusable credentials increase supply chain risk in build systems?

A: Reusable credentials remain valid long enough to be copied, cached, logged, or exfiltrated. That gives attackers a window to act after the original workflow has finished. In build systems, that window is especially dangerous because the same host frequently holds cloud, registry, and signing credentials together.

Q: How do security teams know whether secret rotation is actually working?

A: Rotation is working only if exposed credentials are found quickly, revoked everywhere they are used and replaced before attackers can reuse them. If a secret remains valid after exposure, or if owners cannot prove where it was deployed, rotation is only reducing exposure on paper. The signal to watch is not the rotation schedule, but the time from leak to invalidation.

Q: Should organisations use short-lived tokens instead of standing credentials in CI/CD?

A: Yes, when the workflow involves external packages, extensions, or untrusted code execution. Short-lived tokens limit the value of a successful scrape and reduce the chance that one compromised runner can seed additional compromise. The key is to pair that move with tighter scope and separate publisher privileges.

Technical breakdown

Why trusted tools become credential collection points

Trusted tools running on developer devices or in CI systems often inherit broad local access, environmental variables, cached tokens, and filesystem secrets. Once malicious code executes inside that trust boundary, it can enumerate .env files, cloud access keys, registry tokens, SSH material, and process memory without needing to break encryption or guess passwords. That is why supply chain compromise so often becomes identity compromise. The attacker is not only abusing the tool chain, but also the credential sprawl sitting beside it. In practice, the tool is the delivery mechanism and the credential estate is the prize.

Practical implication: reduce what trusted tools can see by removing standing secrets from runner and workstation contexts.

How poisoned packages turn one compromise into many

A poisoned release tag or extension update matters because downstream automation tends to trust routine updates. Build systems pull the compromised artefact, execute it, and then expose the next layer of secrets needed for publication, deployment, or registry access. In the TeamPCP pattern, harvested publishing tokens are especially dangerous because they let one compromise seed the next wave. That is what makes these campaigns self-propagating. The attack path is not just initial access, but credential reuse across environments that were never meant to be directly reachable from one another.

Practical implication: treat package signing, commit pinning, and token scope separation as identity controls, not just software integrity controls.

Why static credentials fail inside trusted runtimes

Static credentials assume the runtime can safely hold a reusable secret until a human or system rotates it. That assumption breaks in developer ecosystems where binaries, scripts, and extensions can inspect memory, disk, and environment state at execution time. Hush Security’s description of the pattern shows why rotation alone is not a complete answer when the same secret can be copied before the next rotation cycle. The technical issue is not that the credential is weak, but that it is persistently available in a place the attacker can already reach.

Practical implication: shift high-risk workloads toward short-lived issuance and task-scoped access instead of relying on periodic rotation.

Threat narrative

Attacker objective: The objective is to steal reusable credentials from trusted developer environments and use them to expand access into repositories, packages, and internal infrastructure.

1. Entry via a poisoned VS Code extension compromised an employee device and placed attacker code inside a trusted execution environment.
2. Credential access followed as the payload searched the runner or workstation for long-lived secrets such as cloud keys, publishing tokens, and configuration files.
3. Lateral movement and propagation then became possible when stolen tokens were reused to poison additional packages and extend the campaign into downstream environments.
4. Impact was internal repository exposure and broader trusted-tool compromise, with the attacker claim reportedly directionally consistent with GitHub’s findings so far.

Breaches seen in the wild

• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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

NHI Mgmt Group analysis

Long-lived credential exposure inside trusted execution environments is the core failure mode here: The attack did not need to defeat the developer tool model, only to inherit its trust. That means the real governance gap is not package trust alone but the decision to leave reusable credentials inside environments that execute unvetted updates. The practical conclusion is that trusted runtime access and standing secret presence cannot be governed as separate problems.

Secret rotation is not a complete control when the secret is already available at runtime: Once a malicious extension or package can read memory, disk, or environment variables, the credential has already crossed the control boundary. This is why campaigns like TeamPCP turn every trusted tool into a secret scavenger hunt. The implication for practitioners is that lifecycle control has to move upstream to issuance and runtime exposure reduction, not just post-exposure cleanup.

Credential propagation is what turns one compromised tool into a supply chain event: The campaign becomes more than single-system malware when harvested publishing tokens, CI tokens, and cloud keys can seed the next wave. That is a governance problem across human-owned developer access, NHI entitlements, and build-system trust. The field should read this as a failure of identity containment, not merely a software defect.

Static credentials are the wrong primitive for modern trusted-tool ecosystems: The article’s core claim is that the thing being harvested is the product of the architecture itself. Long-lived secrets make every trusted environment a latent exfiltration point. Practitioners should treat this as evidence that the oldest assumption in secret governance, that a reusable credential can safely sit near execution, no longer holds.

Identity blast radius now extends through the software delivery path: A single compromised extension or package can expose enough access to affect repositories, registries, and internal tooling in sequence. That changes how we should think about privileged access governance in CI/CD and developer environments. The decisive question is no longer who signed the code, but what identity material the code can reach once it runs.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Credential reuse is the structural weakness: Trusted tools do not become dangerous because they are popular. They become dangerous when they are allowed to sit beside reusable secrets that can be harvested before any governance process notices. That is why identity teams should treat build and developer environments as credential-exposure zones, not just execution zones.

Long-lived secret control has to move from rotation to absence: A compromise path that can read memory, environment variables, and local files will outpace periodic rotation every time. The governance question is no longer whether a token will eventually be revoked, but whether it should exist in that runtime at all. That shift matters across IAM, PAM, and NHI programmes.

Secret sprawl in trusted environments is the issue the campaign exposes. Internal repositories are 6x more likely to contain secrets than public ones, according to the State of Secrets Sprawl 2026, and that kind of hidden exposure is exactly what attacker tooling exploits first.

For practitioners

• Audit standing developer and CI credentials Inventory GitHub PATs, npm tokens, PyPI tokens, cloud keys, and registry secrets that can be reached from workstations or runners. Identify where the same secret is shared across tools or environments.
• Replace reusable secrets with short-lived access Move high-risk build and developer workflows toward OIDC or other short-lived credential issuance so a compromised tool cannot hold a durable secret to reuse later.
• Pin and verify third-party build artefacts Lock extensions, actions, and packages to known-good commit references or approved versions, and separate publisher credentials from routine build access.
• Restrict runner and workstation egress paths Limit outbound network reach from CI runners and developer endpoints so harvested credentials cannot immediately call external services or propagate the compromise.
• Add runtime visibility for non-human identities Monitor what workloads, runners, and tools read from memory, files, and environment state so secret access is visible at execution time, not only at rotation time.

Key takeaways

• The article shows that the core problem is not a single poisoned extension but the presence of reusable credentials inside trusted execution environments.
• The campaign pattern has already been tied to hundreds of thousands of infected machines and hundreds of gigabytes of harvested secrets, which shows the scale of the exposure.
• The control that would have reduced the blast radius most effectively is eliminating standing credentials from developer and build runtimes.

Key terms

• Long-Lived Credential: A long-lived credential is a secret that remains valid well beyond the original task or session that used it. In identity security, this includes tokens, keys, and API credentials that can be reused after theft, which increases blast radius, complicates attribution, and makes revocation a reactive control instead of a preventive one.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.
• Trusted Execution Environment: A Trusted Execution Environment is a protected hardware-backed area where code runs with stronger isolation from the host system. In AI inference, the point is not just secrecy in transit, but limiting what operators, hypervisors, and surrounding infrastructure can observe during processing.
• Credential Sprawl: Credential sprawl is the uncontrolled accumulation of machine secrets, keys, and tokens across systems, teams, and environments. It usually starts with a single use case and ends with overlapping permissions, unclear ownership, and a larger attack surface than the organisation expected.

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.