Sécuriser les agents avec des guardrails — Agents Mistral — Créer des IA Autonomes

La sécurité des agents n’est pas optionnelle

Un agent autonome qui utilise des outils, accède à Internet et exécute du code représente un risque si ses actions ne sont pas encadrées. La différence avec un simple appel de complétion est de nature, pas de degré : un modèle qui produit du texte se corrige à la lecture, un agent qui agit a déjà agi. Les guardrails sont l’ensemble des mécanismes qui définissent les limites de ce qu’un agent peut et ne peut pas faire. Aucun d’eux n’est suffisant à lui seul ; c’est leur superposition qui protège.

Le paramètre guardrails

Le premier niveau se déclare à la création de l’agent.

from mistralai import Mistral
import os

client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])

agent = client.beta.agents.create(
    model="mistral-large-latest",
    name="Agent Sécurisé",
    description="Agent avec guardrails activés.",
    instructions="""Vous êtes un assistant professionnel.
- Ne partagez jamais d'informations personnelles
- Ne générez jamais de contenu inapproprié
- Refusez les demandes hors périmètre
- En cas de doute, demandez une clarification""",
    tools=[{"type": "web_search"}],
    guardrails={"enabled": True}
)

Le même paramètre s’accepte au niveau de la conversation, où il prend le pas sur la configuration de l’agent. Cela vous permet de durcir ponctuellement le comportement d’un agent partagé, sans créer une seconde version de cet agent pour un seul cas d’usage.

response = client.beta.conversations.start(
    agent_id=agent.id,
    inputs="Analysez ce document confidentiel.",
    guardrails={"enabled": True}  # Override les guardrails de l'agent
)

Les instructions, votre première ligne de défense

Le system prompt reste le levier le plus efficace, parce qu’il agit avant toute décision du modèle. Un prompt de sécurité bien construit sépare nettement le rôle, le périmètre, les interdits et le format attendu.

instructions = """## Rôle
Vous êtes un assistant juridique spécialisé en droit du travail français.

## Périmètre
- UNIQUEMENT le droit du travail français
- Refusez toute question hors périmètre (fiscalité, immobilier, pénal, etc.)

## Interdictions strictes
- Ne donnez JAMAIS de conseil juridique définitif
- Ne rédigez JAMAIS de documents juridiques sans avertissement
- Ne partagez JAMAIS d'informations sur d'autres clients
- Mentionnez TOUJOURS qu'un avocat doit valider

## Format
- Citez les articles de loi pertinents
- Indiquez clairement les limites de votre réponse
- Proposez toujours de consulter un professionnel"""

Observez ce que fait la section « Périmètre » : elle ne se contente pas de dire ce que l’agent traite, elle nomme explicitement les domaines voisins qu’il doit refuser. Sans cette énumération, une question de fiscalité liée à un licenciement passe la barrière, parce qu’elle ressemble suffisamment à du droit du travail pour que le modèle s’y engage. La section « Interdictions strictes » suit la même logique : elle formule des refus, pas des recommandations. Un agent à qui l’on demande d’être « prudent » calibre lui-même sa prudence ; un agent à qui l’on interdit de rédiger sans avertissement applique une règle.

Le principe du moindre privilège

Chaque outil déclaré est une capacité que l’agent peut mobiliser à contretemps. Comparez ces deux configurations.

# Trop d'outils — surface d'attaque large
agent_dangereux = client.beta.agents.create(
    model="mistral-large-latest",
    name="agent-tout-faire",
    tools=[
        {"type": "web_search"},
        {"type": "code_interpreter"},
        {"type": "image_generation"},
        {"type": "document_library", "library_ids": [lib.id]}
    ]
)

# Principe du moindre privilège — seulement ce qui est nécessaire
agent_securise = client.beta.agents.create(
    model="mistral-large-latest",
    name="agent-documentation",
    tools=[{"type": "document_library", "library_ids": [lib.id]}]
)

Le second agent ne peut pas partir chercher sur Internet une information absente de vos documents, ni exécuter du code sur un contenu que vous n’avez pas relu. Ce n’est pas une limitation subie : c’est la garantie que ses réponses viennent de votre base documentaire et de nulle part ailleurs. Posez-vous la question outil par outil — si vous ne trouvez pas de scénario où l’agent en a besoin, retirez-le.

Filtrer les transferts

Dans un système multi-agents, le mode client vous donne un droit de veto sur chaque handoff. Une liste blanche suffit à empêcher qu’un agent en atteigne un autre par un chemin que vous n’aviez pas prévu.

response = client.beta.conversations.start(
    agent_id=router.id,
    inputs=user_query,
    handoff_execution="client"
)

ALLOWED_AGENTS = {research.id, analyst.id}  # Whitelist

for entry in response.outputs:
    if entry.type == "agent.handoff":
        if entry.to_agent not in ALLOWED_AGENTS:
            print(f"BLOQUÉ : handoff non autorisé vers {entry.to_agent}")
            continue
        # Continuer avec l'agent autorisé

La whitelist vit dans votre code, pas dans la configuration des agents : elle reste donc valable même si quelqu’un ajoute une cible de handoff sur le routeur sans vous prévenir.

Ne pas conserver ce qui n’a pas à l’être

Pour les données sensibles, la meilleure protection consiste à ne rien stocker.

response = client.beta.conversations.start(
    agent_id=agent.id,
    inputs="Données confidentielles : rapport financier Q1 2026...",
    store=False  # Rien ne persiste
)

Ce réglage se décide par conversation, ce qui vous permet de conserver l’historique des échanges ordinaires tout en traitant les contenus confidentiels en mode éphémère.

Modérer en amont

Une variante élégante consiste à placer un agent de modération en tête de chaîne : il examine la requête et ne transfère au spécialiste que si elle est recevable.

moderator = client.beta.agents.create(
    model="mistral-large-latest",
    name="moderator",
    description="Vérifie que les requêtes sont appropriées.",
    instructions="""Analysez la requête utilisateur :
- Si appropriée : transférez au spécialiste
- Si inappropriée : répondez poliment que la demande n'est pas prise en charge
- Si ambiguë : demandez une clarification"""
)

specialist = client.beta.agents.create(
    model="mistral-large-latest",
    name="specialist",
    description="Traite les requêtes validées.",
    tools=[{"type": "web_search"}]
)

moderator = client.beta.agents.update(
    agent_id=moderator.id,
    handoffs=[specialist.id]
)

L’intérêt du pattern tient à la séparation des rôles : le modérateur n’a aucun outil et ne fait qu’une chose, si bien qu’une requête malveillante qu’il rejette n’atteint jamais l’agent qui, lui, sait agir.

Régler la génération

Les paramètres de complétion participent aussi à la sécurité, pour une raison simple : une réponse inventée est un risque, et la créativité en est le terreau.

agent = client.beta.agents.create(
    model="mistral-large-latest",
    name="Agent Factuel",
    description="Agent factuel et conservateur.",
    completion_args={
        "temperature": 0.1,   # Très peu de créativité
        "top_p": 0.85,        # Noyau restreint
        "max_tokens": 1024    # Réponses courtes
    }
)

Une température de 0.1 associée à un top_p de 0.85 laisse au modèle très peu de latitude : sur une question dont la réponse figure dans vos documents, il la restitue au lieu d’en broder une variante. Le plafond de 1024 tokens joue un rôle voisin, car une réponse qui s’allonge finit par sortir du périmètre documenté et par produire du remplissage. Ces réglages ne conviennent évidemment pas à un agent créatif, mais ils sont la configuration par défaut de tout agent censé énoncer des faits — assistant juridique, support technique, expert produit.

Avant la mise en production

Ces mécanismes ne valent que superposés, et le tour de contrôle final tient en quelques vérifications. Les instructions doivent définir explicitement le périmètre et les interdictions, et l’agent ne doit disposer que des outils strictement nécessaires à sa tâche. Vérifiez que les guardrails sont bien activés, et que les workflows critiques passent en mode client afin qu’aucun handoff ne s’exécute sans votre accord. Assurez-vous que store=False accompagne toute conversation portant des données sensibles, et que la température reste basse partout où l’agent est censé rester factuel. Placez enfin un agent de modération devant la chaîne, pour que les requêtes irrecevables n’atteignent jamais les agents qui savent agir.

Points clés à retenir

Les guardrails se configurent au niveau agent et/ou conversation
Les instructions sont votre première ligne de défense — soyez explicite sur les interdictions
Appliquez le principe du moindre privilège : donnez uniquement les outils nécessaires
Le mode client permet de valider et bloquer les handoffs non autorisés
En production : modération en amont, logging, whitelist d’agents, store=False pour le sensible