Notifications
Clear all
Topic starter
06/09/2026 9:01 am
TL;DR: OWASP LLM security testing now has to account for prompt injection, system prompt leakage, vector-store abuse, and excessive agency because static scanning misses runtime failures, according to Openlayer. The 2025 OWASP update makes session-level testing and evidence generation central to AI governance, especially where tools, retrieval, and agent handoffs can turn model behaviour into real actions.
NHIMG editorial — based on content published by Openlayer: OWASP LLM Security Testing: Top 10 Risks Guide (July 2026)
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.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams test LLM applications for runtime security failures?
A: Test the full runtime path, not just the model in isolation.
Q: Why do agentic AI systems create more security risk than standard chatbots?
A: Agentic systems can turn model output into action, which means a bad instruction can affect code flow, tool use, and downstream state.
Q: What do security teams get wrong about prompt injection defence?
A: They often assume better blocklists will solve the problem, but obfuscation simply changes the shape of the payload.
Practitioner guidance
- Build session-level LLM test cases Create adversarial test suites that exercise direct injection, indirect injection, tool abuse, and prompt leakage with retrieval and agents enabled.
- Constrain tool and API privileges Map every tool call, database action, and external API request to a specific business task and remove broad standing access.
- Protect prompts and retrieval inputs as governed assets Classify system prompts, vector-store content, and retrieved documents as security-relevant inputs.
What's in the full article
Openlayer's full blog covers the operational detail this post intentionally leaves for the source:
- Phase-by-phase testing guidance for model evaluation, integration testing, output validation, and production monitoring
- Threshold examples for groundedness, toxicity, and refusal-rate drift that teams can use in testing programmes
- Coverage of how Openlayer logs flagged inferences and builds evidence records for conformity assessments
- Practical examples of how agent evaluation tracks tool-call accuracy and permission scope across reasoning steps
👉 Read Openlayer's guide to OWASP LLM security testing and the 2025 risk update →
OWASP LLM security testing: are your runtime controls keeping up?
Explore further
06/09/2026 9:02 am
OWASP LLM security testing has become a runtime governance discipline, not a model QA exercise. The 2025 revision reflects a market reality that LLM failures surface through inference-time behaviour, retrieved content, and delegated actions. That pushes security teams toward continuous evaluation, session logging, and policy enforcement at the API boundary. For IAM and NHI programmes, the implication is clear: if a model can act, it needs governance that looks more like identity control than static software review.
A question worth separating out:
Q: How do organisations govern LLM tools and retrieval without overexposing access?
A: Treat every tool, retrieval source, and connected API as a scoped capability with a clear owner, purpose, and revocation path. Remove standing access that an LLM does not need, and require logging for each inference that touches sensitive context. That keeps delegated behaviour reviewable and limits blast radius.
👉 Read our full editorial: OWASP LLM security testing now needs runtime and agentic controls
