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: an altered script sent each CI job's environment variables to a third-party server, so any credential, token or key passed through the runner may have been exposed. The effects reached past Codecov itself: HashiCorp revoked and replaced the GPG key used to sign its release hashes, and Twilio, Rapid7 and monday.com each disclosed access to repositories or source code. The same concentration is why the Shai-Hulud worm could self-propagate: where it found npm credentials, it published infected versions of other packages those credentials could publish.

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. Giving an agent the pipeline's existing credentials is the path of least resistance, and it 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. GitHub Actions and GitLab CI/CD can issue these OIDC tokens, and AWS, Microsoft Azure and Google Cloud accept them through their federation features. It removes stored cloud keys from the pipeline.
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 can capture full request and response payloads, which makes it a secrets surface to inspect.
• 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. Exfiltration needs an outbound call to an endpoint the attacker controls. In the Codecov case the altered script sent the environment to a third-party server.
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 a high-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. Anything executing there can reach all of them, which is why the Codecov compromise exposed customers' own credentials, including the key HashiCorp used to sign release hashes.

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. If agents are handed the pipeline's existing credentials, 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. GitHub Actions and GitLab CI/CD issue such tokens, and AWS, Microsoft Azure and Google Cloud accept them, so it usually needs no new tooling.

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.

Which CI/CD credential mistake should be removed first?

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 is easy to find in an inventory, and workload identity federation replaces it without new tooling.

Companies working on this: AI agent identity and access, AI agent security and governance, MCP and agent gateways. Each category lists sourced company profiles in alphabetical order; it is not a ranking. All categories: NHI market map.