Join our Newsletter — 33% off our NHI Course

OWASP LLM security testing: are your runtime controls keeping up?

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 16497
Topic starter  

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.

Editorial analysis by NHI Mgmt Group, based on content published by Openlayer: “OWASP LLM Security Testing: Top 10 Risks Guide (July 2026)”.

Key questions

Q: What breaks when LLM security testing stops at static analysis?

A: Static testing misses the failure modes that emerge only when prompts, retrieval, and tools interact at runtime.

Q: Why do LLM agents create more privacy and compliance risk than standard chatbots?

A: LLM agents increase risk because they can read, store, and act on more data across more systems.

Q: How do security teams know whether LLM firewall controls are working?

A: They should look for blocked secrets, logged policy violations, session-linked traces, and a measurable reduction in unsafe prompts and leaked outputs.

Practitioner guidance

  • Test prompts, retrieval, and tools as one runtime path Run adversarial scenarios across the full inference session so you can see how injected instructions propagate through retrieval and tool calls.
  • Scope agent permissions to the minimum task set Limit each agent, model, and workflow to only the tools and actions required for the specific job, and review any cross-service delegation.
  • Protect system prompts as sensitive runtime assets Separate hidden instructions, policy text, and secrets from user-visible context, then monitor for extraction attempts and unexpected disclosure.

Bottom line: LLM security failures now emerge at runtime, where prompts, retrieved content, and tool responses combine into behaviour that static analysis cannot see.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 16988
 

Runtime test coverage is now the real control boundary for LLM security. Static scanning can still find conventional software defects, but it cannot prove that a model will refuse injected instructions, resist prompt leakage, or ignore hostile retrieval content. The security question has moved from code correctness to behaviour under live context. Practitioners should treat runtime evaluation as a core control, not a bolt-on validation step.

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.

A question worth separating out:

Q: Which frameworks matter when LLMs can act through tools and retrieved context?

A: OWASP LLM testing maps most directly to agentic application risks, while AI governance frameworks matter when the model’s behaviour must be auditable and bounded. For practitioners, the practical decision is to align evaluation evidence with the controls that govern runtime behaviour, delegated access, and retrieval trust.

👉 Read our full editorial: OWASP LLM security testing now needs runtime and agentic controls



   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.