An AI system in production rarely consists of just a single component: LLM, RAG, and vector databases; function calling; agents orchestrated via MCP; and MLOps and model serving infrastructure.
ving. Each added building block expands the available attack surface, and most of the incidents documented in 2025–2026 occur precisely in the interfaces between these building blocks, rather than in the language model itself. This guide covers five architectural building blocks in the order in which they are typically stacked, identifying the risk vector(s) specifically associated with each one.
LLM: prompt injection, jailbreak, and system prompt leak
The language model itself is the most mature component from a security perspective, precisely because it is the focus of the most research attention. Threeattack vectors target it directly.Prompt injection inserts malicious instructions into the input processed by the model, either directly or via a document being accessed; this is currently the most well-documented attack vector, with the majority of production deployments being exposed to it in one way or another. Jailbreak aims to bypass alignment safeguards to generate content that would normally be rejected. System prompt leakage targets internal instructions that configure an application’s behavior; extracting these can reveal business logic or facilitate a more targeted attack.
These three vectors have one thing in common: there is no foolproof defense against them; the probabilistic nature of an LLM makes protection a matter of reducing the attack surface and continuous detection rather than complete elimination.
RAG and Vector Databases: RAG Poisoning
The RAG enriches a model’s responses with documents retrieved from a vector database at the time of the query—a critical component: these are often copies of data that is already sensitive elsewhere, with historically weaker protection. The associated risk, known as RAG poisoning, involves injecting malicious documents into this database: recent research shows that even a very small number of poisoned documents is sufficient to significantly influence the generated responses, even within an index containing several million legitimate documents. Any database fed by ungoverned sources (customer tickets, internal wikis, scraped content) must be treated as a full-fledged channel for indirect injection.
Encryption at rest and in transit, as well as aligning the retention period for indexed documents with that of the original sources, remain basic measures that are often overlooked during the prototyping phase.
MCP, function calling, and agents: inherited permissions and upstream poisoning
Function calling allows a model to act beyond the text; the MCP protocol standardizes this connection to tools. The most fundamental risk principle can be summed up in one sentence: an AI agent acts within its own permissions, and any successful manipulation—such as an indirect prompt injection hidden within a viewed document—causes it to inherit that elevation of privileges. This is why managing AI access and identities becomes a security component in its own right as soon as an agent has tools at its disposal. A CVE documented in early 2026 (CVE-2026-4270 in awslabs.aws) on a widely used MCP server illustrates this scenario: a flaw in file access restrictions exposed arbitrary local content without any compromise of the model.
Autonomous agents pose this risk and add to it the risk of sub-goal hijacking, as well as a supply chain risk specific to their ecosystem: In early 2026, a landmark incident illustrated this risk when Openclaw’s Clawhub marketplace was targeted by a campaign involving malicious “skills.” Researchers identified 341 malicious skills out of 2,857 analyzed, several of which were used to install or distribute the Atomic macOS Stealer (AMOS) by masquerading as legitimate tools and exploiting the trust of users who had installed these extensions. Upstream from these components, model poisoning targets the training or fine-tuning process itself to introduce hidden behavior into the final model.
Infrastructure and Model: Extraction, Inversion, and Slopsquatting
Beneath the application building blocks lie MLOps, model serving, and—for sovereignty—the self-hosted LLM. Two approaches target the model once it has been trained: model extraction, which reconstructs an approximation of the model through repeated queries to its API—posing an intellectual property risk—and model inversion, which reconstructs information about the training data from the responses—posing a direct risk to privacy if that data were sensitive.
A more recent vector affects the development pipeline associated with these building blocks: slopsquatting exploits the fact that a code-generating template sometimes references package names that do not exist
(20% of generations, according to a study conducted by three universities), which an attacker then registers in a public registry to trap developers.
Deepfakes, AI-powered phishing, and data exfiltration: when the target is the architecture itself
Two types of attacks do not target any internal technical components: deepfakes and AI-assisted phishing use AI as a weapon against the company from the outside, without requiring any compromise of its information system. Finally, data exfiltration cuts across all the previous components (direct entry, a generated response revealing confidential content, or an agent with excessive access), making it less of an isolated vector and more of a potential consequence of any of the poorly secured components listed above.
A Single Framework for Prioritization: OWASP LLM Top 10
These building blocks and vectors largely align with the ten categories ofthe OWASP LLM Top 10, the most widely adopted framework for structuring an audit. Its practical benefit lies in distributing the workload across the relevant teams (application security for prompt injection, the data team for RAG poisoning, and the platform team for the supply chain and serving) rather than treating the ten categories as a flat list. The common aggravating factor across all these vectors is excessive human trust in the outputs of an AI system: a significant portion of risk reduction does not require expertise in machine learning, but rather the rigorous application of already-known principles (least privilege, input validation, human verification) to high-impact actions.
Frequently Asked Questions About the Security of AI Architectures
Should all bricks be secured with the same level of strength?
Is a recent, well-aligned LLM sufficient to mitigate these risks?
Securing Your End-to-End AI Architecture
Our experts evaluate every component of your architecture and the associated risks, from mapping to penetration testing.
Would you like to discuss your project or assess your needs? Contact our experts.