How should security teams limit exposure from code-bearing workflows?

Why This Matters for Security Teams

Code-bearing workflows such as CI/CD pipelines, build runners, automation bots, and deployment jobs are attractive because they can execute trusted actions quickly, but that same trust makes them high-value non-human identities. When workflow authoring, runtime execution, and secret access are loosely coupled, a small change in code can become a production-grade access path. NHIMG research shows that long-term credentials are still stored directly in code in 30.9% of organisations, which means the workflow itself often becomes the credential container.

The practical risk is not just leakage, but blast radius. A workflow with broad secrets can reach source control, cloud APIs, package registries, and deployment targets in one execution path. That creates a lateral movement opportunity if an attacker edits the workflow, hijacks a dependency, or abuses an overly permissive runner. Guidance from the Anthropic report on AI-orchestrated cyber espionage also reinforces how quickly automated execution can chain actions once initial access is obtained. In practice, many security teams only discover the issue after a pipeline has already minted, moved, or exfiltrated production secrets.

How It Works in Practice

The safest pattern is to treat workflow editing as a privileged activity and execution as a separate, narrowly scoped identity. That means the person or system that can modify the pipeline should not automatically inherit production secret access, and the runtime should not see secrets it does not need. This is the same separation principle behind strong NHI governance, and NHIMG’s 52 NHI breaches report shows how often compromise starts with weak control of a non-human credential rather than a sophisticated exploit.

Operationally, teams should issue dedicated low-trust service identities for execution, use short-lived credentials where possible, and bind secrets to the narrowest job context that can complete the task. Current practice is moving toward just-in-time access, ephemeral tokens, and workload identities rather than static shared secrets. In a mature setup, the runner authenticates as a workload, obtains only the secret required for that step, and loses access when the job ends. Where supported, policy should be evaluated at request time so approvals reflect environment, repository, branch, and job purpose instead of a fixed role alone.

• Separate repository write access from runner administration and secret vault administration.
• Prefer dedicated service identities per workflow, environment, or deployment lane.
• Store secrets in a vault and inject them only at runtime, never into source or long-lived config.
• Limit egress, public internet exposure, and cross-environment access from runners by default.
• Log secret retrieval, workflow edits, token issuance, and deployment actions as distinct events.

These controls tend to break down in self-hosted runners that share hosts, images, or persistent state because one compromise can expose multiple workflows and their cached credentials.

Common Variations and Edge Cases

Tighter workflow isolation often increases operational friction, requiring organisations to balance release speed against reduced blast radius. That tradeoff is especially visible in fast-moving engineering teams, monorepos, and ephemeral build systems where many jobs need different permissions. Current guidance suggests treating these environments as policy problems, not just tooling problems, because there is no universal standard yet for how much autonomy an automation job should have.

Hybrid setups need extra care. If a workflow can deploy to multiple clouds, call third-party APIs, or trigger downstream automation, the safest answer is not one broad secret set but separate identities and secrets per destination. This is where secret sprawl becomes dangerous: NHIMG’s Secret Sprawl Challenge research highlights how easily credentials multiply across code, CI/CD variables, and automation tooling. The best practice is evolving toward per-workflow trust boundaries, short-lived issuance, and explicit approval gates for production changes. Public-facing runners, shared build pools, and workflows that must reach many external services remain the hardest environments to secure because they combine high privilege with broad network exposure.

Related resources from NHI Mgmt Group

• How should security teams add authorization to legacy applications without changing code?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams govern eSignature workflows in low-code automation platforms?
• How should security teams govern AI-generated identity workflows in application code?