Notifications
Clear all
Topic starter
02/08/2026 9:43 am
TL;DR: GenAI and LLM-assisted development can accelerate delivery while also importing vulnerable patterns, according to StackHawk, and runtime testing becomes more important because static analysis alone cannot observe non-deterministic outputs or prompt-driven behaviour. The governance problem is no longer whether AI can write code, but whether security teams can verify what that code does before production.
NHIMG editorial — based on content published by StackHawk: Secure Code in the Age of AI: Challenges and Solutions
By the numbers:
- 77% of respondents said AI tools improve code security, while 59% are concerned that LLM-trained tools will introduce vulnerabilities that appeared in the training code.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope.
Questions worth separating out
Q: How should security teams govern AI-generated code in production environments?
A: Security teams should treat AI-generated code as normal production code with extra provenance risk.
Q: Why does AI-assisted development increase security risk even when developers use familiar controls?
A: Because familiar controls often assume code behaves predictably, while LLM-influenced systems can vary by prompt, context, and input shape.
Q: What do security teams get wrong about AI safety testing?
A: The common mistake is treating AI safety testing as if it were just another security scan.
Practitioner guidance
- Expand DAST coverage for AI-influenced applications Add runtime tests for endpoints that accept prompts, generate responses, or call model-backed APIs, and vary payloads enough to surface non-deterministic behaviour.
- Review identity and secret handling in AI pipelines Inventory API keys, service accounts, and tokens used by AI-assisted workflows, then verify that they are scoped tightly and not embedded in generated code or copied examples.
- Map AI application risks to OWASP LLM controls Use the OWASP Agentic AI Top 10 and related LLM risk guidance to check for prompt injection, unsafe output handling, and over-trusted model responses.
What's in the full article
StackHawk's full article covers the operational detail this post intentionally leaves for the source:
- How its DAST approach tests AI-generated APIs at runtime, including input variation and output validation patterns.
- Why the article argues SAST alone is insufficient for non-deterministic LLM behaviour in production workflows.
- The specific ways the article connects OWASP LLM risks to runtime security testing across the SDLC.
- How StackHawk frames secure code testing inside CI/CD for teams adopting generative AI.
👉 Read StackHawk's analysis of secure code testing in the age of AI →
AI-generated code and LLM APIs: are your controls keeping up?
Explore further
02/08/2026 12:36 pm
Runtime verification is becoming the control plane for AI-assisted development. Static review still matters, but it cannot prove how LLM-influenced code behaves once prompts, inputs, and integrations are live. That shifts security assurance toward DAST, repeated test inputs, and runtime observation. For practitioners, the key conclusion is that safe AI-assisted delivery depends on behaviour validation, not code appearance alone.
A question worth separating out:
Q: Should organisations treat AI-generated code as a separate governance category?
A: Yes, because AI-generated code introduces a trust problem that sits between development, application security, and identity governance. Teams need policy for what AI may generate, how outputs are validated, and how identities and secrets are handled in the resulting code. Without that, responsibility for unsafe behaviour becomes fragmented across teams.
👉 Read our full editorial: AI-generated code needs runtime testing, not static trust alone
