In late February 2026, an AI-powered bot called hackerbot-claw targeted open-source repositories belonging to Microsoft, Datadog, Aqua Security and others. It opened pull requests with trivial changes while hiding malicious payloads in branch names and CI scripts. Those payloads triggered automated workflows that exfiltrated secrets from build runners. One of its highest-profile targets was Trivy, a widely used security scanner, where the bot exploited a pull_request_target workflow to steal a personal access token. A few months earlier, the compromised tj-actions/changed-files GitHub Action exposed secrets for more than 23,000 repositories by dumping runner memory into build logs.
These incidents follow a pattern that has repeated for years: attackers target CI/CD pipelines because the credentials stored there unlock production infrastructure. The CircleCI breach, the Codecov supply chain attack and the GitLab EE CVE-2024-9164 vulnerability all traced back to the same root cause. Static, long-lived credentials sit inside pipeline configurations, and anyone who compromises the pipeline inherits whatever those credentials can access.
Identity federation offers a different approach. Workloads prove who they are through cryptographic attestation and receive short-lived tokens scoped to a single operation. The credential never persists, so there is nothing for an attacker to steal and reuse.
Why CI/CD Pipelines Have Become Prime Targets
CI/CD pipelines sit at the intersection of source code, cloud infrastructure and production deployments. They routinely handle database passwords, cloud provider keys, API tokens for third-party services and deployment credentials. That concentration of access makes them one of the highest-value targets in a modern software environment.
The scale of exposure keeps growing. GitGuardian’s 2026 report on secrets sprawl found 28.65 million new hardcoded secrets on public GitHub in 2025, a 34% year-over-year increase. In the Shai-Hulud 2 supply chain attack analyzed in the same report, 59% of compromised machines were CI/CD runners rather than developer workstations. Build infrastructure has become the primary vector for credential theft, not a secondary one.
The OWASP CI/CD security risks project documents how attackers exploit this surface: poisoned pipeline execution, insufficient credential hygiene, insecure system configuration and inadequate identity verification. Each risk category traces back to the same structural weakness. Pipelines accumulate credentials over time, and those credentials grant broad, persistent access that outlives the jobs they were created for.
Agentic AI compounds the problem. As organizations deploy AI-powered coding assistants and automated agents that interact with CI/CD systems, the number of non-human identities requesting access to pipeline resources is climbing. Each new integration adds another credential to manage and another point where a secret can leak.
How Static Credentials Multiply Risk Across the Pipeline
A typical CI/CD pipeline might store an AWS access key for deployments, a database password for migration scripts, a container registry token for image pushes and API keys for third-party services like monitoring or notification platforms. Each of those credentials shares a set of dangerous properties.
Persistence: Static credentials remain valid until someone explicitly revokes them. GitGuardian’s 2026 report found that 64% of secrets confirmed as valid in 2022 were still active four years later. That means a credential leaked today could remain exploitable well into 2030 if no one rotates it.
Secrets also spread. A single credential rarely stays in one place; it gets copied into environment variables, embedded in configuration files, cached in runner images and pasted into collaboration tools during troubleshooting. GitGuardian found that on average, each live secret appeared in eight different locations on the same machine. That duplication compounds the scope problem. Teams often provision pipeline credentials with wide permissions to avoid breaking builds, so a deployment key might have read-write access to every S3 bucket in an account rather than the single bucket the pipeline actually needs. When that credential is compromised, the blast radius extends far beyond the original use case.
Rotation friction: Rotating a credential that exists in eight locations across three environments requires coordinating changes across teams, updating configurations and testing that nothing breaks. Many organizations defer rotation indefinitely because the operational cost feels higher than the perceived risk.
The CircleCI breach illustrates how these properties compound. An attacker stole a 2FA-backed SSO session cookie from an engineer’s laptop, used it to access internal systems and exfiltrated customer secrets stored in pipeline configurations. Those secrets were long-lived, broadly scoped and duplicated across environments. A single compromised endpoint became a platform-wide incident.
Workload Identity Federation as the Replacement Model
Workload identity federation replaces stored credentials with a runtime authentication flow. The pipeline proves its identity to a target service and receives a short-lived token scoped to the specific operation it needs to perform.
The mechanism relies on OpenID Connect (OIDC) tokens that CI/CD platforms already issue natively. When a GitHub Actions workflow runs, GitHub generates a signed OIDC token containing claims about the workflow: which repository triggered it, which branch, which environment and which actor initiated the run. The target cloud provider (AWS, Azure or GCP) verifies that token against a pre-established trust relationship and issues temporary credentials in exchange.
This flow eliminates three categories of risk simultaneously.
No credential storage: The pipeline never possesses a persistent secret. The OIDC token is generated fresh for each workflow run and the cloud credentials it receives expire within minutes. There is nothing to leak in a build log, nothing to duplicate across environments and nothing for an attacker to harvest from a compromised runner.
Short-lived tokens also remove the rotation problem entirely. When a token expires in 15 minutes, there is no four-year-old credential sitting in a configuration file waiting to be exploited. The window of opportunity for an attacker shrinks from years to minutes.
Granular scope: Because each token is issued for a specific workflow run, access can be scoped to exactly what the job requires. A deployment job gets write access to the production S3 bucket for the duration of that deployment. A testing job gets read-only access to a staging database for the duration of that test run. Narrow, time-bound grants replace the broad, persistent permissions that make static credentials dangerous.
GitHub Actions, GitLab CI/CD and most major CI/CD platforms now support OIDC federation natively for connections to AWS, Azure and GCP. The configuration typically involves creating an identity provider in the cloud account, defining a trust policy that maps specific repository and branch claims to an IAM role and replacing the stored credential in the workflow with a token exchange step. For a GitHub Actions workflow connecting to AWS, the change replaces a stored AWS_ACCESS_KEY_ID with a secretless OIDC authentication flow that requires no static secrets at all.
What Federation Alone Cannot Solve
Native cloud federation works well for single-cloud, single-platform scenarios. A GitHub Actions workflow authenticating to AWS through OIDC is straightforward to configure and maintain. But real-world CI/CD environments rarely stay that simple.
A deployment pipeline might need to authenticate to AWS for infrastructure provisioning, a SaaS monitoring tool for deployment notifications, a third-party API for compliance checks and an internal service for artifact signing. Each of those destinations requires its own federation relationship, its own trust configuration and its own token exchange flow. As the number of services grows, the operational burden of managing pairwise federation relationships grows with it.
Federation also leaves gaps in access governance. A cloud IAM role can restrict which resources a workload accesses, but it cannot evaluate contextual factors like time of day, geographic location or the security posture of the runner executing the pipeline. A pipeline that should only deploy during business hours from a hardened runner environment needs policy enforcement that goes beyond what a static IAM trust policy provides.
Visibility is another gap. When each cloud provider manages its own federation relationships independently, there is no single place to see which workloads accessed which resources, when and under what policy. Audit trails fragment across providers. Compliance reporting and incident investigation become slower and more error-prone as a result.
Workload identity and access management (WIAM) platforms address these gaps with a centralized control plane for workload-to-workload access. You define each service once and create access policies that apply across environments. Pairwise federation configurations become unnecessary. Conditional access policies can enforce contextual requirements like deployment windows and runner posture. Centralized logging captures every access decision with full context and routes events to downstream SIEMs. Teams no longer need to correlate data across multiple cloud providers.
For CI/CD pipelines specifically, this means a single integration point that replaces the patchwork of stored secrets, per-service federation configurations and manual audit processes that most organizations maintain today. A WIAM platform verifies pipeline identity through cryptographic attestation, enforces policy-based access at every connection point and brokers short-lived credentials so pipelines never store static secrets to authenticate.
Credential Debt Keeps Compounding
As pipeline complexity grows and agentic AI introduces new categories of non-human identities into CI/CD workflows, the gap between what native federation provides and what production environments require will continue to widen. Every new service integration, every additional cloud provider and every AI agent that touches the pipeline introduces another identity to govern or another federation relationship to maintain. Organizations that treat workload identity as an infrastructure investment rather than a per-service configuration problem will be better positioned to absorb that complexity without accumulating the credential debt that powers most pipeline breaches today. Aembit was built for exactly this shift. It replaces static secrets across CI/CD pipelines and workload environments with identity-based access that scales with the infrastructure it protects.
