AI-native software engineering raises new control gaps for security

At a glance

What this is: This is an analysis of how AI-native software engineering changes the software security problem, with the key finding that agentic workflows expand the attack surface and accelerate the pace of risk introduction.

Why it matters: It matters because security, IAM, and PAM teams now have to govern not just human developers but also AI tools and agent-like workflows that can create, modify, and pass context across the SDLC.

By the numbers:

• AI code assistants are expected to be used by 90% of enterprise software engineers by 2028, up from less than 14% in early 2024.

👉 Read Veracode's analysis of the Gartner report on AI-native software engineering

Context

AI-native software engineering is the use of AI across design, coding, review, remediation, and delivery, not just as an assistant for drafting code. The governance gap is that these workflows can move faster than security review, especially when generated output is trusted before it is validated. In identity terms, that creates a new control problem around who or what is acting inside the development pipeline and under what authority.

Veracode’s article uses the Gartner report to argue that development is becoming more automated and more agentic at the same time. That combination matters for software security because it changes how code is produced, how fixes are approved, and how context is shared between tools. The starting position is increasingly typical across mature engineering organisations, not an edge case.

Key questions

Q: How should security teams govern AI-enabled workflows that can act on their own?

A: Treat them as identity-governed execution paths, not just software features. Assign a named owner, define least-privilege access, log every tool call, and require revocation paths for credentials and tokens. If the workflow can touch production systems or sensitive data, its permissions must be reviewed with the same discipline used for privileged machine identities.

Q: Why do AI native workflows create more identity risk than traditional engineering models?

A: AI native workflows increase identity risk because they multiply the number of identities and shorten the time access remains stable. When humans, services, and agents can all act in the same delivery flow, visibility and accountability become harder to preserve. The risk is not AI use itself, but access that outpaces governance.

Q: What do teams get wrong when they rely on human-in-the-loop controls for AI?

A: Teams often treat human-in-the-loop as a compliance checkbox, but the real test is whether the organisation understood the risk and placed controls around irreversible actions. A human review step helps only when it is tied to ownership, evidence, and a clear boundary for what the agent may do.

Q: How can teams reduce risk from AI-generated code in supply chains?

A: Teams should apply the same provenance and review expectations to AI-generated code as they do to third-party dependencies. That means verifying source, tightening review on generated changes, and blocking untrusted artifacts from reaching deployment. The goal is to prevent automation from scaling uncertainty faster than governance can absorb it.

Technical breakdown

Agentic workflows in the SDLC

Agentic workflows are development processes where AI systems can translate intent into actions, such as generating code, suggesting fixes, or moving work between tools. That changes the SDLC because the control plane is no longer only human review and CI policy. The security challenge is that context, permissions, and output quality can propagate across multiple steps before a person sees the result. In practice, this creates a blended identity problem: the human developer remains accountable, but the workflow itself behaves like a non-human actor with delegated influence.

Practical implication: define which AI actions are advisory only and which require explicit human approval before they can change code or configuration.

Software supply chain risk from AI-generated code

AI-generated code can introduce security defects, duplicate logic, or misconfiguration even when it appears syntactically correct. In supply chain terms, the issue is not just malicious insertion but unsafe acceleration, where vulnerable code moves from suggestion to production faster than conventional review can catch it. Multi-agent workflows increase that risk because one model’s output becomes another model’s input, compounding errors and weak assumptions. Security teams should treat AI-assisted development as a supply chain with new trust boundaries, not as a simple productivity feature.

Practical implication: extend SAST, SCA, and change-control gates to flag AI-originated code paths and high-risk configuration changes.

Why human-in-the-loop remains a control, not a slogan

Human-in-the-loop means a person retains the authority to review and approve security-relevant actions before they are finalised. In AI-native engineering, that matters because remediation suggestions and auto-fixes can be accurate in one context and dangerous in another. The core failure mode is blind trust in machine output without explainability or policy alignment. This is where identity governance intersects the engineering stack: delegated AI activity needs clear ownership, bounded scope, and traceability if the organisation wants to preserve accountability.

Practical implication: require approval checkpoints for security fixes, infrastructure changes, and policy exceptions generated by AI tooling.

Threat narrative

Attacker objective: The objective is to turn trusted AI-enabled development pathways into a faster route for introducing exploitable defects, misconfigurations, or downstream compromise.

1. Entry begins when AI-based tools are embedded into coding, review, and remediation workflows without sufficiently narrow permissions or validation gates.
2. Escalation occurs when generated code, fixes, or context are reused across agents and tools, amplifying errors and letting unsafe changes propagate faster than human review.
3. Impact follows when defective or misconfigured output reaches production, introducing vulnerabilities, operational instability, or supply chain exposure.

NHI Mgmt Group analysis

AI-native engineering creates governance debt before it creates productivity gain. The security programme now has to absorb faster code creation, faster remediation, and faster context transfer between tools. That means the control model must move from periodic review to continuous governance of machine-assisted change. Practitioners should treat the AI-native SDLC as an operational risk surface, not a productivity-only initiative.

Agentic workflows introduce a delegated-identity problem inside development pipelines. When an AI system can act, pass context, and trigger follow-on actions, it behaves like a bounded non-human participant in the engineering process. That makes identity and access control relevant even when the topic appears to be software security. The practical conclusion is that permissions, approvals, and traceability must extend to AI-driven steps as well as human ones.

Software supply chain controls now need to account for generated code, not just imported dependencies. Traditional supply chain thinking focuses on packages, libraries, and build integrity, but AI-native development can inject risk at the point of creation. That widens the scope of secure SDLC governance and makes provenance, review, and policy enforcement more important. Security leaders should assume that generation speed will outpace manual inspection unless the process is redesigned.

Human review remains essential because explainability is still a security control gap. The article correctly flags the danger of trusting outputs that cannot be fully explained or validated in context. In practice, explainability is not a nice-to-have feature for engineering teams, it is part of change assurance. The broader lesson is that organisations should not allow AI to collapse the accountability chain between recommendation and approval.

AI-native software engineering is now a control design problem, not a tool selection problem. The category question is no longer whether teams will use AI, but how they will prevent delegated workflows from bypassing policy, quality, and privilege boundaries. That is why identity governance, secure SDLC, and change control now intersect more tightly than they did in pre-agentic development. Practitioners should redesign controls around action, not just access.

What this signals

AI-native engineering will force security programmes to manage the identity of the workflow as much as the identity of the developer. That means permissions, approvals, and traceability need to follow machine-assisted actions across build, remediation, and deployment systems. For identity teams, the practical shift is toward policy that governs delegated action rather than assuming human review will catch every risky change.

Workflow trust collapse: when generated code, generated fixes, and generated context are all accepted without independent validation, the organisation loses the ability to prove where risk entered the pipeline. That problem sits close to NHI governance because AI systems increasingly behave like bounded non-human participants. Teams should align engineering controls with NIST Cybersecurity Framework 2.0 and, where identity assurance is relevant, NIST SP 800-63 Digital Identity Guidelines.

The next step for practitioners is to decide which AI actions are allowed to create lasting change and which remain recommendation-only. Once that boundary is explicit, security teams can instrument review checkpoints, provenance tracking, and approval records around it. This is also where the OWASP NHI Top 10 becomes useful as a risk lens for agentic workflows.

For practitioners

• Bound AI actions by workflow class Classify AI-assisted tasks into advisory, draft, and change-making categories, then require explicit approval for any action that can alter code, infrastructure, or policy. Tie those permissions to named owners so accountability does not diffuse across tools.
• Extend security gates to generated artefacts Apply SAST, SCA, configuration review, and policy checks to code and fixes produced by AI tools, not just human-authored changes. Block promotion when the output cannot be traced to a reviewable source or approved context.
• Track AI-originated change paths Tag commits, remediation actions, and configuration updates that originate from AI-assisted workflows so audit teams can reconstruct how a change was created and approved. This creates a usable trail for incident response and assurance reviews.
• Require validation for cross-agent context reuse Prevent one agent’s output from being accepted as trusted input by another agent unless the context has been validated against policy, source data, and intended scope. This is especially important in multi-agent remediation chains.
• Map AI workflow permissions to least privilege Limit each AI system to the narrowest set of repositories, build steps, secrets, and deployment functions required for its role. Review those entitlements as if they were non-human identities with production impact.

Key takeaways

• AI-native software engineering expands the security problem from reviewing code to governing machine-assisted change.
• The main risk is not AI itself, but the speed at which generated output can bypass context, review, and accountability.
• Security teams should redesign approval, provenance, and least-privilege controls around AI-enabled workflows, not just human developers.

Key terms

• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
• Human-in-the-Loop (HITL): A governance pattern requiring human approval before an AI agent takes high-impact, irreversible, or out-of-scope actions. HITL is a critical control for agentic AI identity governance.
• Software Supply Chain Risk: Software supply chain risk is the chance that code, build, deployment, or dependency paths are altered in ways that affect downstream systems. For AI code assistants, this risk rises when the tool can change source, trigger pipelines, or influence infrastructure definitions.

What's in the full article

Veracode's full article covers the strategic implications this post intentionally leaves for the source:

• How the Gartner report frames AI-native software engineering across the SDLC and why that changes security planning
• Veracode's own view of secure AI-assisted remediation and where human review sits in the workflow
• The article's discussion of developer productivity, agentic workflows, and the operational risks they create
• Context on how Veracode positions AI inside its SAST, DAST, and SCA remediation approach

👉 Veracode's full article covers the Gartner findings, AI-native workflow risks, and its secure development perspective

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and agentic AI identity. It is designed for practitioners who need to align identity controls with modern security and engineering programmes.