OWASP LLM security testing now needs runtime and agentic controls

At a glance

What this is: Openlayer’s analysis says OWASP LLM testing has shifted from static checks to runtime and session-level evaluation because the main failure modes emerge during inference, retrieval, and tool use.

Why it matters: IAM and AI security teams need to treat agent permissions, tool calls, and retrieval paths as governed attack surfaces, not just model inputs, because LLM failures can become real actions.

Context

LLM applications do not fail like conventional software, because the relevant security boundary is often the live interaction between prompts, retrieved content, tools, and downstream actions. That creates a governance gap for security teams that still rely on static analysis, CVE scanning, or single-turn validation to judge AI risk.

The identity angle is real when models act through tools, APIs, and delegated access. Once an LLM can read data, call services, or hand work to another agent, the question becomes who or what is authorised to act at runtime, and how that authority is tested before it reaches production.

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. That means prompt injection, prompt leakage, and unsafe tool execution can pass code review and still fail in production. Security teams need session-level evaluation because the real attack surface appears after the model assembles context and begins acting.

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. Memory, multimodal inputs, and tool use expand the volume of sensitive information in play, while weak controls can expose personal data or credentials. That raises GDPR, audit, and deletion challenges, especially when decisions are made without clear human review or reliable data flow tracing.

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. If the team cannot reconstruct who submitted what, what the model returned, and which policy intervened, the control is not operationally complete.

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.

Technical breakdown

Why static scanning misses OWASP LLM risks

Traditional application security tools assume predictable code paths and bounded inputs. LLM applications break that assumption because prompts, retrieved documents, tool responses, and hidden instructions all become part of the execution context at inference time. A malicious instruction can arrive through a user prompt or through RAG content that the model trusts, so the attack surface moves with every session. Static analysis sees the code, but not the behaviour the model produces once context is assembled.

Practical implication: test the live prompt, retrieval, and tool chain together, not just the application code.

System prompt leakage and vector-store weakness

System prompt leakage is a runtime disclosure problem, not a code flaw alone. If a model can be coaxed into revealing hidden instructions, it may also expose embedded policies, workflow logic, or accidentally included secrets. Vector and embedding weaknesses widen that risk in RAG systems, because poisoned or manipulated stores can influence what the model retrieves and how it answers. The control problem is therefore about trust in context sources, not just model output filtering.

Practical implication: govern what enters retrieval layers and treat system prompts as sensitive runtime assets.

Excessive agency turns model output into action

Excessive agency occurs when an LLM or agent can do more than its task requires, such as invoking tools, writing to systems, or passing decisions downstream without a validation gate. That is where identity and privilege become central. The model is no longer only generating text; it is acting through delegated authority. Once tool calls chain across services, a successful prompt injection can cross from content manipulation into operational change.

Practical implication: scope every tool, API, and delegated permission to the minimum action set required for the task.

Threat narrative

Attacker objective: The attacker wants to turn a model interaction into unauthorized disclosure or unauthorized action by exploiting runtime trust.

1. Entry occurs when an attacker injects malicious instructions through a prompt, retrieved document, or other trusted context source at inference time.
2. Credential access or action abuse follows when the model accepts hidden instructions and uses its connected tools, APIs, or delegated permissions beyond the intended task.
3. Impact occurs when the compromised session leaks sensitive context, executes unintended actions, or propagates the injected instruction across agent handoffs.

Breaches seen in the wild

• ForcedLeak (Salesforce Agentforce) 2025: A critical Agentforce flaw let attackers steer an AI agent through a Web-to-Lead form to leak CRM data via an expired allowlisted domain.
• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Excessive agency is the clearest identity problem in agentic AI. Once an LLM can call tools or hand work to another system, it is operating through delegated authority that needs scope, revocation, and auditability. That makes the model, the tool chain, and the permissions model inseparable. Practitioners should govern agent permissions the way they govern privileged access, because the blast radius is determined by delegated action.

Vector-store trust is a new governance surface, not just a retrieval design choice. RAG systems inherit the risk of whatever content they retrieve, and poisoned context can change behaviour without changing code. Context integrity gap: that is the failure mode the 2025 OWASP update is really naming, because the model trusts retrieved material that security teams have not authenticated. Practitioners should classify retrieval sources as security-relevant inputs, not as neutral data plumbing.

The OWASP LLM Top 10 is becoming an evidence framework as much as a threat taxonomy. The value is no longer just naming categories like prompt injection or system prompt leakage. It is in producing repeatable test records that show how an application behaved under adversarial inputs, which is what auditors and AI governance teams need. Practitioners should design testing to generate defensible evidence, not just vulnerability findings.

From our research library:

• 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.
• Read next: Agentic AI Security Guide

What this signals

Runtime evaluation is becoming the governance control that separates safe prototypes from deployable LLM systems. Security teams can no longer rely on the assumption that code review, unit tests, or CVE scans will expose behavioural failure. The key shift is to make every release prove how it behaves under prompt injection, retrieval poisoning, and tool abuse before it is allowed to act.

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. That pattern reinforces the article’s core warning: the wider AI stack, not just the model, is where many of the most damaging exposures now accumulate.

For identity programmes, the important question is no longer whether the model is accurate enough. It is whether the model, the retrieval layer, and the tool chain are all operating within a controllable privilege envelope. If those boundaries are vague, OWASP testing will surface symptoms, but governance will still be incomplete.

For practitioners

• 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.
• Treat retrieval sources as governed inputs Validate the provenance and trust level of vector-store content, documents, and API responses before they can influence model behaviour.

Key takeaways

• LLM security failures now emerge at runtime, where prompts, retrieved content, and tool responses combine into behaviour that static analysis cannot see.
• Agentic systems increase risk because delegated permissions let a compromised inference session become an unauthorized action path.
• OWASP LLM testing is most useful when it produces auditable evidence about behaviour, not just a checklist of theoretical vulnerabilities.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• System Prompt Leakage: System prompt leakage is the exposure of hidden prompt content to users or attackers. The real security problem is usually not the prompt itself, but the secrets, policy logic, and internal architecture details placed inside it. If those details are sensitive, they should live in code or secrets management instead.
• Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.
• Vector And Embedding Weaknesses: Vector and embedding weaknesses are security flaws in the storage, retrieval, or protection of embeddings used by LLM applications. If these data structures are poisoned, exposed, or improperly controlled, attackers may alter retrieval results, influence model output, or access information that should remain restricted.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and workload identity in the context of real operating controls. It helps security practitioners connect runtime AI behaviour to access, privilege, and lifecycle governance.