Agentic coding security is reshaping appsec and supply chains

At a glance

What this is: This is OXSecurity’s read on Gartner’s 2026 secure software engineering Hype Cycle, highlighting how agentic coding security, ASPM, and software supply chain security now converge around AI-written code and agent-driven workflows.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly have to govern software pipelines, model access, and tool delegation as identity-bearing attack surfaces rather than purely technical delivery systems.

👉 Read OXSecurity's analysis of Gartner's 2026 secure software engineering Hype Cycle

Context

Agentic coding security is the practical response to software being produced and modified by AI systems that can call tools, follow instructions, and generate output at runtime. That changes the control problem for application security, because the thing to secure is no longer only the finished code but the path the system takes to create it, including credentials, tool permissions, and third-party dependencies.

The identity intersection is real: AI agents that write code and invoke MCP-connected services behave like non-human identities in the delivery chain, with access rights, delegation paths, and provenance questions that traditional AppSec tooling does not model well. For identity and security programmes, this is the same governance problem seen in NHI sprawl, just expressed inside software engineering.

A useful reference point is the OWASP Non-Human Identity Top 10, which helps frame the control issues around secrets, privilege, rotation, and lifecycle management when machines act on behalf of teams. The starting position in this article is typical of the market: vendors are converging on the same control gap, but the operational model is still lagging the reality of AI-assisted software delivery.

Key questions

Q: How should security teams govern autonomous coding agents in software delivery pipelines?

A: Treat the agent, its sandbox, and its tool access as a single governed execution path. Require per-run identity, scoped credentials, signed triggers, and human approval before merge. The key is not to stop automation, but to ensure every autonomous action has a bounded lifecycle, a clear owner, and an auditable trail from trigger to release.

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: What do security teams get wrong about ASPM in agentic environments?

A: They often treat ASPM as a reporting layer instead of a decision layer. In agentic workflows, the problem is not finding more issues, but connecting findings to the context that determines business impact, ownership, and urgency. If posture data cannot drive prioritisation, the programme becomes noise management rather than risk management.

Q: What is the difference between software supply chain security and application security in agentic pipelines?

A: Application security focuses on weaknesses in the application and its runtime behaviour, while supply chain security focuses on the trustworthiness of what gets assembled into that application. In agentic pipelines, both matter because the system may consume code, models, tools, and credentials from multiple sources before outputting a build. One controls defects, the other controls provenance.

Technical breakdown

Why agentic coding creates a new attack surface

When an AI agent writes or modifies code, the security boundary expands beyond source files. The attack surface includes the instructions the agent receives, the tools it is allowed to call, the context it can read, the packages it pulls in, and the outputs it emits. Traditional scanners mostly inspect artefacts after the fact. They do not reliably govern the decision path that produced those artefacts, which is where prompt injection, tool abuse, and dependency poisoning enter the picture. In practice, secure software engineering now needs controls that observe and constrain the whole agent workflow, not just the final commit.

Practical implication: Security teams should treat agent prompts, tool permissions, and dependency provenance as first-class control points, not as developer convenience layers.

How ASPM changes security decision-making

Application Security Posture Management is best understood as the layer that turns fragmented findings into governance decisions. It correlates scanner results, runtime signals, pipeline telemetry, and policy context so teams can prioritise what actually changes risk. Without that connective layer, organisations accumulate more findings than they can action, which creates reporting noise rather than control. In an agentic environment, ASPM becomes more important because the number of code changes, dependency events, and policy exceptions rises faster than human review capacity. The value is less about detection alone and more about decision quality across the software lifecycle.

Practical implication: Teams should use ASPM to consolidate control signals into risk-ranked decisions tied to ownership, exposure, and remediation deadlines.

Why software supply chain security now includes model and MCP provenance

Software supply chain security used to focus on packages, builds, and signing. In agentic pipelines, the supply chain also includes the model source, the tools the agent can reach, and any MCP servers or external services that mediate actions. That widens the trust boundary considerably. A dependency may be technically clean but still introduce risk if the agent can use it in ways the organisation did not intend. Provenance therefore extends beyond code artefacts to the identity and authority of the components that influence generation and execution. The problem is not just vulnerable code, but unreviewed trust in the systems that help create it.

Practical implication: Govern provenance for models, tools, and MCP endpoints with the same seriousness as package signing and build integrity.

Threat narrative

Attacker objective: The attacker aims to influence code generation or delivery paths so that malicious logic, exposed secrets, or unsafe dependencies reach production with legitimate-looking provenance.

1. Entry occurs when an AI coding agent is granted access to prompts, repositories, packages, or external tools that shape code generation and execution.
2. Escalation follows when the agent can call MCP-connected services or inherited credentials that exceed the task scope originally intended by the team.
3. Impact emerges when unreviewed instructions, compromised dependencies, or malformed outputs propagate into production code and broader supply chain exposure.

NHI Mgmt Group analysis

Agentic coding security is now an identity governance problem, not just an AppSec problem. When code creation is delegated to systems that can call tools and access repositories, the control issue becomes who or what is authorised to act in the build path. That means NHI-style governance, including entitlement scope, credential lifecycle, and delegation boundaries, belongs in secure software engineering. The practical conclusion is that application security and identity security can no longer be managed as separate disciplines.

ASPM is becoming the control plane for software risk triage. The market is moving away from isolated finding generation and toward decision support across code, runtime, and pipeline context. That shift validates the need for a unified governance layer, but it also raises the bar for data quality, ownership mapping, and policy design. Security leaders should expect posture management to become the place where engineering trade-offs are negotiated, not just reported.

Supply chain provenance now needs to cover machines that make software decisions. Packages are only one part of the trust chain when models, MCP servers, and autonomous tools participate in delivery. The control gap is not simply vulnerable components but unaudited authority in the systems that assemble, transform, and deploy software. Practitioners should treat machine provenance as a board-relevant assurance issue, because the blast radius now extends from code to delegated action.

Tool delegation is the new least-privilege frontier. The article’s core message is that AI-assisted engineering makes over-permissioned tooling visible in the same way cloud sprawl once exposed over-permissioned workloads. If a coding agent can reach more systems than the task requires, then identity governance has failed before a vulnerability scanner ever runs. The conclusion for practitioners is to scope delegation as tightly as they scope production privilege.

What this signals

Agent-assisted development will force identity teams to participate earlier in software governance. As coding agents gain access to repositories, secrets, and deployment tooling, identity controls move upstream into engineering workflows. That means service-account governance, credential scope, and offboarding discipline will increasingly determine whether software delivery is auditable or opaque. The practical shift is from periodic review to continuous delegation control.

Machine provenance will become a standard assurance expectation. Security leaders should expect questions about where model outputs came from, which tools were used, and what authority the agent had to act. That aligns closely with OWASP Agentic AI Top 10 thinking and with broader software integrity programmes. The programme implication is clear: provenance evidence will need to be collected alongside build artefacts, not after incidents.

Software teams that already manage NHI lifecycle well will adapt faster. Organisations that know where their service accounts, API keys, and certificates live are better positioned to govern coding agents and MCP-based workflows. The relevant benchmark is whether those identities are inventoried, scoped, and retired in line with actual use. This is where the NHI lifecycle and secure software engineering agendas now intersect.

For practitioners

• Constrain agent tool access Map every coding agent to the minimum repository, package, and service permissions required for its task. Revoke broad tokens and avoid reusable credentials where the agent only needs ephemeral access to a single workflow stage.
• Introduce provenance checks for agent inputs Validate prompts, retrieved context, packages, model sources, and MCP endpoints before they influence code generation or execution. Treat unreviewed upstream content as a supply chain risk, not just a developer productivity issue.
• Correlate pipeline telemetry in ASPM Aggregate scanner output, build events, runtime signals, and policy exceptions in one posture view so teams can prioritise by exposure rather than by alert volume. Use that view to assign ownership and remediation deadlines.
• Apply lifecycle controls to non-human identities in delivery pipelines Inventory the service accounts, API keys, tokens, and certificates that support software delivery and rotate or retire them on a defined schedule. Pair that inventory with offboarding steps when tools, agents, or integrations are removed.

Key takeaways

• Agentic coding security changes application security by moving the control boundary from final code review to the full path of instructions, tools, execution, and outputs.
• ASPM is increasingly the layer that turns scattered findings into usable risk decisions, which becomes more important as AI-assisted delivery accelerates change volume.
• Software supply chain security now has to account for model provenance, MCP trust, and delegated machine authority, not just vulnerable packages.

Key terms

• Agentic Coding Security: The set of controls used to govern AI systems that write, modify, or assemble code. It covers the instructions, tools, permissions, and outputs involved in code generation, not only the finished source files. The goal is to prevent unsafe or unauthorised machine-driven changes from reaching production.
• Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Model Provenance: Model provenance is the evidence chain showing where an AI artefact came from, how it was modified, and whether the version in use is the one that was approved. For AI security teams, provenance is the control that turns trust from assumption into verification.

What's in the full article

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

• The exact three-category mapping from Gartner's Hype Cycle and how OXSecurity positions each category in relation to its own thesis.
• The vendor's layer-by-layer framing of agentic coding security across input, tools, execution, and output.
• The way OXSecurity connects ASPM signals to engineering decision-making and prioritisation.
• The supply chain implications the vendor associates with MCP servers, model provenance, and open-weight LLM dependencies.

👉 OXSecurity's full post expands the category mapping, control boundaries, and supply chain implications.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and machine identity security for teams building disciplined control models. It helps practitioners connect identity lifecycle controls to the broader security programmes their delivery pipelines depend on.