Topic starter
02/08/2026 9:42 am
TL;DR: LLM applications introduce attack surfaces that traditional AppSec was not designed to handle, from prompt injection and sensitive information disclosure to excessive agency and vector database abuse, according to StackHawk’s analysis of the OWASP Top 10 for LLM Applications. The governance problem is no longer whether AI is in production, but whether security teams can control inputs, outputs, context, and delegated actions as systems become more autonomous.
Editorial analysis by NHI Mgmt Group, based on content published by StackHawk: “Understanding LLM Security Risks: OWASP Top 10 for LLMs (2025)”.
Key questions
Q: What breaks when LLM security is enforced only in the application layer?
A: Alternate routes bypass the controls.
A: Start by limiting what the model can do, not just what it can say.
Q: How can security teams tell whether LLM evaluation is actually working?
A: Look for continuous coverage across live traffic, regression testing on new prompts or models, and sampled human review of judge outputs.
Practitioner guidance
- Define separate trust boundaries for prompts, outputs, and tool calls Do not treat model input validation as coverage for everything the system does.
- Remove secrets and sensitive terms from system prompts System prompts are not secure storage.
- Restrict model access to downstream tools by task and scope Grant the model only the minimum set of actions needed for a specific workflow, and require approval for any operation that can send data, change state, or touch production systems.
Bottom line: LLM applications fail in places where conventional AppSec assumptions stop holding, especially around prompt trust, output trust, and delegated action paths.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:36 pm
LLM security debt is now a governance problem, not a feature problem. The article shows that LLM risk spans prompt injection, retrieval layers, output handling, and delegated tool use, which means the security boundary is no longer the app alone. Traditional AppSec assumes predictable logic, while LLM systems operate on probabilistic behaviour and external context. Practitioners should treat model governance as part of the control stack, not as an experiment layered on top.
A few things that frame the scale:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: Should organisations prioritise retrieval isolation or output filtering first for LLM security?
A: Prioritise retrieval isolation when the model can access sensitive sources or shared vector stores, because exposed context can undermine every later control. Output filtering still matters, but if the model sees the wrong data in the first place, downstream sanitisation cannot fully recover the boundary.
👉 Read our full editorial: OWASP Top 10 for LLMs exposes where appsec breaks