Securing AI coding agents across development, repo, and CI/CD

At a glance

What this is: This analysis shows that AI coding agents extend risk across the full software delivery chain, with distinct exposure points in development environments, repositories, and CI/CD pipelines.

Why it matters: It matters to IAM, PAM, and security teams because the same agent can touch credentials, packages, and privileged pipeline contexts without the controls that normally govern human access.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read StepSecurity's analysis of securing AI coding agents across the development lifecycle

Context

AI coding agents are software systems that can install packages, create pull requests, push commits, and interact with tools inside development pipelines. The security problem is that these systems operate with access to credentials and execution paths that were historically controlled through human review and segmented tooling.

For IAM and PAM teams, the relevance is direct: these agents often inherit standing access, invoke APIs, and move between development, repository, and CI/CD environments without clear lifecycle governance. That makes them a non-human identity governance problem as much as a software supply chain problem.

The article's starting position is increasingly typical, not exceptional. As agentic coding tools become embedded in engineering workflows, the security baseline has to shift from code output review to control over identity, privilege, and runtime behaviour.

Key questions

Q: What breaks when an AI review system has write access to repositories and pipelines?

A: The boundary between detection and execution breaks. If the same identity can inspect code and change code, a compromise can become a direct route to backdoors, unsafe builds, or unauthorized deployments. That is why review tools with write access must be treated as governed NHIs with tight separation of duties.

Q: Why do AI coding agents increase supply-chain risk?

A: AI coding agents can choose tooling, install packages, and edit lock files in ways that may bypass the controls humans expect in a managed environment. That widens the blind spot around untracked software and makes package provenance harder to enforce. The practical response is to restrict agent permissions, inventory their workspaces, and review their install behaviour like any other privileged automation.

Q: How do security teams know if an AI agent is operating outside its approved role?

A: Teams should compare actual workflow behaviour against the approved use case. Signs of trouble include unexpected record access, unapproved action types, new system paths after an update, or repeated attempts to exceed the intended scope. In healthcare, behaviour review matters as much as entitlement review because unsafe actions often appear first as workflow drift.

Q: Who is accountable when leaked AI agent code leads to downstream abuse?

A: Accountability usually sits with the organisation operating the agent stack, the team that approved the release path, and the owners of telemetry and access controls. Under AI governance and security frameworks, the question is not only who made the error, but who owns provenance, review, and containment once the leak is public.

Technical breakdown

How AI coding agents expand the development attack surface

AI coding agents do not stay in one control plane. They can read prompts, resolve dependencies, invoke local tools, and take actions across developer machines and ephemeral environments. That means the same system may touch SSH keys, cloud tokens, package registries, and source repositories in a single workflow. The architectural risk is not just malicious code generation. It is the agent's access to trusted tools and identities while it operates with little or no session-level scrutiny. In identity terms, the agent becomes a privileged runtime actor that can inherit, use, and propagate credentials faster than traditional review processes can inspect them.

Practical implication: treat coding agents as governed identities with explicit tool boundaries, not as harmless productivity extensions.

Why repository-level package risk is amplified by agentic workflows

Agentic development increases supply chain exposure because dependency selection becomes automated and task-driven. An AI coding agent may choose packages based on functionality, not provenance, freshness, or organisational allowlisting. That creates a weak point where a malicious or newly published dependency can enter through pull requests before a human reviewer notices the risk. The problem is compounded when organisations assume repository controls alone are enough. In practice, the repository is only one checkpoint in a broader chain that now includes agent behaviour, package reputation, and organisation-wide exposure tracking.

Practical implication: pair package controls with org-wide exposure search and pre-merge blocking for risky dependencies.

What runtime visibility must exist in CI/CD pipelines

CI/CD pipelines are particularly sensitive because they often hold production secrets and deployment privileges. When coding agents run inside GitHub Actions or similar systems, they can spawn processes, make outbound calls, and interact with APIs in ways that standard endpoint tools do not see. Runtime visibility therefore has to include network events, process attribution, and policy enforcement at the workflow level. Without that layer, an agent can exfiltrate data or widen blast radius before a security team can reconstruct what happened. The underlying issue is observability of non-human action in a privileged execution environment.

Practical implication: instrument CI/CD with workflow-aware runtime controls that can block unauthorized egress and attribute each action.

Threat narrative

Attacker objective: The attacker wants to turn a trusted development workflow into a credential, supply chain, or release-path compromise that reaches production.

1. Entry occurs when an AI coding agent runs on a developer machine or inside an ephemeral environment with access to credentials, source code, and external tools.
2. Escalation happens when the agent installs packages, loads extensions, or interacts with MCP servers that can influence behaviour or expose secrets.
3. Impact follows when compromised credentials or malicious dependencies reach the repository or CI/CD pipeline and are used to publish, deploy, or exfiltrate at scale.

NHI Mgmt Group analysis

AI coding agents should be governed as non-human identities, not treated as code-generation tools. Once an agent can install packages, push commits, and act inside CI/CD, it inherits the governance problems that apply to service accounts and workload identities. The control question becomes who or what is authorised to act, with which tools, and under what boundary conditions. Practitioners should align agent governance with OWASP-NHI and NIST-CSF thinking, because the identity layer is now part of the software delivery threat model.

End-to-end visibility is now the deciding control for agentic development security. Point solutions that only scan code output or only watch endpoints miss the chain of action that links developer context to repository changes and pipeline execution. The new failure mode is stage fragmentation, where one control plane assumes another will catch the abuse. Practitioners should design for correlated visibility across development, source control, and CI/CD, not isolated detection.

Package reputation is no longer enough when the actor choosing the dependency is autonomous. Task-driven dependency resolution shifts the risk from what is available to what the agent is likely to select under time pressure. That creates what can be called dependency selection drift: the agent optimises for function while governance expects provenance discipline. Practitioners should require pre-approved dependency paths and org-wide exposure tracing for any agentic workflow that touches packages.

CI/CD privilege is the highest-value stage because it collapses identity, runtime, and release authority into one surface. If a coding agent can run inside a privileged workflow, the environment itself becomes a high-trust execution zone that must be continuously monitored. This is where agentic AI and PAM intersect most sharply: short-lived task access is not enough if the workflow can still spawn uncontrolled actions. Practitioners should treat pipeline runtime controls as mandatory security infrastructure, not optional telemetry.

Stage-boundary attacks are the category shift the market has not fully absorbed. The article shows that secure AI coding cannot be solved by IDE controls alone, because the attack path crosses development, repository, and pipeline domains. That validates a broader governance model in which identity, supply chain, and runtime controls are evaluated together. Practitioners should reassess any tool strategy that assumes a single-layer control can protect the full lifecycle.

What this signals

Dependency selection drift: agentic development shifts the security problem from approved code changes to unreviewed runtime choices, which means governance has to follow the agent, not just the repository. Teams that only monitor pull requests will miss the behaviour that happens before a commit exists.

The strongest next step is to unify identity, supply chain, and pipeline controls so that a coding agent cannot move from prompt to production without policy checks at each stage. That is a Zero Trust problem as much as a software engineering problem, and it should be measured in blocked actions, not just detected alerts.

For practitioners

• Define agent identities and tool scopes Create explicit registration, ownership, and tool-allowance policies for every AI coding agent. Bind each agent to a named workflow or team, then restrict access to the minimum packages, repositories, and APIs it actually needs.
• Block risky dependency introduction before merge Require org-wide package allowlists, cooldown rules for newly published packages, and automated pull request blocking when an agent introduces an unfamiliar dependency into a repository.
• Instrument CI/CD for runtime attribution Monitor workflow process creation, outbound network activity, and file events so that every action can be traced back to the exact step and process that triggered it.
• Enforce egress controls on privileged runners Apply DNS, HTTPS, and network-layer blocking on CI/CD jobs that can reach production secrets, and keep unauthorized outbound traffic out of release workflows.
• Track organisation-wide exposure from AI-driven changes Search across repositories, pull requests, and developer machines when an agent introduces a package or when a supply chain alert appears, so incident response starts from exposure scope rather than guesswork.

Key takeaways

• AI coding agents create a multi-stage identity and supply chain problem because they can act across developer environments, repositories, and CI/CD pipelines.
• The most credible evidence points to hidden secret exposure, runtime opacity, and dependency abuse as the practical failure modes teams need to address.
• Security programmes should govern agent identity, package introduction, and workflow runtime together rather than relying on any single layer of control.

Key terms

• AI Coding Agent Governance: The rules and oversight structures that define what a coding agent may do, why it may do it, and who is accountable for the outcome. It sits above security tooling and focuses on delegation, approval, auditability, and rollback rather than threat prevention alone.
• Dependency Drift: Dependency drift is the ongoing change in a vendor ecosystem as subcontractors, hosting layers, software components, and access paths evolve. It creates governance lag when assessment data is captured periodically but the real environment changes continuously between reviews.
• CI/CD Runtime Visibility: The ability to observe what processes, network calls, and file events occur during a build or deployment job. It is a control requirement for agentic workflows because security teams need to attribute action to a specific step or process, not just inspect final output.
• Stage-Boundary Attack: An attack that moves across more than one part of the software delivery chain, such as developer environment, repository, and pipeline. These attacks are hard to stop with single-point controls because the initial compromise can happen in one stage and the impact appear in another.

What's in the full article

StepSecurity's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for securing AI coding agents on developer machines and ephemeral environments.
• Workflow-level controls for GitHub Actions, including process tracing, network enforcement, and runtime attribution.
• Package governance techniques for blocking suspicious npm dependencies before they reach production workflows.
• Practical integration notes for Claude Code, Gemini, and GitHub Copilot inside CI/CD pipelines.

👉 The full StepSecurity post covers stage-by-stage controls for developer machines, repositories, and CI/CD pipelines.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme that governs access, privilege, and lifecycle.