LLM threats are risks created when large language models are misused, manipulated, or allowed to act without sufficient controls. They include prompt injection, data leakage, hallucinated outputs, model theft, and unsafe tool use. In practice, they affect AI agents, access controls, secrets exposure, and downstream decisions across identity and security workflows.
What LLM threats usually involve
LLM threats are not a single bug class. They are a set of failure modes that appear when a model can be steered by untrusted inputs, exposed to sensitive context, or allowed to take actions without enough policy and oversight.
That makes the term broader than prompt injection alone. It also covers hallucinated outputs that are treated as truth, leakage of prompts or retrieved data, model theft, and tool use that crosses trust boundaries.
Why LLM threats are dangerous in practice
The danger is that LLMs often sit inside workflows that already contain access, secrets, and decisions. If the model can see confidential context, retrieve privileged data, or invoke tools, a compromise can move from “bad output” to real business impact quickly.
Threats also scale through repetition. A single poisoned prompt, connector, or shared memory path can affect many chats, many users, or many downstream systems, especially when the model is embedded in copilots, agents, or retrieval pipelines.
For a broader threat model of this class, the LLM Security Guide is the best starting point because it ties jailbreaks, data leakage, output handling, and system prompt extraction into one operating model.
Common failure patterns behind LLM threats
Prompt injection exploits the model’s tendency to follow the most persuasive instructions, even when those instructions come from untrusted content. Data leakage happens when prompts, retrieval sources, logs, or outputs expose secrets, personal data, or internal instructions.
Hallucinations become a security problem when users or automation trust fabricated facts, invented citations, or incorrect policy decisions. Unsafe tool use is worse still, because a mistaken or manipulated action can create account changes, data access, or external side effects.
Model and credential theft matter because LLM systems are often surrounded by API keys, service credentials, and cloud permissions. The LLM Provider API Key Security and LLMjacking Guide shows how stolen model access material turns an LLM issue into an access-control and abuse problem.
Where LLM threats show up in real environments
They often appear in chatbots, copilots, RAG systems, agentic workflows, model hosting platforms, and AI-enabled support tools. The weak point is usually not the model alone, but the surrounding permission model, connectors, memory, and output handling.
That is why exposed chats, leaked API keys, and compromised AI platforms are recurring patterns. The DeepSeek database exposure 2025 and Microsoft Azure OpenAI abuse by Storm-2139 examples both show how weak exposure controls and stolen credentials can amplify LLM-related harm.
When the threat involves agents, memory, or orchestration, the security question shifts from “is the model accurate?” to “what can it read, remember, retrieve, and do?” The Agentic AI Security Guide helps frame that broader control surface.
Risk and Threat Considerations
LLM threats become materially more serious when the model is connected to secrets, enterprise data, or tools that can change state. In those environments, a successful injection, leakage event, or bad tool decision can produce credential exposure, unauthorized access, or corrupted downstream decisions.
Failure mechanism: Attackers or untrusted content manipulate the model’s context, retrieval results, or tool-selection logic, then use the model’s authority and reach to exfiltrate data, trigger unsafe actions, or widen access.
Impact: The result can be disclosure of secrets or chat content, loss of trust in outputs, privilege misuse, fraudulent actions, or persistence through compromised AI workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI 600-1 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI01 — Agent Goal Hijack | LLM threats include prompt-driven manipulation of autonomous agent goals. |
| ASI02 — Tool Misuse | Unsafe tool use is a core LLM threat when models can invoke external actions. | |
| ASI03 — Identity & Privilege Abuse | LLM threats often turn into access abuse when models hold delegated permissions. | |
| Recommendation — Constrain agent objectives and reject instructions that redirect the approved task. Restrict tool scopes and validate every model-generated action before execution. Apply least privilege to agent identities and separate read from write authority. | ||
| NIST AI 600-1 | Generative AI Risk Profile | This profile addresses governance and risk controls for generative AI systems. |
| Recommendation — Use the profile to govern testing, monitoring, and incident handling for GenAI deployments. | ||
| MITRE ATLAS | Adversarial ML Techniques | Prompt injection, poisoning, and model abuse map to adversarial AI techniques. |
| Recommendation — Map observed LLM attacks to ATLAS techniques and hunt for matching abuse patterns. | ||
Practitioner Guidance
Why practitioners should care: The main mistake is treating LLM security as a content problem instead of an access and control problem. If the model can see sensitive data or act on behalf of users, the blast radius is defined by permissions, connectors, and logging as much as by model quality.
What to watch for: Look for overbroad context, reusable secrets in prompts or memory, unvalidated tool calls, and outputs that are used as if they were verified facts. The strongest control posture is the one that limits what the model can observe and what it can influence.