Generative AI Risks: The Complete List Every Business Should Know
Generative AI risk spans two distinct classes: model-level risk (hallucination, data leakage, IP exposure, training data poisoning) created by what a model produces, and runtime or agentic execution risk (prompt injection, excessive agency, insecure tool design, uncontrolled tool calls) created by what an AI agent does when connected to enterprise systems. Enterprises need separate assessment processes and control layers for each.
What Generative AI Risk Actually Covers
Generative AI risk is not a single category of exposure. It spans model behavior, the infrastructure that serves models, and increasingly the actions AI agents take when connected to enterprise tools and data. Frameworks published or updated in the past year, including NIST's Generative AI Profile (NIST AI 600-1), the OWASP Top 10 for LLM Applications, and MITRE ATLAS, each describe overlapping but distinct parts of this exposure. None of these sources on its own provides a single taxonomy spanning both model-output risk and runtime execution risk, which is one reason enterprise risk registers built on a single framework tend to leave gaps.
For governance purposes, it is useful to separate generative AI risk into two broad classes. The first is model-level risk: exposure created by what a generative model produces, including inaccurate or fabricated outputs, leaked sensitive information, and IP or copyright exposure in generated content. The second is runtime and agentic execution risk: exposure created by what an AI agent does, including which tools it invokes, what permissions it holds, and how it interacts with connected systems such as those exposed through the Model Context Protocol (MCP). Standalone generative models, whose action space is limited to producing text or data, primarily present the first class of risk. AI agents that plan multi-step tasks and call external tools extend well into the second.
Model-Level Risks: What the Model Produces
Model-level risk concerns the content a generative system generates rather than any action it takes. These risks are assessed primarily through output evaluation, red-teaming of generated content, and data governance review, since the model's action space in this class is limited to generation rather than execution.
- Confabulation (hallucination): a core risk category identified by NIST's Generative AI Profile, where a model produces plausible but inaccurate or unsupported output.
- Sensitive information disclosure: proprietary or confidential data appearing unintentionally in generated output, per OWASP's Top 10 for LLM Applications.
- Training data poisoning: manipulated training data influencing model behavior.
- Model denial of service: resource-intensive interactions that degrade availability.
- Supply chain vulnerabilities: weaknesses introduced through third-party models or components.
- Model theft: extraction of model weights or behavior.
- Intellectual property exposure: generated content that incorporates or closely resembles protected material.
- Overreliance: a governance risk, also named in OWASP's list, that occurs when users or downstream systems treat generative output as authoritative without adequate verification, compounding the impact of hallucination or data leakage.
Runtime and Agentic Execution Risks: What the Agent Does
When a generative model is embedded in an agent that plans tasks and invokes tools, the risk surface extends beyond content into execution.
- Excessive agency: defined by OWASP as the risk that arises when an LLM-based system is granted more functionality, permissions, or autonomy than its task requires.
- Insecure plugin or tool design: integrations that lack proper input validation or access boundaries.
- Prompt injection: crafted input that manipulates a model into producing unintended instructions or actions, materially more consequential in agentic systems because it can lead directly to tool invocation rather than only altered text output.
The emergence of protocols such as MCP, released by Anthropic in November 2024 as an open standard for connecting models and agents to external data sources and tools, adds a further layer. MCP's architecture involves a host application, client, and server, mediating access between the model, the connecting agent, and external systems. This mediation creates a distinct trust boundary that did not exist in earlier, more contained generative model deployments. Risk assessment and controls at this layer must therefore address the protocol and connector components, not only the underlying model, since uncontrolled tool calls or improperly scoped MCP server permissions can expose enterprise systems regardless of how well the model itself behaves.
Control Categories That Address Each Risk Class
The table below summarizes the two risk classes described above, the additional protocol-layer risk introduced by agent connectors, and the governance control categories that address each layer.
| Risk layer | Description |
|---|---|
| Model-level risk | Exposure from model outputs: hallucination, data leakage, IP exposure, training data poisoning. |
| Runtime and agentic risk | Exposure from agent actions: prompt injection, excessive agency, uncontrolled tool calls. |
| Protocol and connector risk | Risk introduced at the MCP or tool-connector layer mediating agent and enterprise system access. |
| Governance controls | Least-privilege access, tool-call policy enforcement, output validation, audit logging. |
Why the split matters: model-level controls such as output validation and red-teaming do not cover what happens once an agent is granted tool access. Runtime governance, least-privilege access, tool-call policy enforcement, and audit logging address the execution-layer risks separately.
Governance Structure and Framework Alignment
NIST's original AI RMF (2023) organizes risk management around four functions: Govern, Map, Measure, and Manage. This structure can be applied across both model-level and agentic risk categories, giving organizations a common process even where the specific controls differ. OWASP's LLM risk categories are useful as a checklist basis for building internal risk registers, but they are not a formal regulatory standard, and organizations should not treat OWASP alignment as equivalent to regulatory compliance.
CISA and NSA's joint guidance on deploying AI systems securely frames AI security largely within existing enterprise security governance practices, recommending access control, monitoring, and incident response rather than treating AI as an entirely separate discipline. MITRE ATLAS complements these defender-oriented frameworks by documenting adversarial tactics and techniques against AI systems, including data poisoning, model evasion, and exfiltration via ML system components, modeled on the ATT&CK structure. Combining a defender-oriented framework like NIST or OWASP with an adversary-oriented reference like ATLAS gives governance teams a more complete basis for identifying where model-level and runtime controls need to apply.
Build a Structured View of Your Generative AI Risk Surface
Separating model-level risk from runtime and agentic execution risk is the first step toward a defensible AI risk program. Runtime governance controls, including least-privilege access, tool-call policy enforcement, and audit logging, address the execution-layer risks that model-level controls alone do not cover.
Explore runtime governance