Zero-trust CI/CD replaces standing secrets with scoped identity, policy gates, and audit trails for coding agents in pipelines. Full breakdown.
Why standing secrets break down for coding agents
Coding agents in CI/CD often need repository access, cloud APIs, package registries, and deployment targets. The usual fix is a long-lived token or shared key stored as a pipeline secret. That model assumes a trusted runner and a narrow blast radius. Agents change both assumptions: they take multi-step actions, call tools, and may open pull requests or apply infrastructure changes without a human at every click. A stolen or over-scoped credential then becomes a general-purpose key into the delivery path, not a single-job password.
Zero-trust permissions start from a different default: no agent identity is trusted by default, and no secret should outlive the job that needs it. Access is granted for a specific action, against a specific resource, for a short window, and only when policy allows it. Standing secrets are the opposite of that model—they invert trust into ambient privilege.
Scoped identity instead of shared keys
Replace static credentials with short-lived identity tied to the pipeline run, the repository, the branch, and the agent task. The agent authenticates as a workload, not as a person and not as a shared “CI bot” account. Each identity should carry only the claims needed for that run: read this repo, write to this environment, open PRs but not merge, or call one API surface rather than an entire cloud account.
Practical design choices matter. Prefer federated or OIDC-style workload identity so the pipeline never stores a permanent secret for cloud access. Scope tokens to the minimum resource set and the minimum action set. Separate identities for plan, apply, and publish stages so a compromised lint or test step cannot also ship production. When an agent needs elevated rights, require a distinct, time-bound grant rather than widening the base identity for every run.
Policy gates before high-impact actions
Identity alone is not enough. Agents still need hard gates at the points where damage is possible: merging, deploying, mutating infrastructure, rotating credentials, or posting to external systems. Express those gates as policy that the pipeline evaluates before the action runs, not as comments in a runbook.
- Allowlist which tools and APIs an agent may invoke in a given stage.
- Require human approval or a second identity for production writes and secret material.
- Block privileged actions on untrusted branches and unreviewed changes.
- Fail closed when policy evaluation is unavailable or incomplete.
Policy should be versioned with the pipeline, testable in pull requests, and readable by both engineers and security reviewers. The goal is not to slow every job—it is to make high-impact paths explicit and enforceable while keeping low-risk work unblocked.
Audit trails that make agent behavior reviewable
Zero-trust without observability is incomplete. Every agent session should leave a durable record of who (which identity and run), what was requested, what policy decided, which credentials were issued, and which external systems were touched. Logs should link pipeline IDs, commit SHAs, and tool invocations so an incident review can reconstruct the path without guessing.
Treat audit data as part of the delivery system: retain it long enough for post-incident analysis, protect it from tampering by the agent itself, and alert on unusual patterns such as new APIs, broader scopes, or failed policy checks followed by retries. Over time, those trails also inform tighter scopes—rights that never appear in successful runs are candidates for removal. Scoped identity, policy gates, and audit trails work together: identity limits what an agent can claim, policy limits what it may do, and audit shows whether both held under real pipeline conditions.