Achieving secure CI/CD with AI agents starts with using a non-human identity for every job. When AI agents run in a CI/CD pipeline, the ideal state is a short-lived, purpose-built non-human identity that is granted exactly the permissions needed for the specific build step, and the system logs every command, masks any secret data that appears in output, and requires a human approval before any risky operation. In that world the pipeline never relies on a static credential, there is no secret leakage, and auditors can trace who did what, when, and why.
In practice, most teams still use a handful of shared service accounts. Those accounts are hard-coded into build scripts, stored in secret managers, and rotated on a schedule that rarely matches the pace of development. The same credential is reused across dozens of jobs, across multiple repositories, and often across environments. When an AI agent is given that credential, it inherits every permission the account holds, regardless of the task at hand. The result is a blast radius that expands with each new pipeline addition, and a lack of visibility that makes post-mortems a guessing game.
Current practice: shared service accounts
Shared service accounts are attractive because they are simple to create and they work with any tool that expects a username and password or a static API key. Teams embed them in CI configuration files, reference them from secret stores, and grant them broad roles that cover all downstream resources. The downside is threefold:
- Over-privilege. A single credential can reach production databases, cloud resources, and internal services, even when the job only needs to push a Docker image.
- Lack of audit. When a build fails or a data leak occurs, there is no per-job log that ties the action to a specific identity.
- Credential churn. Rotating the account forces a coordinated update across every pipeline, which is error-prone and often delayed.
Because the credential travels directly from the CI runner to the target system, there is no place to inspect the traffic, enforce policies, or redact secrets that appear in command output.
Why non-human identity alone isn’t enough
Switching to non-human identity means issuing a unique OIDC or SAML token for each CI job, or for each AI-driven step. The token can be scoped to a specific role, and the identity provider can enforce short lifetimes. This eliminates the static secret, but it does not automatically give you the controls needed to manage risk:
- The CI job still connects straight to the database or cloud API. If the token is over-scoped, the agent can still perform destructive actions.
- There is no built-in mechanism to record the exact commands the AI agent runs, nor to mask sensitive fields that appear in logs.
- Approval workflows are missing; the pipeline proceeds without any human checkpoint, even for high-risk operations.
In other words, non-human identity fixes the credential problem but leaves the enforcement gap wide open. The request still reaches the target directly, and the pipeline retains full control without any observable guardrails.
Putting non-human identity on the access path
To close the gap, the identity-aware proxy must sit in the data path between the CI runner and the target system. That proxy inspects every protocol exchange, applies policy checks, and records the session for later replay. This is exactly what hoop.dev provides.