Agent credentials in CI/CD and secrets handling

The concentration problem

A build environment typically holds, at once: cloud provider credentials for deployment, container registry push tokens, package registry publish tokens, code-signing keys, and access to the source repository itself. Anything executing in that environment can reach all of them.

That was the Codecov pattern: a modified script exfiltrated environment variables, and the credentials it captured were themselves keys to production and to package registries. The compromise did not stop at data theft, it escalated into the supply chain. It is also why the Shai-Hulud worm could self-propagate, each captured maintainer credential expanded the attack surface without further attacker action.

What agents change

1. Untrusted content enters the credential-rich environment. An agent triaging issues, reviewing pull requests or summarising dependency changes is processing text from outside your trust boundary, inside the place where your credentials live. That is prompt injection with an unusually good payoff.
2. The agent's reach is the union of the pipeline's. Agents are usually given the pipeline's existing credentials because that is the path of least resistance, which grants them everything the pipeline can do rather than what the task requires.
3. Generated code is executed. An agent that writes code which then runs in the pipeline has an indirect path to arbitrary execution with pipeline privileges.
4. Attribution collapses. Commits, deployments and package publishes attributed to a shared bot identity cannot be traced to the human who initiated the work.

The credential model

Three changes, in order of impact:

1. Workload identity federation instead of stored secrets. The pipeline proves what it is to the cloud provider using an OIDC token issued by the CI system, and receives a short-lived credential scoped to that job. No static cloud key exists in the environment. This is available on every major CI system and cloud provider today, and it eliminates the largest single class of exposure.
2. Per-job, per-purpose scoping. A job that builds does not need publish rights. A job that runs tests does not need deployment rights. Splitting these is more work and it converts a total compromise into a partial one.
3. A distinct identity per agent, not the pipeline's. The agent gets its own registered identity with reach scoped to its actual task, and user authority carried separately when it acts for a person. See delegation chains.

Secrets handling for agents specifically

• Mint per call rather than inject into the environment. If a credential is in an environment variable, it is in the process the agent can read, and often in logs.
• Never place a secret in agent context. System prompts, tool descriptions and configuration passed to the model are all reachable by the model and by anything that manipulates it.
• Broker downstream access. The agent asks a broker to perform an action; the broker holds the credential and enforces policy. The agent never possesses the secret at all, which makes exfiltration structurally impossible rather than merely unlikely.
• Redact in logs and traces. Agent observability tooling captures full request and response payloads by default, which is a new and under-inspected secrets surface.
• Scan generated artefacts. Agents can reproduce a credential they saw into generated code or configuration. Treat agent output as a source that needs secrets scanning, the same as human-authored code.

Controls in priority order

1. Eliminate long-lived cloud credentials via workload identity federation. Highest impact, no new tooling.
2. Egress allowlisting on build and agent runtimes. Most exfiltration ends in an outbound call to an arbitrary endpoint. Cheap, rarely applied.
3. Separate identities per job purpose, so one compromise is not total.
4. Fork-triggered jobs get no secrets. A configuration setting, not a project.
5. Broker rather than inject for anything an agent touches.
6. Secrets scanning on agent output as well as on commits.
7. Attribution: distinct identity per agent, and the initiating human recorded on every pipeline-triggered action.

Frequently asked questions

Why is CI/CD the highest-risk environment for non-human identities?

Because it concentrates credentials that are otherwise separated. A build environment typically holds cloud deployment credentials, container and package registry tokens, code-signing keys and source repository access simultaneously, usually with weaker controls than production. Anything executing there can reach all of them, which is why the Codecov compromise escalated from data theft into the software supply chain.

What changes when AI agents operate inside a pipeline?

Untrusted content enters the credential-rich environment, since an agent triaging issues or reviewing pull requests processes text from outside your trust boundary. Agents are usually handed the pipeline's existing credentials, so their reach becomes the union of everything the pipeline can do. Generated code is executed, giving an indirect path to arbitrary execution with pipeline privileges. And attribution collapses when actions run under a shared bot identity.

How do you remove static secrets from CI/CD?

Workload identity federation. The pipeline proves what it is to the cloud provider using an OIDC token issued by the CI system and receives a short-lived credential scoped to that job, so no static cloud key exists in the environment. This is supported by every major CI system and cloud provider, requires no new tooling, and eliminates the largest single class of CI/CD credential exposure.

How should an agent access secrets it needs?

Ideally it should not possess them at all. Use a broker: the agent requests an action, the broker holds the credential and enforces policy, and the agent never sees the secret. Where that is impractical, mint credentials per call rather than injecting them into the environment, and never place a secret in system prompts, tool descriptions or any configuration the model can read.

What is the single most common CI/CD credential mistake?

A long-lived cloud access key stored as a repository secret and available to every job in every branch, including jobs triggered by pull requests from forks. It has been behind a large share of CI/CD compromises, it is trivially discoverable in an inventory, and workload identity federation replaces it without new tooling.