AI-driven development is outpacing AppSec risk frameworks

At a glance

What this is: Apiiro’s executive panel argues that AI-driven development is accelerating code output and expanding the attack surface, while exposing limits in current AppSec review and risk prioritisation models.

Why it matters: This matters because identity, access, and governance controls must now cope with AI agents, automated code generation, and rapidly changing software assets that can outpace human review.

By the numbers:

• AI increases velocity by 4 times, but risk by 10 times in the panel discussion.
• AI is expanding the attack surface 10x, sometimes 100x, according to Armis CEO Yevgney Dibrov.
• 90% of the code used in projects is not owned by developers, according to Thomas Dohmke.

👉 Read Apiiro’s executive panel on AI-driven development risk and AppSec governance

Context

AI-driven development changes the unit of risk from a handful of controlled code changes to a much larger, faster-moving software supply chain. The first failure is usually not the model itself, but the governance process around it, because human review, ownership, and prioritisation assumptions were built for a slower development cadence. In identity terms, the same pressure applies to AI agents that can create, review, or deploy code without a stable accountability model.

The executive discussion from Apiiro frames this as an AppSec and governance problem rather than a tooling problem. Once code volume rises sharply, teams need context about what is actually exploitable, who owns the risk, and how AI-generated or AI-assisted changes are reviewed without freezing delivery. That starting position is increasingly typical in enterprises adopting AI at scale.

Key questions

Q: What breaks when AI agents can make code changes faster than humans can review them?

A: Manual review stops being a meaningful control if it cannot keep pace with change volume. Teams then miss unsafe dependencies, unintended privilege use, and subtle architecture drift. The failure is not only in code quality, but in the programme’s ability to detect and contain agent-driven mistakes before they reach production.

Q: Why does AI-assisted development complicate application security governance?

A: AI-assisted development complicates governance because the organisation must track who authorised the change, what system generated it, and whether the output can be audited. Without that chain of accountability, security teams can inspect the artefact but still fail to prove how it was produced or why it was allowed to ship.

Q: What do teams get wrong about securing AI coding assistants?

A: Teams often focus on code output and ignore the agent boundary, where file reads, tool outputs, and external content shape the next action. That misses the real control point. The right question is whether untrusted input can influence privileged behaviour before the code is even written or committed.

Q: How should organisations govern AI agents that can modify repository code?

A: They should treat the agent as a delegated non-human identity with tightly bounded authority. Separate instruction input from execution rights, require human approval for write actions, and log every agent-initiated change with enough context to support review. If the agent can edit code without that separation, prompt injection becomes a privilege escalation path.

Technical breakdown

How AI code generation changes the software attack surface

AI-assisted development does not just increase lines of code. It increases the number of repositories, dependencies, APIs, configuration paths, and ephemeral artefacts that can carry risk. Attack surface expands because each generated or modified component can introduce exposure, even when the code itself looks routine. The harder problem is context: organisations need to know which assets are externally reachable, which dependencies are trusted, and which AI-generated changes alter privilege or data flow. In practice, software architecture determines whether a new asset is noise or a material security issue.

Practical implication: prioritise exposure based on architecture and reachable trust boundaries, not raw code volume.

Why human code review breaks under AI-assisted delivery

Traditional AppSec processes assume developers write code at a pace that review, testing, and approval can absorb. AI changes that assumption by creating parallel streams of code generation, which makes human review the bottleneck. When review cannot keep pace, risk does not disappear. It migrates downstream into production, where defects become harder to catch and more expensive to fix. This is especially relevant where AI agents can generate changes continuously, because process controls designed for sequential work lose effectiveness when work becomes concurrent and iterative.

Practical implication: shift from review-only controls to prevention and automated policy enforcement earlier in the lifecycle.

Why AI accountability is becoming an access-governance problem

The panel points to a larger governance issue: AI systems are increasingly participating in tasks that used to be performed by named people. That means accountability, ownership, and access boundaries must be explicit even when the actor is a model, agent, or automated workflow. If an AI agent can create code, trigger tests, or influence deployment, it becomes part of the control plane and needs bounded authority. This is where application security intersects with IAM and NHI governance, because the question is no longer only what the code does, but what identity and privilege model governs the system producing it.

Practical implication: treat AI development agents as governed identities with explicit scope, logging, and approval boundaries.

Threat narrative

Attacker objective: The attacker aims to exploit the enlarged and less-governed software supply chain to reach production weaknesses faster than defenders can review or remediate them.

1. Entry occurs when AI-generated code, open source dependencies, or agent-driven workflows introduce unreviewed changes into the development pipeline.
2. Escalation follows when human review cannot keep pace, allowing insecure code paths, hidden dependencies, or excessive trust in automated outputs to persist into production.
3. Impact appears as a larger and more opaque attack surface, with more exploitable paths, weaker accountability, and a higher chance that vulnerabilities reach customers or internal systems.

NHI Mgmt Group analysis

AI-assisted development has created governance debt, not just productivity gain. Faster code generation matters, but the real security issue is that review, ownership, and prioritisation models were built for slower human-paced delivery. Once AI compresses the development cycle, the organisation inherits a backlog of unreviewed risk that traditional AppSec cadence cannot absorb. The practitioner conclusion is to treat AI velocity as a governance stress test, not a success metric.

Code review is no longer the primary control when AI can outpace human process. The panel is right that review breaks first, because it assumes sequential work and stable handoffs. That assumption collapses when developers, copilots, and autonomous agents generate changes in parallel. Security programmes need prevention at creation time, policy enforcement in the pipeline, and continuous validation after merge. The practitioner conclusion is to move control left and automate what human review can no longer cover.

AI development agents need an identity model, not just a workflow model. If agents can create, modify, or deploy code, they are participating in privileged technical actions and should be governed as non-human identities with bounded authority. This is where application security intersects directly with NHI governance, because access scope, traceability, and approval boundaries matter as much as the generated output. The practitioner conclusion is to define explicit identity and privilege boundaries for every AI system that can affect code or deployment.

Software exposure management is becoming the new control plane for application risk. The article’s strongest point is that organisations cannot prioritise what they cannot contextualise. Open source, APIs, data models, and AI-generated artefacts all expand the software estate, but only architecture tells you which exposures matter. This aligns with broader NIST-CSF and NIST SP 800-53 thinking on asset, access, and monitoring control. The practitioner conclusion is to prioritise exploitable exposure, not inventory size.

What this signals

AI governance now needs an identity layer for development automation. As AI systems take on more of the code lifecycle, enterprises will need to define who or what can author, approve, and deploy changes. That means treating some AI systems like governed technical identities, with explicit scope and auditability rather than informal tool usage. The organisations that separate generation from authority will have a clearer control model than those that collapse both into one workflow.

Velocity metrics are becoming a weak security signal unless they are paired with exposure context. Boards will keep asking for productivity gains, but practitioners should answer with risk-adjusted measures that show which AI-assisted changes actually increase exploitable surface. Context matters more than raw throughput. That is the practical shift for programmes trying to reconcile delivery pressure with control assurance.

For practitioners

• Map AI-assisted development paths end to end Identify where code is generated, reviewed, tested, approved, and deployed, then flag every point where an AI system can influence the path without named human accountability.
• Bound AI agents with explicit technical authority Assign each AI development agent a clear scope for repository access, build actions, and deployment influence, then log every privileged action as if it were performed by a service account.
• Shift from review dependence to prevention controls Add policy gates, secure-by-default templates, dependency controls, and automated checks before merge so that human review becomes a backstop rather than the primary safeguard.
• Prioritise exploitable exposure over raw code volume Use software architecture context to rank which AI-generated changes, libraries, APIs, and data models create real attack paths, then focus remediation on those paths first.

Key takeaways

• AI-assisted development is not only increasing output, it is stretching AppSec governance beyond the pace of human review.
• The most important failure mode is not AI code quality alone, but the collapse of sequential review and clear accountability.
• Security teams should govern AI development agents as bounded identities and move prevention earlier in the delivery lifecycle.

Key terms

• AI-assisted development: A development workflow where an AI system helps generate, refactor, test, or execute code inside the software delivery process. The security issue is not the assistance itself, but that the tool may operate in trusted contexts that also contain credentials, infrastructure access, and other sensitive assets.
• Attack Surface Expansion: Attack surface expansion is the growth in the number of reachable entry points, trust relationships, and exposed services that attackers can target. In modern applications, APIs, microservices, cloud services, and connected identities all add places where a vulnerability can become operationally important.
• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Software exposure management: The practice of identifying which software assets, dependencies, and code paths are actually exploitable, then prioritising remediation accordingly. For AI-driven delivery, it requires combining architecture context with access and trust analysis so teams focus on meaningful exposure, not just large inventories.

What's in the full article

Apiiro's full executive forum covers the operational detail this post intentionally leaves for the source:

• Panel-level discussion of how banking and enterprise risk frameworks break when AI accelerates code generation and review pressure rises
• Direct commentary from senior security leaders on accountable ownership for AI adoption across development and risk teams
• Specific guidance on how organizations can think about AI agents that write, review, and secure code in parallel
• Context from the executive forum on board-level reporting and the velocity-versus-risk tradeoff in AI coding adoption

👉 Apiiro’s full panel covers the risk framework breakdown, board reporting concerns, and AI agent accountability questions.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, secrets management, and workload identity. It helps practitioners who need to translate identity controls into governance for modern automation and AI-enabled delivery.