OWASP LLM security testing now needs runtime and agentic controls

At a glance

What this is: Openlayer's guide argues that OWASP LLM security testing must move from static checks to runtime evaluation because LLM risks emerge through prompts, retrieved content, tool calls, and agent behaviour.

Why it matters: For IAM and NHI practitioners, the article matters because LLM applications now behave like identity-bearing systems whose prompts, tools, and delegated actions can create privilege and governance failures.

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.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Openlayer's guide to OWASP LLM security testing and the 2025 risk update

Context

LLM security testing fails when teams treat generative systems like deterministic software. The attack surface is shaped at runtime through prompts, retrieved documents, tool responses, and session context, so traditional static controls miss the conditions that actually trigger abuse. That matters directly for LLM security testing, especially where LLMs are wired into workflows that can read data, call tools, or take downstream actions.

The identity angle is now unavoidable because many LLM deployments behave like delegated systems with credentials, scopes, and policy boundaries. Once an LLM can retrieve content or invoke tools, security teams need to think about least privilege, session scoping, and auditability in the same way they would for high-risk non-human identities.

Openlayer's framing is typical of the current market shift: practitioners are moving from model-only evaluation to application-level and session-level governance.

Key questions

Q: How should security teams test LLM applications for runtime security failures?

A: Test the full runtime path, not just the model in isolation. Use adversarial prompts, indirect injection through retrieved content, and tool-call scenarios to see whether the application can be steered into unsafe behaviour once retrieval, agents, and external APIs are active. That is where most LLM risk actually appears.

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. Standard chatbots usually stop at text generation. Agentic AI adds execution authority, so compromise can lead to disclosure, unauthorized changes, or misuse of credentials.

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. Real defence requires examining meaning across the full interaction, including retrieved content and model responses. If the control cannot interpret intent, it will keep missing the attack class it is meant to stop.

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.

Technical breakdown

Why LLM security testing must target runtime behaviour

LLM applications do not have a fixed, deterministic request path. A prompt can arrive through direct user input, retrieved content, a plugin response, or a tool call, and the model may reinterpret each as instruction. That makes the effective attack surface session-specific rather than code-specific. Security testing therefore has to simulate adversarial prompts, indirect injection, and context manipulation while the full stack is active. The important shift is from checking whether the model compiles or deploys to checking whether it can be steered into unsafe behaviour during inference.

Practical implication: test the application with retrieval, tools, and agents enabled, not just the base model in isolation.

How prompt injection propagates through agentic systems

Prompt injection becomes materially worse when an LLM can act. In a single-turn system, a malicious instruction may contaminate one response. In an agentic workflow, the same instruction can flow across multiple tool calls, sub-agents, and external API interactions until the task completes. That is why OWASP's 2025 update treats excessive agency and prompt injection as interacting risks, not separate ones. The governance problem is not only whether the model understands the instruction, but whether it has enough privilege for the instruction to matter.

Practical implication: scope every tool and API to the minimum session-level privilege needed for the task.

Why vector stores and system prompts need security boundaries

RAG architectures and system prompts create new trust surfaces inside the application. A poisoned vector store can surface malicious content that the model treats as authoritative, while exposed system prompts can reveal internal logic, policy constraints, or embedded secrets. These are not classic vulnerabilities in the web sense. They are retrieval and context integrity failures. Security teams need to treat retrieval sources, prompt templates, and context windows as governed inputs with validation, logging, and monitoring rather than as neutral plumbing.

Practical implication: validate retrieved content, protect prompt templates, and log every inference that touches sensitive context.

Threat narrative

Attacker objective: The attacker aims to steer the LLM or agent into revealing sensitive context, taking unsafe actions, or abusing connected tools and resources.

1. Entry occurs when an attacker places malicious instructions in user input, a retrieved document, or another content source that the model trusts during inference.
2. Escalation happens when the model follows those instructions across tool calls, allowing prompt injection to propagate into higher-privilege actions or data access.
3. Impact follows when the agent executes unintended actions, leaks prompts or context, or consumes resources in ways that affect security, cost, or availability.

NHI Mgmt Group analysis

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.

Runtime trust gap: this article shows that the missing control is not just content filtering but governed trust between prompts, retrieval, and tools. System prompt leakage, poisoned vector stores, and excessive agency all fail because the application treats contextual input as implicitly safe. That is a control design problem, not a tuning problem. Practitioners should read this as a warning that AI systems need explicit trust boundaries, especially where workload identity, delegated access, or secret material is involved.

Agentic AI testing must be session-scoped because single-turn testing cannot capture cumulative privilege abuse. An agent can inherit risk across multiple calls in ways that a one-off prompt test will never surface. This matters across OWASP-NHI and OWASP Agentic AI thinking because the security issue is not merely what the model says, but what it is allowed to do after it has been influenced. Teams should treat each session as a governed identity event with traceable scope and revocation points.

LLM security and identity security are converging around the same governance questions. Once an LLM can retrieve data or invoke tools, the core issue becomes who or what is authorised to act, under what conditions, and with what audit trail. That means security leaders should align AI testing with IAM, PAM, and secrets governance rather than leaving it in a separate AI risk silo. The practical conclusion is to collapse the gap between model evaluation and access governance.

Vector and embedding weaknesses deserve the same seriousness as credential exposure in adjacent systems. Poisoned retrieval layers can alter decision-making, expose sensitive information, or redirect downstream actions without touching the model weights. That makes data integrity and access controls on retrieval stores central to AI security. Practitioners should treat these stores as governed assets with ownership, validation, and monitoring.

What this signals

Session-level governance is becoming the deciding control for AI-enabled workflows. Once prompts, tools, and retrieval are part of the same execution path, traditional application testing is not enough. Practitioners should expect more pressure to produce auditable evaluation records, especially where AI systems touch regulated data or delegated access. For identity teams, the key question is whether AI actions are being governed like any other privileged runtime event.

Vector-store integrity will matter as much as model quality for many deployments. If the retrieval layer can be poisoned or mis-scoped, the model may behave correctly from its own perspective while still making unsafe decisions. That makes retrieval governance, prompt protection, and logging part of the security baseline. The practical signal is that AI risk management is moving closer to data access governance and away from isolated model review.

OWASP LLM testing is converging with identity and access control work. Teams that already manage NHIs, secrets, and privileged workflows have an advantage because the same governance pattern applies: define scope, log usage, and revoke when behaviour exceeds intent. The near-term programme shift is to unify AI security testing with IAM and PAM control evidence rather than run them as separate assurance tracks.

For practitioners

• 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. Validate behaviour across the whole runtime path, not just in model isolation.
• 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. Apply least privilege so a compromised reasoning step cannot trigger high-impact actions.
• Protect prompts and retrieval inputs as governed assets Classify system prompts, vector-store content, and retrieved documents as security-relevant inputs. Enforce validation, logging, and review for anything that can influence model behaviour or expose sensitive context.
• Preserve audit evidence for AI evaluations Store pass-fail records, threshold breaches, and flagged inferences in a form auditors can inspect during conformity work. Tie each evaluation run to the deployed model version and the control objective it was meant to prove.
• Connect AI testing to identity governance Align OWASP LLM test results with IAM, PAM, and secrets management so delegated model actions are reviewed like other privileged runtime events. That gives security teams a shared control model instead of fragmented AI and identity oversight.

Key takeaways

• LLM security testing now has to address runtime behaviour, because prompts, retrieval, and tool calls create failures that static scanning will miss.
• The 2025 OWASP update matters because it formalises agentic risk, system prompt leakage, vector-store abuse, and unbounded consumption as first-class concerns.
• Identity governance is part of AI security now, because delegated model actions need scope limits, logging, and revocation just like other privileged non-human workflows.

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.
• 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.
• 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.

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

👉 Openlayer's full article covers the testing phases, risk categories, and monitoring controls in more detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to govern delegated access. It is designed for security teams building the identity controls that modern AI and automation programmes now depend on.