Notifications
Clear all
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.
NHIMG editorial — based on content published by StackHawk: Understanding LLM Security Risks: OWASP Top 10 for LLMs (2025)
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when an LLM can act without strict permission boundaries?
A: The main failure is that the model starts behaving like an over-privileged service account.
Q: Why do NHIs complicate zero trust and least privilege efforts?
A: NHIs complicate zero trust because they are numerous, persistent, and often tightly integrated into applications and pipelines.
Q: How do security teams know whether an LLM is operating safely?
A: Look for evidence that the model’s read scope, tool scope, and output handling are all bounded and reviewed.
Practitioner guidance
- Classify every LLM as a privileged runtime Inventory each production model, the data it can read, the tools it can call, and the accounts or API keys behind those actions.
- Segment prompts, retrieval, and tool execution Do not let the same trust boundary cover system prompts, vector stores, and action endpoints.
- Add approval gates for non-read actions Require human approval or step-up authorisation before the model can send messages, modify records, execute code, or trigger external workflows.
What's in the full article
StackHawk's full blog covers the operational detail this post intentionally leaves for the source:
- Expanded examples for each OWASP risk category, including prompt injection, system prompt leakage, and vector store weaknesses
- Implementation context for output validation, rate limiting, and access controls in AI-enabled application workflows
- Practical security guidance for teams building LLM features into existing applications and delivery pipelines
- Examples of how AI gateways and model-adjacent controls fit into broader AppSec practice
👉 Read StackHawk's OWASP Top 10 for LLM security risks analysis →
LLM security risks in 2025: are your controls keeping up?
Explore further
02/08/2026 12:36 pm
LLM security is now an identity governance problem as much as an application security problem. Once a model can read context and invoke tools, it behaves like a software entity with delegated privileges. That shifts the control question from "is the model safe" to "what can this identity do, for how long, and under what conditions." Security teams need to align AppSec with IAM, PAM, and secrets governance because the model cannot be separated from the permissions it uses.
A question worth separating out:
Q: Should organisations allow AI agents to use production credentials?
A: Only if those credentials are task-scoped, closely monitored, and revocable without affecting unrelated systems. In most cases, production credentials create unnecessary blast radius. A safer pattern is short-lived access, explicit approvals for non-read actions, and strong separation between agent identity and human privilege.
👉 Read our full editorial: OWASP Top 10 for LLMs exposes where appsec breaks
