Notifications
Clear all
Topic starter
19/08/2026 3:56 pm
TL;DR: Generative AI is widening application attack surface faster than AppSec tooling can track, with 890% growth in GenAI traffic, 250% growth in data-loss incidents, and 80% of organisations shipping vulnerable AI-assisted code, according to Apiiro, Palo Alto Networks, and Checkmarx/Jit.io. The real issue is not code volume alone but loss of context across prompts, models, dependencies, and runtime behaviour.
NHIMG editorial — based on content published by Apiiro: generative AI security and the hidden risks in application development
By the numbers:
- According to Palo Alto Networks, there was an 890% surge in generative AI traffic in 2024, showing how quickly AI-assisted development has become embedded in the software ecosystem.
- GenAI data loss incidents increased by 250% in early 2025 and now account for 14% of all data security incidents across SaaS traffic.
- A joint study by Checkmarx and Jit.io found that 80% of organisations using AI coding assistants ship vulnerable code, including missing authentication checks and unsafe defaults.
Questions worth separating out
Q: How should security teams govern AI experimentation without slowing delivery?
A: Use lane-based governance.
Q: Why do AI coding assistants still produce insecure code?
A: They learn patterns from large code corpora that contain both secure and insecure examples, and they do not reliably reason about all dataflow or trust-boundary issues.
Q: What breaks when organisations cannot inventory their AI credentials?
A: Rotation, recertification, and offboarding all break down when the inventory is incomplete.
Practitioner guidance
- Inventory all AI-assisted development paths Map every approved and unapproved model, coding assistant, plugin, and embedded framework to the repos and services it touches.
- Add AI-specific review gates to SDLC workflows Require extra review when code is generated by assistants, when prompts can influence tool calls, or when a change introduces a model endpoint, external API, or unvetted package.
- Link source changes to runtime behaviour Correlate commits, model versions, and AI tool activity with runtime telemetry so teams can see which AI-generated change affected which asset or data flow.
What's in the full article
Apiiro's full article covers the operational detail this post intentionally leaves for the source:
- Concrete examples of how AI-generated code bypasses conventional AppSec review paths
- Detailed discussion of prompt injection, data poisoning, and insecure output handling in development workflows
- Practical workflow patterns for runtime monitoring and code-to-runtime correlation
- Implementation detail on AI-SPM style visibility and validation across models, code, and data
👉 Read Apiiro's analysis of generative AI security and the AppSec blind spot →
Generative AI security: where are AppSec controls falling behind?
Explore further
19/08/2026 4:34 pm
Generative AI has turned application security into a prompt-to-runtime governance problem. The security boundary has shifted upstream from commit and build into prompt construction, model configuration, and tool delegation. That means teams can no longer treat AI-assisted code as a downstream scanning issue. The relevant control model now spans architecture, policy, and runtime telemetry, not just source analysis. Practitioners should govern AI systems as part of the SDLC itself, not as a separate innovation layer.
A question worth separating out:
Q: How can security teams tell whether AI-generated code is actually safe?
A: They should look for security regression evidence, not just test pass rates. A codebase is safer only when the agent’s output survives threat-informed checks, review of privileged paths, and validation against the vulnerability classes most likely to recur in that repository.
👉 Read our full editorial: Generative AI security is exposing a new AppSec attack surface
