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.
At a glance
What this is: Apiiro’s panel argues that AI-driven development is outpacing traditional AppSec gates, especially around inventory, ownership, and release control.
Why it matters: This matters because IAM and AppSec teams increasingly have to govern not only human developers but also AI-assisted workflows that change code, data flow, and approval boundaries faster than manual controls can track.
By the numbers:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
👉 Read Apiiro's analysis of AI-driven development and AppSec governance gaps
Context
AI-driven software delivery changes the governance problem before it changes the vulnerability count. When code, policy, and release decisions all move at machine speed, traditional AppSec models that depend on human review queues, manual ownership checks, and late-stage blocking lose effectiveness. The primary issue in this article is not whether AI can write code, but whether security teams can still see, classify, and control what is entering the software estate.
For IAM and NHI practitioners, the intersection is real even though the discussion is framed as AppSec: AI coding agents, embedded GenAI frameworks, and non-engineer-built workflows all create new identity, authorization, and provenance questions. That makes inventory, approval boundaries, and policy enforcement the practical bridge between application security and identity governance.
Key questions
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. Define what information can be sent to models, require human review of generated code, and apply least privilege to connected repositories and tools. Approved use cases should be explicit, monitored, and revisited as model capabilities expand.
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. The risk is not merely more code, but more unknown code paths, dependencies, and data flows reaching production before ownership and exposure are clear.
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. The more important control point is the moment the agent is allowed to initiate the action. If that step is not governed, testing becomes a detection layer rather than a prevention layer.
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.
Technical breakdown
Why AI-driven code generation breaks AppSec inventory models
AI coding agents can introduce code, libraries, and integration paths without the same human review trail that older AppSec processes assume. That matters because inventory is not just an asset list, it is the basis for knowing what changed, who owns it, and which controls should apply. When velocity increases, teams often see the change before they understand its scope, which turns release governance into a lagging process. The problem is not that AI always introduces flaws. The problem is that the change surface expands faster than classification and assignment can keep up.
Practical implication: security teams need inventory tied to code provenance and ownership, not just vulnerability scanning.
How prompt-speed SLAs change release governance
Traditional software release controls were built around hours or days of review. AI-assisted delivery compresses that into minutes or milliseconds, which means human approval gates can become the bottleneck and also the blind spot. If teams still expect developers to manually inspect every change in high-volume AI-assisted pipelines, they will either slow delivery to a halt or approve too much without context. The technical challenge is to move policy enforcement closer to the pipeline, where decisions can be automated consistently and exceptions can be logged.
Practical implication: enforce policy checks in CI/CD and treat release gating as a machine-enforced control point.
Why GenAI in products creates a separate attack surface
The article distinguishes between using AI to write code and embedding GenAI frameworks or agents inside the product itself. Those are different surfaces because the first changes how software is produced, while the second changes runtime behavior, data paths, and external dependencies. A GenAI framework can create new data egress routes, introduce version-specific exposure, and widen the set of systems that need governance. That is why inventory has to cover both development tooling and application runtime dependencies, not just one or the other.
Practical implication: track AI frameworks and agent dependencies as governed application components with explicit approval and review.
Threat narrative
Attacker objective: The objective is to exploit governance lag so risky code, integrations, or AI-driven workflows enter production before security teams can classify and stop them.
- Entry occurs when AI coding agents or non-engineer-built workflows introduce software changes, dependencies, or data connections faster than security teams can review them.
- Escalation happens when missing inventory and ownership allow those changes to reach sensitive code paths, data egress routes, or production systems without clear accountability.
- Impact follows when vulnerabilities, unsafe integrations, or uncontrolled AI use expand the attack surface and make remediation too slow to contain risk.
NHI Mgmt Group analysis
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.
Inventory is becoming the missing control plane for AI-assisted software delivery. If teams cannot identify what an agent introduced, they cannot assign ownership, assess exposure, or apply the right policy. This is a classic governance failure with a modern shape: change happens first, understanding comes later. The named concept here is AI inventory gap, and it is now a direct barrier to AppSec and IAM decision-making.
Identity governance now extends into software creation workflows. When AI agents, low-code builders, or non-engineers can create software that touches sensitive data, the boundary between application governance and identity governance disappears. Access scope, provenance, and approval authority become central to whether those workflows are acceptable. Teams that manage human identity well but ignore delegated AI-assisted creation will miss the operational risk.
Release blocking is losing value as a primary security strategy. The panel makes clear that blanket blocking at the end of the pipeline is no longer sustainable when change volume rises and development cycles shorten. Security teams need controls that are more selective, more contextual, and more automated. The practitioner conclusion is to redesign gates around risk triage and policy enforcement, not around universal stop buttons.
AI-assisted software governance will increasingly be measured by visibility, not intent. Good intentions, policy statements, and broad AI adoption goals do not prove control. The real test is whether teams can see the full software and identity surface, including where AI was used, what it changed, and who can approve it. That is where modern AppSec and NHI governance converge.
What this signals
AI inventory gap: the next governance failure will be inability to explain what an AI-assisted workflow changed, not just whether the change contained a vulnerability. Teams should expect requests for provenance, owner mapping, and approved framework inventories to become routine in assurance reviews.
The practical signal for programmes is that release governance will need to shift from broad blocking to context-aware policy enforcement. That means identity and access controls for AI-assisted workflows, plus traceability for who or what created the change, will matter more than end-stage review volume.
For practitioners
- 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. Capture both development-time and runtime components so change provenance is visible.
- 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.
- Separate AI coding risk from embedded AI runtime risk Treat AI used to generate code differently from GenAI features embedded into products, because each creates a different exposure model, review requirement, and control set.
Key takeaways
- AI-assisted development is compressing AppSec decision windows and exposing inventory gaps that traditional review models were never designed to handle.
- The most important control question is no longer whether code was written by a human or an agent, but whether teams can identify what changed, who owns it, and what policy allowed it.
- Practitioners should move governance into the pipeline, separate development-time and runtime AI risks, and treat provenance as a control requirement, not a documentation nicety.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0007;TA0008 — Discovery; Lateral Movement | AI-driven code changes create unseen paths that expand discovery and movement opportunities. |
| Recommendation — Map AI-assisted change paths to TA0007 and TA0008, then hunt for untracked dependencies and unexpected data flows. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorisations | The article centers on access boundaries, approval authority, and controlled release of software change. |
| Recommendation — Apply PR.AC-4 to enforce scoped approvals for AI-assisted workflows and product changes. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | AI tools and non-engineer builders need constrained authority over code, data, and production paths. |
| Recommendation — Use AC-6 to limit AI-assisted build and deployment permissions to the minimum required. | ||
| CIS Controls v8 | CIS-5 — Account Management | Ownership and accountability for AI-assisted software changes are central to the article's governance gap. |
| Recommendation — Apply CIS Control 5 to ensure every AI-assisted workflow has a named accountable owner. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The discussion is fundamentally about governance structures for AI use in software delivery. |
| Recommendation — Establish GOVERN controls for AI-assisted development and assign accountability for policy enforcement. | ||
Key terms
- AI Inventory: An AI inventory is a governed record of all AI-related assets, enriched with owner, purpose, access, and risk context. It turns discovery into something security, compliance, and IAM teams can use to make approval, review, and revocation decisions.
- Agent-Driven Change: Agent-driven change is a software modification created or materially shaped by an AI system that can act with partial independence in a development workflow. The security issue is not just speed, but the reduction in human traceability, which makes approval, audit, and remediation harder to enforce consistently.
- Release governance: The controls that decide who can publish software, under what approval conditions, and with what revocation path. For non-human identities, release governance is part of identity security because publishing credentials often have production-level impact even when they look like routine developer tools.
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
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern access control. It helps practitioners connect identity governance to the operational decisions that shape security programmes.
Published by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
