A CI/CD system that does more than build and deploy because it also stores or issues credentials for cloud and application access. In practice, this creates a hidden identity tier inside delivery infrastructure, where compromise of the pipeline can expose downstream permissions.
What makes a CI/CD credential broker different
A CI/CD credential broker is not just a build-and-deploy layer, it also becomes a trust boundary that stores, mints, or forwards credentials for cloud, deployment, and application access. That turns delivery tooling into part of the organisation’s access fabric, not only its automation stack.
The key distinction is that the pipeline no longer only moves code, it can also move authority. If the broker issues short-lived tokens, exchanges federation assertions, or injects secrets into jobs, it effectively sits between the build system and the protected runtime it reaches.
Why this creates a hidden identity tier
Credential brokers inside CI/CD often emerge because teams need unattended deployment, artifact publishing, environment promotion, or cloud API access at scale. The broker centralises those functions, which reduces friction, but also concentrates access paths that would otherwise be spread across separate services and operators.
This hidden tier is easy to miss because it is embedded in delivery workflows and may not be treated as a standalone identity system. In practice, it governs who can act on behalf of pipelines, runners, jobs, and release automation.
Common security mechanisms and failure modes
Credential brokering can use vault lookups, secret injection, OIDC federation, token exchange, or scoped API keys to give jobs the access they need. When designed well, those mechanisms support narrow, time-bound access; when designed poorly, they create long-lived secrets, broad permissions, or shared credentials that are hard to audit.
The failure modes are usually structural rather than exotic: overprivileged tokens, leaked environment variables, reused credentials across pipelines, and weak separation between build, test, and release stages. A broker that can be reached from untrusted jobs, third-party actions, or shared runners also widens the blast radius of compromise.
Why compromise of the pipeline becomes a permissions problem
Once a CI/CD system can issue or store credentials, compromise of that system is no longer limited to source code tampering. An attacker who reaches the broker can often pivot into cloud control planes, container registries, package repositories, or production deployment paths through the credentials the broker exposes.
That is why CI/CD credential brokers are best understood as both infrastructure and access control. The security question is not only whether the pipeline builds correctly, but whether it can safely hold and delegate authority without turning build compromise into downstream account compromise.
Risk and Threat Considerations
Credential brokers create concentrated exposure because they sit at the point where automation receives authority. If secrets, tokens, or federation paths are weakly protected, a single pipeline compromise can turn into cloud access, deployment abuse, secret theft, or persistence in downstream systems.
Failure mechanism: Attackers target the broker, the runner, or any upstream dependency that can reach it, then extract or abuse the credentials it stores, issues, or injects. Shared secrets, long-lived tokens, and overly broad delegation make that path especially valuable.
Impact: Compromise can spread beyond the CI/CD platform into production workloads, registries, infrastructure APIs, and third-party services, creating lateral movement opportunities and forcing rotation across multiple trust domains.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CI/CD brokers store and issue secrets that can leak from delivery paths. |
| NHI-04 — Insecure Authentication | Brokered pipeline access depends on how jobs authenticate to issue or receive credentials. | |
| NHI-05 — Overprivileged NHI | Pipeline-issued credentials often grant cloud and deployment access with excessive scope. | |
| Recommendation — Centralise brokered secrets and scan pipeline outputs for exposed credentials. Use strong federated authentication for pipeline jobs instead of static shared secrets. Scope broker-issued credentials to the minimum permissions each job requires. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential brokers manage generation, rotation, storage, and revocation of authenticators. |
| AC-6 — Least Privilege | CI/CD brokers should limit what automated jobs can access or do. | |
| IA-9 — Service Identification and Authentication | Brokers commonly authenticate workloads, runners, and services to each other. | |
| Recommendation — Rotate, revoke, and expire brokered credentials on a short lifecycle. Restrict pipeline credentials to least privilege for each stage and environment. Authenticate pipeline services with workload-to-workload trust instead of shared secrets. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Broker endpoints and token exchange paths are authentication-critical attack surfaces. |
| Recommendation — Harden broker authentication and reject weak or replayable token flows. | ||
Practitioner Guidance
Why practitioners should care: Treat the credential broker as an identity-bearing component of delivery infrastructure, not as a convenience feature. The governance question is whether the broker’s issuance, scope, and expiry model matches the minimum authority each pipeline stage actually needs.
What to watch for: Broadly scoped tokens, static secrets embedded in jobs, shared credentials across environments, and brokers reachable from untrusted build paths are all signs that the delivery layer has become an unnecessary authority concentration.
Practitioner takeaway: A CI/CD credential broker should reduce standing access, not become the system where standing access is hidden.
Related resources from NHI Mgmt Group
- Why do secrets managers not fully solve credential theft in CI/CD?
- How should security teams implement runtime credential brokering for CI/CD workloads?
- Why do misconfigured CI/CD workflows increase credential theft risk?
- What breaks when CI/CD release workflows can be triggered by a compromised push credential?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org