Why Secure Your AI Applications

Updated November 2, 2026 — Models. Mistral Large 3 (mistral-large-2512) and Mistral Medium 3.5 were deprecated on October 31, 2026, and will be retired on April 30, 2027. Their designated successor, Mistral Large 4 (mistral-large-4), has been in public preview since October 6. The examples in this course use the alias mistral-large-latest, which currently points to Mistral Large 3 according to its official specification (verified November 3, 2026). Similarly, mistral-medium-latest points to Mistral Medium 3.5. These aliases will remain valid until April 30, 2027. For new projects, test mistral-large-4, their designated successor.

Corrected November 3, 2026. The guardrail example previously used an invented format (guardrails={"enabled": True}). The official parameter is a list of moderation_llm_v2 configurations, detailed in the next lesson. Two unsourced figures (“78% of companies” and “less than 50ms latency”) have been removed: Mistral does not publish latency metrics for its guardrails. Sources: Moderation & Guardrailing · mistralai SDK 3.7.0.

AI Security: A Critical Challenge in 2026

Deploying a language model to production without security mechanisms is like launching a web service without a firewall. Large language models (LLMs) are powerful tools, but they can generate inappropriate content, leak sensitive data, or be manipulated by malicious users. This isn’t a theoretical problem: it manifests within the first few thousand real requests, as soon as your users step outside the scenarios you imagined.

As a developer, you are directly responsible for what your AI application produces. If your chatbot generates dangerous medical advice or hateful content, your company bears the consequences—legal, reputational, and financial. No one will ask whether the model came from a third-party provider.

The Three Types of Risks

The first risk is generated inappropriate content. The model can produce violent, sexual, discriminatory, or dangerous content, even without malicious intent from the user. A simple ambiguous prompt is enough to trigger a problematic response: ask a culinary assistant how to “neutralize” an ingredient, and you’ll see the line is finer than expected.

The second risk comes from user manipulation, also known as prompt injection. Malicious users attempt to bypass system instructions to force the model to produce forbidden content. Jailbreak techniques evolve constantly, spread across forums within hours, and require multi-layered defenses rather than a simple list of banned words.

The third risk is sensitive data leakage. The model can inadvertently reveal personally identifiable information (PII), secrets injected into the context, or confidential data present in its training set. Consider an HR assistant innocently asked, “What’s in Marie’s file?” The request isn’t aggressive, yet the result is a data breach.

The Mistral Approach: Two Lines of Defense

Mistral addresses these risks with two complementary layers: one upstream, one downstream. The first, Custom Guardrails, analyzes the user’s prompt before it reaches the model. If the content is deemed dangerous, the request is blocked with a 403 error—themodel never sees the prompt and generates nothing from it.

# The prompt is analyzed BEFORE the model
response = client.chat.complete(
    model="mistral-large-latest",
    messages=[{"role": "user", "content": prompt}],
    guardrails=[  # First line of defense
        {
            "block_on_error": True,
            "moderation_llm_v2": {
                "custom_category_thresholds": {"jailbreaking": 0.3},
                "action": "block",
            },
        }
    ],
)

The second layer, the Moderation API, works in the opposite direction: it analyzes content after generation to assign risk scores by category. Unlike guardrails, it doesn’t make decisions for you. You retrieve the scores and decide what to do next: display, hide, flag, or block.

# The generated content is analyzed AFTER generation
moderation = client.classifiers.moderate_chat(
    model="mistral-moderation-2603",
    inputs=[
        {"role": "user", "content": prompt},
        {"role": "assistant", "content": texte_genere},  # the response text
    ],
)

Why Both Are Necessary

Each layer has a blind spot that the other covers. Guardrails alone aren’t enough: the model can generate problematic content even from a harmless prompt, and input analysis can’t anticipate everything. Moderation alone isn’t enough either: it detects problems after the fact, never preventing the model from processing malicious requests or wasting compute time on them.

Combined, they form a defense in depth: input filtering is proactive, output filtering is reactive, and dangerous content must pass both to reach the user. It’s this redundancy, not the perfection of a single filter, that makes the architecture robust.

Your Responsibility as a Developer

The European regulatory framework imposes concrete obligations under the AI Act and the GDPR (General Data Protection Regulation). You must ensure transparency, meaning you inform users they are interacting with an AI, and traceability, by keeping moderation logs usable during an audit. Proportionality also applies: security thresholds for an assistant designed for healthcare professionals cannot be the same as those for a consumer chatbot, and you must be able to justify your choice. Finally, data protection prohibits processing PII without a legal basis, including in your moderation logs.

In this course, you will learn to implement these two lines of defense with the Mistral API, configure your thresholds, and build a complete security architecture for your production applications.

Key Takeaways

• LLMs in production require security mechanisms
• Mistral offers two complementary approaches: guardrails (before) and moderation (after)
• You are responsible for the content generated by your application
• AI security isn’t optional—it’s a legal and ethical obligation