TeamPCP exposure shows rotation tickets can lag revoked access

At a glance

What this is: Vectra AI argues that the TeamPCP disclosures show a gap between apparent remediation and actual credential invalidation, with exposure data spanning thousands of organisations and hundreds of thousands of pipeline records.

Why it matters: For IAM, PAM, and NHI teams, the problem is proving that rotation, revocation, and offboarding actually took effect across every automation identity, not just closing the ticket.

By the numbers:

• The archive was linked to more than 2,500 organizations and roughly 434,000 CI/CD pipelines.
• Hudson Rock said the archive contained a 153 GB collection of 433,909 files.
• SOCRadar found that 2,085 of 2,188 organization records, or 95 percent, showed collection activity before March 24.
• The earliest collection record was March 19, 18:05 UTC, and the latest was March 24, 20:09 UTC.

Context

The core issue is not whether a leaked secret was ever rotated, but whether the old credential was actually invalidated everywhere it could authenticate. In NHI governance, a closed remediation task and a revoked credential are not the same outcome, especially when CI/CD pipelines, repository tokens, and cloud service accounts can continue to function after the supposed fix.

Vectra AI uses the TeamPCP disclosures to show how exposure data can outlive the incident timeline that teams initially search. The article argues that the meaningful question is not only what was copied, but which identities still worked after rotation and which systems could still present valid authentication to cloud and pipeline services.

For identity programmes, this is a lifecycle problem as much as a detection problem. If a pipeline identity, automation token, or cloud key remains accepted after remediation, the organisation has not completed recovery, it has only documented an intention to recover.

Key questions

Q: What breaks when teams rotate a secret but do not remove all copies?

A: Rotation only protects the new value if every old copy is retired. If the credential still exists in other repositories, pipelines, or third-party integrations, the exposure window remains open. Teams then believe the incident is closed while another valid path still exists.

Q: Why do leaked pipeline credentials create risk even after the public incident window has passed?

A: Because collection, publication, and reuse are different phases. A token may be copied well before the visible event and remain usable after it, which means response teams need to hunt from the earliest collection evidence rather than the headline date.

Q: How do security teams know if credential rotation actually worked?

A: They need proof that every consumer rejected the old credential, every dependent workflow has moved to the replacement, and no residual access path still functions. A rotation is not complete until validation shows the old secret is dead everywhere it mattered. Without that verification, response teams are guessing.

Q: What should teams do when a secret may already be exposed?

A: They should assume the secret is compromised until proven otherwise, revoke it, rotate dependent credentials, and check for secondary copies across repositories, tickets, and collaboration tools. The goal is to limit reuse before an attacker can convert exposure into access. Waiting for confirmation usually gives the attacker more time than defenders have.

Technical breakdown

Why credential rotation can leave live access behind

Rotation only replaces a value if every authenticating path accepts the new secret and rejects the old one. In pipeline-heavy environments, a service account may exist in multiple places at once: repo settings, CI variables, package publish workflows, and cloud service bindings. If one location is missed, the old token can still authenticate successfully even though the ticket says rotation is complete. That is why token replacement is not the same as access revocation. The failure mode is lifecycle fragmentation, where control ownership is split across teams and systems that do not share a single source of truth.

Practical implication: verify invalidation at each authentication point, not just in the secret store.

Why reconstructed exposure is not the same as confirmed compromise

A reconstructed exposure archive is a derived evidence set, not always a forensic statement that every credential was used or every named organisation was breached. That distinction matters because teams often overfit response to a narrow incident window and then miss older collection activity. In this case, the article shows that exposure can predate the public release of poisoned packages, meaning the initial compromise chain may sit upstream of the obvious event. For NHI governance, the key lesson is that collection time, publication time, and use time can be separate phases.

Practical implication: scope hunts to the earliest collection evidence, not to the most visible event date.

How valid tokens become invisible risk in automation

A valid token does not announce itself as malicious when it authenticates successfully. Cloud logs typically record a successful call from a recognised principal, which means compromise can look operationally normal until you correlate it with unusual timing, new resources, or an unexpected client path. That is why secrets abuse is so difficult in CI/CD and workload identity environments: the attacker does not need to break authentication if they can reuse it exactly as designed. The architectural problem is that success and safety are not the same thing.

Practical implication: build detections around behaviour after authentication, not only failed logins.

Threat narrative

Attacker objective: The objective was to preserve usable automation access long enough to keep reaching repositories, pipelines, and downstream secrets after remediation was believed complete.

1. Entry occurred when automation credentials and pipeline secrets were copied into the TeamPCP archive from the upstream compromise chain.
2. Credential access then persisted because at least one surviving token or service account remained usable after a rotation event on March 1.
3. Escalation followed when malicious activity continued through identities that were still accepted by cloud and CI/CD systems.
4. Impact was continued access to repositories, pipelines, and related secrets, even after teams believed remediation had closed the exposure.

Breaches seen in the wild

• Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.
• ChainDrop npm worm 2026: A self-propagating npm worm starting with keyv hit 444 packages in hours, harvesting publishing tokens, CI secrets, cloud keys and AI tool credentials.

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

Credential rotation is not remediation unless the old identity is provably dead: The TeamPCP disclosures show the gap between a closed ticket and a revoked credential. In NHI governance, rotation that does not invalidate the previous authenticator everywhere it can be used is only partial containment. The practitioner conclusion is simple: lifecycle completion must be proven at each authentication edge, not assumed from a change record.

Exposure reconstruction changes the hunt window: The article makes clear that the most visible event is not always the earliest collection point. That matters because teams that search only around the public incident date will miss upstream harvesting and later reuse. The implication is that NHI incident response must start from first collection evidence and work forward, rather than anchoring on the headline date.

Ephemeral access debt is the new name for leftover automation access: When automation identities survive a remediation cycle, the organisation carries access debt that behaves like an outstanding liability. The secret may be rotated, but the trust relationship remains live until every dependent system has rejected the old credential. Practitioners should treat this as a governance defect in identity lifecycle closure, not a routine cleanup issue.

Pipeline identities need the same offboarding discipline as human access: This article is a reminder that service accounts, repository tokens, and cloud keys are governed identities, not disposable implementation details. If offboarding is incomplete, an attacker can continue to authenticate through the exact interface the pipeline already trusts. The conclusion for IAM and NHI teams is that offboarding evidence matters as much as provisioning evidence.

Identity blast radius is defined by what still authenticates after compromise: The article’s real signal is that compromise scope is determined by surviving access paths, not by the original secret that was found. Once a token remains valid, the blast radius extends to every system that still accepts it. Practitioners need to map which credentials can still move across repositories, CI/CD, and cloud services after a rotation event.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.

What this signals

Ephemeral credential trust debt: Once a pipeline secret has been copied, the organisation inherits a period of residual trust in identities that may still authenticate successfully. The operational goal is not to admire the rotation event, but to prove that every old credential is rejected across build, repo, and cloud boundaries.

Searches that stop at the public incident date will miss upstream collection and later reuse. For NHI programmes, the stronger control is to anchor hunting on the earliest observed collection activity and then trace forward through any surviving identities.

According to the 2024 State of Secrets Management Survey, the average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes. That delay is long enough for a surviving automation token to remain useful if offboarding is incomplete.

For practitioners

• Verify revocation, not just rotation Confirm that each old cloud key, repository token, service account, and AI provider key is rejected at every system that can authenticate it, not only replaced in a vault.
• Expand hunt windows to the earliest collection point Search pipeline logs, repository events, and cloud sign-ins back to the first evidence of collection, even if that precedes the public incident date by days or weeks.
• Inventory all identities touched by automation workflows List every service account, CI runner credential, publish token, and package signing identity that the affected workflows could reach, then verify each one independently.
• Test for surviving access after a remediation ticket closes Use a controlled access check to confirm that a credential marked rotated cannot still reach repositories, build systems, or cloud APIs through an alternate path.
• Treat quiet logs as insufficient evidence Assume a lack of alerts means only that you did not observe misuse, not that the credential was never copied or later reused by a different identity.

Key takeaways

• The TeamPCP disclosures show that closing a remediation ticket does not prove an old automation credential has been invalidated.
• The article’s timeline suggests exposure can predate the event teams initially investigate, so hunt windows must start earlier than the headline date.
• The limiting control is lifecycle closure at every authentication point, because a still-valid token turns rotation into a partial fix.

Key terms

• Credential Rotation: The practice of regularly replacing secrets and credentials with new values to limit the window of exposure if a credential is compromised. Automated rotation, enforced by policy, is the security-optimal approach.
• Reconstructed Exposure: Reconstructed exposure is an evidence set assembled from logs, dumps, or disclosures that indicates where credentials may have been present or collected. It is useful for scoping investigations, but it is not the same as a confirmed compromise or proof that every listed organisation was breached.
• Lifecycle Closure: Lifecycle closure is the discipline of making sure access does not only get granted and adjusted, but also removed when the business need ends. In identity governance, it means provisioning, change, review, and revocation are treated as one control loop rather than separate tasks.
• 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.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.