Notifications
Clear all
Topic starter
02/08/2026 9:41 am
TL;DR: AI coding assistants are now widely adopted, with 87% of organisations using tools such as GitHub Copilot, Cursor, or Claude Code to some extent and 53% of AppSec stakeholders seeing them as a moderate or significant risk, according to StackHawk. The real problem is not just code quality, but loss of developer context, overloaded review processes, and expanding attack surfaces that existing tooling cannot track at AI speed.
NHIMG editorial — based on content published by StackHawk: The Real Reason AppSec Can’t Keep Up With AI Development (It’s Not What You Think)
By the numbers:
- 87% of organizations have adopted tools like GitHub Copilot, Cursor, or Claude Code to some extent.
- 53% of respondents view AI coding assistants as a moderate or significant security risk.
- 71% cited alert fatigue as a moderate-to-critical challenge.
Questions worth separating out
Q: How should security teams govern AI experimentation without slowing delivery?
A: Use lane-based governance.
Q: Why does AI-assisted development create new AppSec failure modes?
A: AI-assisted development increases risk because it reduces the developer’s working context while expanding the number of paths that must be secured.
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
- Map application context before code volume grows further Build automated inventories of endpoints, data flows, and AI-enabled features directly from source and runtime telemetry so teams can still explain what the application does after AI-assisted changes land.
- Replace periodic validation with continuous runtime testing Use runtime checks to verify authorization behaviour, data segregation, and AI feature handling in the environments where applications actually execute, rather than relying on stale pre-release assumptions.
- Reduce triage load by prioritising business exposure Tune findings workflows so AppSec teams focus first on issues that affect reachable data, sensitive identities, or AI-enabled attack paths, instead of treating every alert as equal.
What's in the full article
StackHawk's full post covers the operational detail this post intentionally leaves for the source:
- Survey breakdowns on how 250+ AppSec stakeholders are actually adopting AI coding assistants
- Detailed discussion of where legacy DAST and manual review processes break under higher code velocity
- Specific examples of AI/LLM attack surfaces such as prompt injection and context poisoning
- The full guidance stack for building an intelligence-first AppSec programme around AI development
👉 Read StackHawk's analysis of why AppSec cannot keep up with AI development →
AI-assisted development: what it means for AppSec teams now?
Explore further
02/08/2026 12:35 pm
AI-assisted development creates a context governance problem, not just a code quality problem. The security failure is often the shrinking gap between feature creation and the point at which anyone can still explain how the feature should behave. That gap weakens access logic, data-flow assurance, and review quality across both human and non-human workflows. Practitioners should treat software context as a governance asset, not an incidental by-product.
A question worth separating out:
Q: How can AppSec teams tell whether their controls are keeping pace with AI delivery?
A: Look for signals such as shrinking triage backlog, faster validation cycles, and a complete inventory of AI-enabled features, endpoints, and data flows. If the team can explain the security impact of a new release before it reaches production, the control plane is keeping pace. If not, the programme is already behind.
👉 Read our full editorial: AI-assisted development is breaking AppSec velocity and context
