AI agents are changing software delivery and AppSec governance

At a glance

What this is: Checkmarx argues that AI agents are becoming part of software delivery itself, and that traditional AppSec controls no longer cover the speed and autonomy they introduce.

Why it matters: This matters because IAM, PAM, NHI, and agent governance teams need to treat AI agents as operating actors inside the delivery pipeline, not just as productivity tools.

By the numbers:

• Over 50% of respondents said they are currently using or actively planning to adopt generative or autonomous AI tools in Gartner's 2024 Software Engineering Leader survey cited by Checkmarx.

Context

AI agents are software entities that can plan, act, and adapt with limited human intervention, so they change the control problem from static review to continuous governance. In software delivery, that shift matters because the agent can participate in code creation, testing, dependency selection, and workflow execution before a human reviewer sees the result.

The governance gap is that many AppSec and DevSecOps controls still assume a human developer is the primary actor and that risk can be inspected after the fact. Once an agent can write, merge, and trigger tasks in near real time, the relevant question becomes who authorised the action, what scope the agent had, and how its behaviour was bounded.

For identity and access teams, the intersection is genuine: these agents operate like software identities with delegated capability, even when they are not framed that way in development tooling. That makes the article relevant to agent identity governance, not just application security.

Key questions

Q: What breaks when AI agents are given broad enterprise access without tight governance?

A: Broad access turns AI agents into high-speed execution paths that can move data, spend money, modify records, or delete assets before operators can intervene. The failure is not only misuse by an attacker. The system itself can exceed intended scope during normal task completion, so the real control problem is bounding authority before runtime action begins.

Q: How should security teams implement AI release governance in software delivery pipelines?

A: Start by making governance executable inside the release workflow, not in a separate document trail. Teams should classify AI changes, enforce policy gates, require role-based approvals, and capture evidence automatically as part of deployment. The goal is a release record that proves what was checked, who approved it, and why the change was allowed.

Q: How do teams know whether checkpoint controls for agentic AI are working?

A: They are working only if the most sensitive actions consistently pause for fresh human verification and cannot complete on ambient trust alone. A strong signal is that the workflow fails closed when the checkpoint is absent, while low-risk automation continues uninterrupted. If high-consequence actions still complete silently, the checkpoint is cosmetic rather than controlling.

Q: Why do autonomous AI agents create new AppSec risk in CI/CD workflows?

A: Autonomous agents compress code creation, testing, dependency selection, and execution into a single machine-driven sequence, so a bad instruction or unsafe dependency choice can propagate before a human review happens. The risk is not just faster mistakes. It is that the control point moves earlier, and many traditional AppSec checks are positioned too late to stop the decision that caused the issue.

Technical breakdown

Agentic AI in the SDLC: why release controls no longer assume a human actor

Agentic AI changes the software development life cycle because the system can move from recommendation to execution without waiting for a person to carry each step forward. In practice, that means code generation, test creation, dependency selection, and pipeline actions can all occur inside one operating sequence. Traditional AppSec often treats these as separated stages with review points in between. Agentic workflows compress those stages, so the control boundary shifts from post-change validation to pre-authorisation, runtime policy, and continuous monitoring. The architectural issue is not simply automation. It is that the actor making the change is now software with delegated intent, not a developer pausing for manual approval.

Practical implication: Treat agent actions as governed execution events and move approval, scope, and logging controls closer to the point where the agent acts.

Prompt injection, data leakage, and supply chain drift in agentic workflows

The main technical risk patterns in agentic software delivery are prompt injection, data leakage, supply chain drift, and uncontrolled resource consumption. Prompt injection manipulates the agent through malicious instructions embedded in input, while data leakage happens when generated output surfaces sensitive internal information. Supply chain drift appears when the agent selects unverified packages or dependencies because it optimises for task completion rather than trust. These risks are structurally different from ordinary developer mistakes because the agent can compound them at machine speed across many tasks. AppSec therefore has to watch not only the final artifact, but also the intermediate decisions the agent makes while assembling it.

Practical implication: Instrument agent inputs, dependency choices, and output paths so unsafe decisions are detectable before they propagate into builds or merges.

Policy-as-code and behaviour monitoring for AI agents

The control model for agentic AI in software delivery is converging on policy-as-code, real-time scanning, and behaviour monitoring. Policy-as-code turns security intent into executable rules that can act during merge requests, build steps, and other workflow boundaries. Behaviour monitoring looks for abnormal activity, model drift, or resource spikes that suggest the agent is acting outside its intended scope. This is important because a review process that happens after deployment is too late when an agent can generate and route changes continuously. For IAM and NHI teams, this is the same underlying governance problem seen in machine identity control: scope must be bounded at issuance and usage time, not only audited later.

Practical implication: Define explicit agent permissions, log every sensitive action, and enforce policy before the agent can complete a workflow step.

Threat narrative

Attacker objective: The objective is to influence software delivery outcomes through the agent so that insecure code, poisoned dependencies, or sensitive data reach downstream systems under the cover of automation.

1. Entry occurs when an agent receives a task or prompt that can be manipulated by malicious instructions, unverified dependencies, or overly broad workflow scope.
2. Credential or control abuse follows when the agent is allowed to act on repositories, build systems, or package sources beyond what the task truly requires.
3. Escalation occurs when the agent's output, dependency choices, or automated actions are accepted as trusted inputs by downstream delivery systems.
4. Impact is insecure code, data leakage, supply chain drift, or cost blowouts that propagate into staging or production before humans can contain them.

Breaches seen in the wild

• Fake Dependabot commits 2023: Stolen GitHub tokens were used to push fake Dependabot commits to hundreds of repos, adding workflows that stole Actions secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI has turned software delivery into an identity and governance problem, not just a tooling problem. When an agent can create code, tests, and workflow actions, the question is no longer whether the output looks valid. The question is what authority the agent had to produce it and what controls bounded that authority. For IAM and NHI teams, that is the same governance shift seen in machine identity programmes: access must be shaped around delegated capability, not assumed human oversight.

Prompt injection is only part of the story. The deeper problem is that agentic workflows collapse the distance between instruction, execution, and trust. That makes conventional AppSec checkpoints weaker because they often inspect artefacts after the risky decision has already happened. The right named concept here is agentic governance gap: the gap between what an organisation thinks it controls and what an autonomous workflow can actually do before review catches up. Practitioners should treat that gap as a design constraint, not an afterthought.

Security leaders should stop asking where AI fits into the existing workflow and start asking which controls fail once the workflow itself becomes autonomous. This is where the article intersects directly with identity governance. Agent permissions, task scope, and runtime monitoring now function like access governance for non-human actors. Teams that do not assign ownership for those controls will end up with shadow AI behaviour inside delivery pipelines.

The most durable response is not more post-build scanning. It is tighter authorisation, shorter task scope, stronger dependency trust, and continuous behaviour review at the point of action. That approach aligns better with how autonomous systems actually operate and gives security teams a control model they can enforce rather than merely observe.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Gartner predicts that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear value and insufficient risk controls.
• Read next: Agentic AI Identity Guide

What this signals

Agentic governance gap: the next control failure in software delivery will not be a missed patch but an over-trusted autonomous workflow. Security teams should expect AppSec, IAM, and platform engineering to converge on common policy enforcement points because agent behaviour cannot be governed effectively if it is reviewed only after the fact.

Agentic AI will force organisations to separate task authorisation from human identity in more explicit ways, especially where code generation, dependency selection, and release automation are involved. The most resilient programmes will treat agent permissions, monitoring, and revocation as part of the software supply chain, not as an adjacent security concern.

For practitioners

• Constrain agent authority to task-specific scope Limit each agent to the smallest repository, pipeline, package, or environment scope needed for the task. Avoid broad write access to delivery systems, and review every delegated action as if it were a software identity with a lifecycle.
• Move AppSec controls into the workflow Apply policy-as-code, merge-request checks, and build-time validation before an agent can complete code changes or dependency updates. Controls that only run after staging will miss the highest-risk automation paths.
• Monitor agent behaviour and dependency choices Log prompts, tool calls, package selections, and unusual resource spikes so you can detect prompt injection, supply chain drift, and denial-of-wallet patterns early. Treat behaviour telemetry as part of delivery governance, not as optional observability.
• Separate trusted human changes from agent-generated changes Tag and route agent-produced code, tests, and documentation through distinct review paths so human reviewers can apply different scrutiny to autonomous output than to manual commits. This reduces false trust in machine-generated artefacts.

Key takeaways

• AI agents are no longer just productivity helpers in software delivery. They can now become execution actors that change code, tests, dependencies, and release flows at machine speed.
• The main risk is not abstract AI hype. It is that prompt injection, data leakage, supply chain drift, and unsafe automation can spread through delivery pipelines before conventional AppSec controls catch up.
• The practical response is to shift governance into the workflow with scoped authority, policy-as-code, runtime monitoring, and separate treatment of agent-generated changes.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
• Software Supply Chain Drift: Software supply chain drift is the gradual move away from trusted, verified dependencies and build inputs toward unvetted or changing sources. In agentic delivery, it becomes riskier because autonomous systems may choose packages or services that satisfy the task but weaken trust.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security for practitioners building control around autonomous systems. It helps security, IAM, and platform teams align delegated access with operational reality.