Why do coding agents increase NHI risk in repositories and CI/CD pipelines?

Why This Matters for Security Teams

Coding agents compress multiple risky capabilities into one runtime identity: they can read repositories, inspect secrets, edit code, trigger CI jobs, and sometimes push deployment changes. That makes the attack path much shorter than in a human workflow, because the same credential can cross boundaries that were meant to be separated. Current guidance from the OWASP Agentic AI Top 10 and NHI research from Top 10 NHI Issues both point to the same problem: over-scoped identities become dangerous when the workload is autonomous.

The risk is not only accidental misuse. A coding agent operating with a broad token can be induced to exfiltrate secrets, alter build logic, or create a backdoored dependency path without ever crossing a traditional perimeter. The issue is compounded in repositories and pipelines because those environments already contain high-value material such as source code, signing keys, environment variables, and release privileges. In practice, many security teams encounter this only after the agent has already been trusted with too much access, rather than through intentional task-scoped design.

How It Works in Practice

The core control problem is identity scope. A coding agent should not be treated like a generic developer account with long-lived access. It should be treated as a workload with narrow, task-based authority. That means the agent needs a workload identity that can be verified at runtime, plus policy that decides what it may do based on the specific request, the repository context, and the environment state. Frameworks such as the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework both support runtime governance instead of static trust.

Practically, that translates into a few patterns:

• Issue just-in-time, short-lived credentials per task, not reusable tokens for the whole agent session.
• Bind the agent to workload identity, not a shared service account, so each execution can be traced and constrained.
• Separate read, write, and deploy permissions, and revoke the ability to chain them unless a policy explicitly allows it.
• Keep secrets in a manager and inject them only when needed, rather than leaving them in the repository or CI environment.
• Evaluate authorization at request time so the agent cannot assume yesterday’s permissions still apply today.

That approach lines up with NHIMG research on the Guide to the Secret Sprawl Challenge, which shows how often secrets leak into code and CI/CD tooling. It also reflects real-world incidents such as the Reviewdog GitHub Action supply chain attack, where pipeline trust became the weakness. These controls tend to break down when the agent is allowed to operate across multiple repositories and deployment environments with one persistent credential, because the blast radius becomes impossible to contain.

Common Variations and Edge Cases

Tighter agent controls often increase operational overhead, requiring organisations to balance speed of coding assistance against release friction and policy complexity. That tradeoff becomes sharper in fast-moving CI/CD environments, where teams want the agent to open pull requests, run tests, and prepare releases without blocking developers. Current guidance suggests that this is where the boundary between productivity and exposure has to be enforced deliberately, not assumed.

There is no universal standard for this yet, but several edge cases are clear. Agents that only lint or generate boilerplate still need constrained access if they can reach package registries, build secrets, or deployment metadata. Multi-agent workflows raise the stakes further because one agent may hand off artifacts to another, multiplying trust relationships. In repositories that contain infrastructure-as-code, a single prompt can trigger changes that affect clusters, cloud permissions, and production pipelines. That is why NHIMG’s Amazon Q AI Coding Agent Compromised analysis is relevant: if an agent can be socially engineered or prompt-injected into unsafe actions, the identity issue becomes an execution issue as well.

Security teams should also watch for exceptions such as shared runners, cached credentials, and delegated bot accounts, because those often undermine otherwise sound policy. The best practice is evolving toward ephemeral trust, explicit task scoping, and continuous review of what the agent can reach, not just what it is supposed to do.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents increase non-human identity risk?
• Why do CI/CD pipelines increase lateral movement risk?
• Why do private container images increase NHI risk in CI/CD environments?