Notifications
Clear all
Topic starter
14/09/2026 10:10 am
TL;DR: AI-driven development is compressing the time available for review, ownership, and release gating, while source control inventory and vulnerability triage are lagging behind, according to Apiiro’s panel discussion with leaders from GitHub, Apiiro, and Akamai. The practical shift is from blocking defects late to governing agent-driven change earlier, because velocity now outpaces traditional AppSec controls.
NHIMG editorial — based on content published by Apiiro: AI-driven development is straining application security frameworks
By the numbers:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
Questions worth separating out
Q: How should security teams govern AI use in developer tooling?
A: Security teams should govern AI use as a data and access problem, not only a productivity feature.
Q: Why does AI-driven coding increase application security risk even when it improves productivity?
A: Because productivity gains increase change volume faster than teams can classify and review the resulting software.
Q: What do security teams get wrong about AI-generated code risk?
A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows.
Practitioner guidance
- Inventory AI-assisted code paths and dependencies Map where AI coding agents, GenAI frameworks, and low-code tools are being used, then tie each to an owner, approval path, and release boundary.
- Move policy enforcement into the delivery pipeline Apply automated checks for code owners, vulnerability thresholds, approved framework versions, and data egress rules inside CI/CD rather than relying on end-stage manual review.
- Define ownership for AI-created or AI-modified software Require a named accountable owner for every AI-assisted workflow that can change code or connect to sensitive data, including cases built outside engineering by business teams.
What's in the full article
Apiiro's full analysis covers the operational detail this post intentionally leaves for the source:
- Panel-level commentary on how CISOs are reprioritising AppSec and supply chain risk under AI-driven development
- Direct quotations on how teams are using AI for ownership, architecture understanding, and release governance
- Discussion of internal policy enforcement patterns for allowed GenAI frameworks and versions
- Examples of how non-engineering teams are being allowed to build software under the same governance controls
👉 Read Apiiro's analysis of AI-driven development and AppSec governance gaps →
AI-driven development: what it means for AppSec teams now?
Explore further
14/09/2026 10:11 am
AI-driven development is creating a governance debt problem, not just a productivity problem. The article shows that faster coding does not eliminate control requirements, it compresses the time available to satisfy them. That shifts the security burden from late review to earlier policy enforcement, ownership assignment, and runtime accountability. Practitioners should treat this as a control design issue, not a developer training issue alone.
A question worth separating out:
Q: How can organisations tell whether AI governance is working?
A: They should look for continuous discovery coverage, real-time classification decisions, and evidence that prompts and responses are being inspected during the session. If controls only appear in policy documents or periodic reviews, the programme is tracking intent rather than control performance. Working governance leaves an operational trail, not just a compliance statement.
👉 Read our full editorial: AI-driven development is exposing AppSec governance gaps
