How should security teams implement runtime credential brokering for CI/CD workloads?

Start by identifying jobs that still rely on long-lived secrets, then move those paths to workload identity federation with task-scoped issuance. The broker should issue only the credential needed for that run, with trust policy tied to repo, branch, environment, and workflow. That reduces standing access and limits blast radius if a pipeline is compromised.

Why This Matters for Security Teams

Runtime credential brokering changes CI/CD from a secrets distribution problem into a workload identity problem. That matters because pipelines are not static users: they are event-driven, highly parallel, and often triggered from multiple branches, runners, and environments. When teams keep long-lived API keys or cloud tokens in the pipeline, compromise of a single job can become persistent access across deployments, registries, and infrastructure.

Current guidance suggests the safer model is short-lived, task-scoped issuance tied to what the workload is allowed to do at that moment. That aligns with the OWASP Non-Human Identity Top 10 and with NHIMG research showing that 66% of organisations say their tooling is not adequate to manage the scale of machine identities they now have, while only 38% have automated certificate lifecycle management in place in the Critical Gaps in Machine Identity Management report. In practice, many teams discover secret sprawl only after a build agent, dependency step, or compromised workflow has already used the credential beyond its intended scope.

How It Works in Practice

A runtime broker sits between the CI/CD job and the target system that issues or accepts credentials. Instead of preloading a secret into the runner, the job authenticates with its workload identity, then asks the broker for a narrow credential bound to the specific run. Best practice is evolving toward federation plus policy-as-code, where the broker evaluates repo, branch, environment, workflow name, commit state, and sometimes approval status before minting access.

The technical pattern usually includes:

• Workload identity as the starting point, not a shared secret. For many teams, the cleanest approach is federation using SPIFFE workload identity specification or an OIDC-based assertion from the CI platform.
• Short-lived credentials issued just in time, with a TTL matched to the job duration rather than an arbitrary rotation cycle.
• Trust policy that is explicit about source code location, branch protection, deployment environment, and the exact operation requested.
• Revocation or automatic expiry as soon as the task completes, so the credential does not become a reusable asset.

This approach maps cleanly to the operational reality described in the Ultimate Guide to NHIs — Static vs Dynamic Secrets, where static secrets extend blast radius while dynamic secrets reduce standing access. It also fits the identity assurance principles in NIST SP 800-63 Digital Identity Guidelines when the broker uses strong proof of workload possession rather than trusting the runner image alone. These controls tend to break down in self-hosted runners with weak isolation, because a compromised host can steal the broker token before the runtime policy ever has a chance to constrain it.

Common Variations and Edge Cases

Tighter brokering often increases pipeline complexity and operational overhead, so organisations have to balance stronger blast-radius reduction against build latency, policy maintenance, and runner diversity. There is no universal standard for this yet, especially when multiple clouds, artifact registries, and deployment targets all expect different token formats.

One common variation is branch-based trust with stronger controls for protected branches and release tags than for feature branches. Another is environment-aware issuance, where production jobs must satisfy additional gates such as human approval, change ticket validation, or signed provenance before the broker returns a deploy credential. Current guidance suggests avoiding broad reusable tokens even for internal tools, because a broker that issues one all-purpose credential per pipeline quickly recreates the same standing-privilege problem it was meant to solve.

Security teams should also watch for these edge cases:

• Matrix builds and parallel steps that need separate credentials per subtask.
• Long-running jobs that outlive short TTLs and fail unless refresh logic is built in.
• Third-party actions or shared templates that inherit broker trust without enough scoping.

NHIMG research on the CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack shows why over-trusting pipeline components is dangerous: once an attacker lands inside the workflow, broad token reuse makes lateral movement easy. In practice, runtime brokering works best where runners are ephemeral and policy inputs are reliable, and it degrades when legacy jobs depend on shared environments, ad hoc scripts, or opaque third-party actions.

Related resources from NHI Mgmt Group

• How should security teams reduce secret sprawl in CI/CD and agent workflows?
• How should security teams reduce container runtime risk in Kubernetes environments?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams govern machine credentials across cloud and CI/CD environments?