OIDC tokens, scoped jobs, SLSA v1.2 provenance, and short-lived signing certs can lock down coding agents in CI/CD pipelines. Full breakdown.
Why coding agents need zero-trust in CI
Coding agents in CI can read repos, open pull requests, run tests, push artifacts, and call external APIs. That makes them powerful and risky: a single over-privileged job can exfiltrate secrets, alter release artifacts, or merge unsafe changes. Zero-trust for these agents means no ambient trust from “being on the runner.” Every action should prove who is running, what is allowed, and for how long—then drop those rights when the job ends.
The goal is not to ban agents, but to make their authority narrow, short-lived, and verifiable. OIDC tokens, scoped jobs, SLSA v1.2 provenance, and short-lived signing certs work together as that control plane.
OIDC tokens instead of long-lived secrets
Long-lived cloud credentials in CI are a common failure mode: they leak from logs, forks, or compromised runners and stay valid after the job is gone. Prefer OIDC federation so the pipeline requests a short-lived identity token at job start. The identity provider mints claims about the repository, workflow, ref, and environment; the cloud or package registry maps those claims to a role with only the permissions that job needs.
For coding agents, bind the token to the agent’s job identity, not a shared “CI bot” role. Require audience and subject checks so a token from one workflow cannot call APIs meant for another. Rotate nothing by hand: when the job ends, the token expires. Prefer audience-restricted tokens and environment protection rules so production-facing roles cannot be assumed from untrusted branches.
Scoped jobs and least privilege for agent steps
Split agent work into small jobs with explicit permissions instead of one monolithic pipeline with write-all access. A planning or review job may only need read access to the repository. A patch-application job may need write access to a feature branch but not to protected branches or release tags. A publish job should be separate, gated, and allowed only after human or policy checks pass.
- Grant the minimum token scopes for that step (contents, pull requests, packages, deploy keys) and nothing else.
- Keep secrets out of agent-visible environments unless a later, audited job needs them.
- Block self-approval paths: the agent that opens a change should not be the same identity that merges or ships it.
- Constrain network egress and tool allowlists so the agent cannot reach arbitrary endpoints with production credentials.
Scoped jobs also limit blast radius. If an agent prompt injection or dependency compromise succeeds in one step, it should not inherit the credentials of later deploy or signing stages.
SLSA v1.2 provenance and short-lived signing certs
Zero-trust does not stop at runtime permissions. Consumers of agent-produced artifacts need evidence of how those artifacts were built. SLSA v1.2-style provenance records the builder identity, source revision, materials, and parameters used to produce an artifact. Attach and verify that attestation before promoting binaries, container images, or model-assisted code packages. Reject builds whose provenance is missing, unsigned, or claims a builder identity you do not trust.
Pair provenance with short-lived signing certificates rather than permanent keys on disk. Issue certs only for the signing job, scoped to that repository and workflow, with a lifetime measured in minutes. Sign the artifact and the provenance, then discard the private material. Downstream systems should verify the chain, the certificate’s validity window, and that the signer identity matches the expected OIDC subject. Together, OIDC identity, scoped jobs, verifiable provenance, and ephemeral signing close the loop: the agent can act, but only briefly, only where allowed, and only in ways that leave an auditable trail.