Join our Newsletter — 33% off our NHI Course

Large Language Model (LLM) Applications

Large Language Model applications are software products or workflows that use an LLM to generate, classify, summarise or transform text and other content. They sit on top of prompts, retrieval systems, tool calls and application controls, and their security depends on what data they can see, what actions they can take, and how outputs are filtered or reviewed.

What LLM Applications Are Built From

LLM applications are not just “a model in a box.” They are assembled systems that combine prompts, retrieved context, tool integrations, policy checks and output handling, so the real security boundary is the whole workflow, not the model alone.

That matters because an LLM can only act within the controls around it. If the application exposes the wrong data, calls the wrong tool, or passes untrusted input straight into the model, the result can be data leakage, unsafe actions or misleading output at scale.

Where LLM Applications Become Security-Sensitive

The main security question is what the application can see and what it can do. If a copilot, chatbot or workflow assistant can access internal documents, customer records, code repositories or admin functions, then prompt handling, retrieval permissions and tool authorization all become part of the security design.

That is why application security for LLM systems often looks more like governance over data flow and action scope than traditional perimeter defense. A harmless-looking text feature can become a high-impact control point once it can summarize sensitive content, trigger workflows or generate instructions that users trust.

Common Failure Modes in LLM Applications

Typical failure modes include prompt injection, over-sharing from retrieval systems, unsafe tool calls, weak approval boundaries and poor output filtering. These failures often do not require the model to be “broken”; they exploit the surrounding application logic, trust assumptions or missing permission checks.

Another recurring issue is that organisations treat the model output as if it were content only, when it may actually carry operational meaning. If generated text can drive decisions, tickets, messages or code changes, then a bad prompt, poisoned context or compromised connector can create real downstream harm.

Designing LLM Applications for Trust and Control

Good LLM application design separates user input, retrieved context, tool permissions and final output review. The safest systems limit what data reaches the model, keep tool access narrowly scoped, and add explicit checks before any action leaves the application boundary.

For the broader security pattern behind these systems, Permission-Aware RAG is a useful reference for keeping retrieval aligned with access rights, while Enterprise AI Copilot Security Guide shows how over-sharing, connectors and agentic features change the control model.

Risk and Threat Considerations

LLM applications concentrate multiple trust boundaries into a single workflow, so a weakness in prompts, retrieval, connectors or approval logic can expose sensitive data or turn the system into an abuse path. The risk is not only incorrect answers, but also unauthorized disclosure and unintended actions that look legitimate to users.

Failure mechanism: Attackers or malformed inputs can steer the application through prompt injection, poisoned context, over-broad retrieval, or unsafe tool invocation, then use the model’s authority or user trust to amplify the result.

Impact: The outcome can include data exfiltration, policy bypass, fraudulent workflow actions, compromised accounts or large-scale misinformation inside business processes.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST AI 600-1, NIST AI RMF and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST AI 600-1 Generative AI Profile Covers GenAI governance, testing, provenance and incident handling for LLM applications.
Recommendation — Adopt GenAI profile guidance to govern testing, provenance and incident response for LLM features.
NIST AI RMF AI Risk Management Framework Defines risk governance and trustworthy AI practices for systems built on LLMs.
Recommendation — Use the AI RMF to govern risk, trustworthiness and accountability across the LLM application lifecycle.
OWASP ASVS V8 — Authorization LLM apps rely on application authorization for retrieval, tool use and action boundaries.
V16 — Security Logging and Error Handling LLM applications need logging for prompts, tool calls and safety-relevant failures.
Recommendation — Apply V8 to verify that LLM features cannot access or act beyond authorized scope. Use V16 to log model interactions and review failures that indicate abuse or unsafe behavior.
MITRE ATT&CK Enterprise Matrix Supports adversary techniques used against LLM applications, including credential access and lateral movement.
Recommendation — Map observed abuse paths to ATT&CK techniques and hunt for the surrounding intrusion chain.

Practitioner Guidance

Why practitioners should care: LLM applications need controls around the whole interaction path, not just the model endpoint. Security teams should treat retrieval permissions, tool access, human review and logging as first-class design decisions because each one changes what the system can reveal or do.

Practitioner takeaway: If the application can read data or take actions on behalf of users, assume the model is part of a broader control plane and design accordingly.