Tutoriel sur le Sandboxing Agent : Construire des applications LLM sécurisées

Introduction à la Sandbox des Agents

À mesure que les Grands Modèles de Langue (LLMs) évoluent, passant de simples agents conversationnels à des entités autonomes puissantes capables d’exécuter du code, d’interagir avec des API externes et de prendre des décisions dans le monde réel, la nécessité de mesures de sécurité solides devient primordiale. Un agent LLM, lorsqu’il a la capacité d’agir, peut représenter un risque de sécurité important s’il n’est pas correctement limité. C’est là qu’intervient la sandboxing des agents. Sandboxing un agent signifie créer un environnement isolé où il peut fonctionner sans affecter le système hôte ni accéder à des ressources non autorisées. Ce tutoriel explorera les aspects pratiques de la sandboxing des agents, fournissant des exemples pratiques pour démontrer comment construire des applications LLM sûres et fiables.

Le principe fondamental de la sandboxing est celui du moindre privilège : un agent ne devrait avoir accès qu’aux ressources absolument nécessaires à son fonctionnement, et rien de plus. Sans une sandboxing appropriée, un agent malveillant ou errant pourrait :

• Exécuter un code arbitraire sur le système hôte, entraînant un vol de données ou une compromission du système.
• Accéder à des fichiers sensibles ou à des ressources réseau.
• Initier des appels API externes non souhaités, entraînant des coûts ou effectuant des actions non autorisées.
• Exfiltrer des données confidentielles par divers canaux.

En mettant en œuvre une sandboxing efficace, nous pouvons atténuer ces risques, nous permettant d’utiliser l’immense puissance des agents LLM tout en maintenant le contrôle et la sécurité.

Comprendre les Menaces : Pourquoi Une Sandbox ?

Avant d’explorer le ‘comment,’ solidifions le ‘pourquoi.’ Les menaces posées par des agents non sandboxés sont multifactorielles et peuvent être classées comme suit :

1. Vulnérabilités d’Exécution de Code

De nombreux agents LLM avancés sont conçus pour écrire et exécuter du code (par exemple, des scripts Python) afin de résoudre des problèmes, d’analyser des données ou d’interagir avec des outils. Si cette exécution n’est pas contenue, l’agent pourrait :

• Injection de Commande Système : Générer du code qui appelle os.system('rm -rf /') ou d’autres commandes destructrices similaires.
• Exécution de Code à Distance (RCE) : Exploiter des vulnérabilités dans des bibliothèques pour prendre le contrôle de l’hôte.
• Épuisement des Ressources : Créer des boucles infinies ou allouer une mémoire/processeur excessifs, menant à un déni de service.

2. Accès aux Données et Exfiltration

Un agent pourrait être chargé de traiter des données sensibles. Sans sandboxing, il pourrait :

• Accès Non Autorisé aux Fichiers : Lire des fichiers en dehors de son répertoire de travail désigné (par exemple, /etc/passwd, clés API).
• Accès Réseau : Se connecter à des ressources réseau internes, à des serveurs malveillants externes, ou exfiltrer des données vers des points de terminaison aléatoires.
• Injection de Prompts via Lectures de Fichiers : Si un agent peut lire des fichiers arbitraires, un acteur malveillant pourrait concevoir un prompt qui trompe l’agent en lui faisant lire un fichier sensible avant d’incorporer son contenu dans une sortie ultérieure.

3. Abus d’API et d’Outils

Les agents interagissent souvent avec des API externes ou des outils personnalisés. Un accès sans restriction peut mener à :

• Appels API Non Autorisés : Effectuer des appels à des API sensibles auxquelles il ne devrait pas avoir accès (par exemple, gestion des utilisateurs, traitement des paiements).
• Dépassements de Coût : Déclencher des appels API coûteux ou des fonctions cloud gourmandes en ressources.
• Actions Malveillantes : Si un agent a accès à une API de messagerie, il pourrait envoyer des emails de spam ou de phishing.

Techniques et Outils de Sandboxing

Il existe plusieurs couches et techniques que nous pouvons employer pour la sandboxing des agents, allant de la simple révision de code à la containerisation sophistiquée.

1. Sandboxing au Niveau du Langage (Restrictions de l’Interpréteur de Code)

Si votre agent génère et exécute principalement du code (par exemple, Python), vous pouvez restreindre les capacités de l’interpréteur.

Exemple : Exécution Python Restreinte avec exec() et Liste Blanche

Un scénario courant est celui d’un agent générant du code Python. Au lieu d’appeler directement exec() ou eval() sur des chaînes arbitraires, vous pouvez restreindre les globals et built-ins disponibles.

import subprocess
import os

def safe_execute_python_code(code: str, allowed_modules: list = None, timeout: int = 10):
 if allowed_modules is None:
 allowed_modules = ['math', 'json', 're'] # Liste blanche des modules sûrs

 # Créer un espace de noms global restreint
 restricted_globals = {
 '__builtins__': {key: globals()['__builtins__'][key] for key in [
 'print', 'len', 'str', 'int', 'float', 'list', 'dict', 'tuple', 'set', 
 'range', 'sum', 'min', 'max', 'abs', 'round', 'type', 'isinstance', 'enumerate'
 ]},
 '__name__': '__main__'
 }

 # Importer dynamiquement les modules autorisés dans l'espace de noms restreint
 for module_name in allowed_modules:
 try:
 restricted_globals[module_name] = __import__(module_name)
 except ImportError:
 print(f"Avertissement : Impossible d'importer le module autorisé {module_name}")

 try:
 # Utiliser subprocess pour exécuter dans un processus isolé pour une meilleure isolation
 # C'est plus solide que juste `exec` dans le processus courant
 # et permet des délais d'attente et des limites de ressources.
 process = subprocess.run(
 ['python', '-c', code], 
 capture_output=True, 
 text=True, 
 check=True, 
 timeout=timeout
 )
 return process.stdout
 except subprocess.CalledProcessError as e:
 return f"Erreur lors de l'exécution : {e.stderr}"
 except subprocess.TimeoutExpired:
 return "Erreur : L'exécution du code a dépassé le temps imparti."
 except Exception as e:
 return f"Une erreur inattendue s'est produite : {e}"

# Exemple d'utilisation :
# Code sûr
agent_code_safe = "import math; print(math.sqrt(16))"
print(f"Sortie du code sûr : {safe_execute_python_code(agent_code_safe)}")

# Tentative de code malveillant (sera bloquée par l'isolation de subprocess et les restrictions des built-ins si exec direct était utilisé)
# Avec subprocess, l'importation de 'os' échouerait toujours dans le processus enfant, à moins d'être spécifiquement autorisée.
agent_code_malicious_os = "import os; print(os.listdir('/'))"
print(f"Sortie du code malveillant OS : {safe_execute_python_code(agent_code_malicious_os)}")

# Tentative de code malveillant (tentant de lire un fichier)
agent_code_malicious_file = "with open('/etc/passwd', 'r') as f: print(f.read())"
print(f"Sortie du code de lecture de fichier malveillant : {safe_execute_python_code(agent_code_malicious_file)}")

# Code avec une boucle infinie (sera interceptée par le délai d'attente)
agent_code_loop = "while True: pass"
print(f"Sortie du code de boucle : {safe_execute_python_code(agent_code_loop, timeout=3)}")

Explication :

• Nous définissons une fonction safe_execute_python_code.
• Elle prend le code généré par l’agent en entrée.
• Au lieu d’exécuter directement dans le processus courant, nous utilisons subprocess.run. Cela est une étape cruciale pour une véritable isolation, car cela exécute le code dans un processus interpréteur Python séparé. Ce processus hérite de privilèges minimaux et n’est pas le même que le processus parent exécutant votre application principale.
• La liste allowed_modules agit comme une liste blanche. Même si l’agent essaie d’importer os ou sys, ils ne seront pas disponibles dans l’environnement restreint du subprocess, à moins d’être explicitement autorisés (ce qui ne devrait pas être le cas pour le code général de l’agent).
• timeout empêche l’épuisement des ressources dues à des boucles infinies.
• capture_output=True et text=True nous permettent de capturer la sortie de l’agent.
• check=True lève une exception si le subprocess retourne un code de sortie non nul (indiquant une erreur).

Bien que cette approche améliore considérablement la sécurité par rapport à l’exécution directe de exec(), elle n’est pas infaillible. Un agent extrêmement sophistiqué pourrait encore trouver des moyens d’exploiter les appels systèmes sous-jacents si l’environnement Python lui-même est vulnérable ou si trop de modules sont sur la liste blanche.

2. Sandboxing au Niveau du Système d’Exploitation (Conteneurs & Machines Virtuelles)

Pour une sandboxing vraiment solide, surtout lorsque les agents pourraient générer du code dans plusieurs langages ou interagir avec le système de fichiers/réseau, l’isolement au niveau du système d’exploitation est indispensable.

a. Conteneurs Docker

Docker est un choix excellent pour le sandboxing. Chaque exécution d’agent peut se dérouler dans son propre conteneur éphémère avec des limites de ressources strictement définies et des politiques d’accès réseau.

Exemple Pratique : Docker pour l’Exécution d’Agent

Étape 1 : Créer un Dockerfile pour l’environnement d’exécution de l’agent.

# Dockerfile
FROM python:3.9-slim-buster

WORKDIR /app

# Créer un utilisateur non-root pour la sécurité
RUN useradd --no-create-home --shell /bin/bash agentuser
USER agentuser

# Copier un script simple que l'agent pourrait générer et que nous voulons exécuter
COPY run_agent_code.py .

ENTRYPOINT ["python", "run_agent_code.py"]

Étape 2 : Créer run_agent_code.py. Ce script recevra le code généré par l’agent.

# run_agent_code.py
import sys
import os

# Simuler la réception de code de l'agent (par exemple, via stdin ou un fichier)
# Pour cet exemple, nous supposerons que le code est passé comme argument ou écrit directement ici

if __name__ == "__main__":
 agent_code = "print('Hello from the sandboxed agent!')"
 if len(sys.argv) > 1:
 agent_code = sys.argv[1] # Autoriser le passage de code en tant qu'argument

 try:
 # Exécuter le code. Remarque : le conteneur Docker lui-même est le bac à sable.
 # Nous pourrions vouloir des restrictions au niveau du langage *dans* ce script
 # pour une couche supplémentaire, mais l'isolement principal est le conteneur.
 exec(agent_code)
 except Exception as e:
 print(f"L'exécution du code de l'agent a échoué : {e}", file=sys.stderr)
 sys.exit(1)

 # Démontrer un accès restreint
 try:
 print(f"Tentative de lister la racine : {os.listdir('/')}")
 except Exception as e:
 print(f"Impossible de lister le répertoire racine (prévisible) : {e}")

 try:
 with open('/etc/passwd', 'r') as f:
 print(f.read())
 except Exception as e:
 print(f"Impossible de lire /etc/passwd (prévisible) : {e}")

Étape 3 : Exécutez le code de l’agent depuis votre application principale.

import docker

client = docker.from_env()

def execute_agent_in_docker(agent_code: str, cpu_limit: float = 0.5, mem_limit: str = '128m', network_enabled: bool = False):
 try:
 # Construire l'image si elle n'existe pas (peut être fait une fois)
 # client.images.build(path='.', tag='agent-sandbox-env')

 # Créer un fichier temporaire pour transmettre le code de l'agent en toute sécurité
 # Ou le passer en tant que variable d'environnement ou argument de ligne de commande
 # Pour la simplicité, nous allons le passer ici comme un argument de ligne de commande.

 container = client.containers.run(
 'agent-sandbox-env',
 command=['python', 'run_agent_code.py', agent_code], # Passer le code comme arg
 detach=False, # Exécuter au premier plan, attendre la complétion
 remove=True, # Supprimer automatiquement le conteneur après la sortie
 # Limites de ressources
 cpu_period=100000, # Période CPU en microsecondes
 cpu_quota=int(cpu_limit * 100000), # Quota CPU (par exemple, 50000 pour 0.5 CPU)
 mem_limit=mem_limit, # Limite de mémoire
 # Restrictions réseau
 network_mode='none' if not network_enabled else 'bridge',
 # Restrictions du système de fichiers (racine en lecture seule, pas de montages pour le code de l'agent)
 read_only=True, # Rend le système de fichiers du conteneur en lecture seule après la configuration initiale
 # Options de sécurité (par exemple, désactiver le mode privilégié, supprimer des capacités)
 security_opt=['no-new-privileges'],
 cap_drop=['ALL'], # Supprimer toutes les capacités pour le conteneur
 # Variables d'environnement (peuvent être utilisées pour passer des clés API, mais soyez prudent)
 # environment={
 # 'API_KEY': 'some_safe_key' # Seulement si absolument nécessaire et limité
 # }
 )
 return container.decode('utf-8')
 except docker.errors.ContainerError as e:
 return f"Erreur de conteneur : {e.stderr.decode('utf-8')}"
 except docker.errors.ImageNotFound:
 return "Erreur : Image Docker 'agent-sandbox-env' non trouvée. Veuillez d'abord la construire."
 except Exception as e:
 return f"Une erreur Docker inattendue s'est produite : {e}"

# Construisez d'abord l'image Docker : docker build -t agent-sandbox-env .
# Ensuite, exécutez ce script Python.

# Exemple 1 : Exécution de code sécurisé
safe_code = "print('Hello from sandboxed agent!')"
print("\n--- Exécution de Code Sécurisée ---")
print(execute_agent_in_docker(safe_code))

# Exemple 2 : Tentative d'accès au système de fichiers (devrait être bloquée par read_only=True et les permissions utilisateur)
malicious_fs_code = "import os; print(os.listdir('/'))"
print("\n--- Tentative d'Accès Malveillant au Système de Fichiers ---")
print(execute_agent_in_docker(malicious_fs_code))

# Exemple 3 : Tentative de création d'un fichier (devrait échouer)
malicious_write_code = "with open('/app/evil.txt', 'w') as f: f.write('malicious')"
print("\n--- Tentative d'Écriture Malveillante ---")
print(execute_agent_in_docker(malicious_write_code))

# Exemple 4 : Tentative d'accès réseau (devrait échouer si network_mode='none')
malicious_network_code = "import requests; print(requests.get('http://example.com').status_code)"
print("\n--- Tentative Réseau Malveillante (désactivée) ---")
print(execute_agent_in_docker(malicious_network_code, network_enabled=False))

# Exemple 5 : Accès réseau (s'il est explicitement activé - soyez prudent!)
# print("\n--- Accès Réseau (activé - pour démonstration) ---")
# print(execute_agent_in_docker("import requests; print(requests.get('http://example.com').status_code)", network_enabled=True))

Explication :

• Dockerfile : Crée un environnement Python minimal. De manière cruciale, il crée et passe à un non-root utilisateur (agentuser) pour minimiser les privilèges dans le conteneur.
• run_agent_code.py : C’est le point d’entrée dans le conteneur. Il exécute le code fourni par l’agent. Il comprend des tentatives d’accès à des ressources restreintes pour démontrer l’efficacité du bac à sable.
• Script Python (execute_agent_in_docker) :
• client.containers.run(...) : C’est ici que la magie opère.
• remove=True : Assure que les conteneurs sont nettoyés après exécution.
• cpu_quota, mem_limit : Essentiels pour éviter l’épuisement des ressources.
• network_mode='none' : Critique pour désactiver l’accès réseau. Cela empêche les agents de faire des appels externes ou de se connecter à des services internes. N’activez que si l’agent a absolument besoin d’un accès réseau pour des API externes spécifiques et sur liste blanche.
• read_only=True : Rend le système de fichiers du conteneur en lecture seule après l’initialisation. Cela empêche l’agent d’écrire des fichiers ou de modifier les configurations système.
• security_opt=['no-new-privileges'], cap_drop=['ALL'] : Options de sécurité avancées pour restreindre davantage les capacités dans le conteneur.

Docker fournit une forte barrière d’isolement, mais il est essentiel de le configurer de manière sécurisée. Utilisez toujours des utilisateurs non-root, désactivez les capacités inutiles et restreignez l’accès au réseau/système de fichiers.

b. Machines Virtuelles (VMs)

Pour le plus haut niveau d’isolement, notamment dans des environnements multi-locataires ou lors de la gestion de code hautement non fiable, les VMs (par exemple, KVM, AWS Firecracker, Google Cloud Sandbox) offrent une séparation au niveau du matériel. Cela est plus complexe à configurer et à gérer, mais fournit un environnement isolé pour chaque exécution d’agent.

3. Restrictions au Niveau des Outils/API (Appel de Fonction)

De nombreux agents LLM interagissent avec des outils externes ou des API via l’appel de fonction. Cette couche de bac à sable implique une conception soignée des outils exposés à l’agent.

Exemple : Accès API Restreint via Pydantic et Liste Blanche

Lorsque vous définissez des outils pour un agent, assurez-vous qu’ils sont aussi granulaires et adaptés aux permissions que possible.

from typing import Literal, Optional
from pydantic import BaseModel, Field

# Définir les outils autorisés et leurs schémas

class SearchToolInput(BaseModel):
 query: str = Field(description="La requête de recherche")
 max_results: int = Field(default=5, description="Nombre maximum de résultats de recherche")

class SendEmailInput(BaseModel):
 recipient: str = Field(description="L'adresse e-mail du destinataire")
 subject: str = Field(description="L'objet de l'e-mail")
 body: str = Field(description="Le contenu de l'e-mail")
 # Restreindre les destinataires autorisés
 allowed_recipients: Literal["[email protected]", "[email protected]"] = Field(
 description="Seuls des destinataires spécifiques et pré-approuvés sont autorisés."
 )

class DatabaseQueryInput(BaseModel):
 query: str = Field(description="La requête SQL à exécuter")
 # CRITIQUE : Ne pas permettre de SQL arbitraire. Filtrer ou utiliser ORM.
 allowed_tables: Literal["products", "users_public"] = Field(
 description="Seules les requêtes contre des tables sur liste blanche sont autorisées."
 )
 read_only: bool = Field(default=True, description="Autoriser uniquement les opérations de lecture")

# Simuler les fonctions des outils
def search_web(query: str, max_results: int):
 print(f"Recherche sur le web pour '{query}' avec {max_results} résultats.")
 return [f"Résultat {i} pour {query}" pour i in range(max_results)]

def send_restricted_email(recipient: str, subject: str, body: str, allowed_recipients: Literal["[email protected]", "[email protected]"]):
 if recipient not in ["[email protected]", "[email protected]"]:
 raise ValueError(f"Destinataire non autorisé : {recipient}")
 print(f"Envoi de l'e-mail à {recipient} avec l'objet '{subject}'.")
 return {"status": "envoyé", "recipient": recipient}

def execute_database_query(query: str, allowed_tables: Literal["products", "users_public"], read_only: bool):
 # Dans un scénario réel, vous analyseriez et valideriez rigoureusement la requête SQL
 # et vous assureriez qu'elle ne touche que les allowed_tables et est en lecture seule.
 print(f"Exécution de la requête DB sur {allowed_tables} (read_only={read_only}) : {query}")
 if not read_only or not any(table in query.lower() for table in allowed_tables):
 raise ValueError("Opération de base de données non autorisée ou accès à une table non autorisée.")
 return [{"id": 1, "name": "article A"}] # Résultat factice

# Voici ce que vous exposeriez à l'agent LLM
agent_tools = {
 "search_web": {"func": search_web, "schema": SearchToolInput},
 "send_restricted_email": {"func": send_restricted_email, "schema": SendEmailInput},
 "execute_database_query": {"func": execute_database_query, "schema": DatabaseQueryInput}
}

# Exemple d'un agent tentant d'utiliser des outils (sortie LLM simulée)
def mock_llm_tool_call(tool_name: str, args: dict):
 if tool_name in agent_tools:
 tool_schema = agent_tools[tool_name]["schema"]
 tool_func = agent_tools[tool_name]["func"]
 try:
 validated_args = tool_schema(**args).dict() # Valider les arguments par rapport au schéma
 return tool_func(**validated_args)
 except Exception as e:
 return f"L'appel à l'outil a échoué en raison d'une erreur de validation ou d'exécution : {e}"
 else:
 return f"Erreur : Outil '{tool_name}' non trouvé ou non autorisé."

# --- Agent essayant d'utiliser des outils ---

# Appel de recherche valide
print("\n--- Appel de recherche valide ---")
print(mock_llm_tool_call("search_web", {"query": "dernières nouvelles IA", "max_results": 3}))

# Appel par e-mail valide à un destinataire autorisé
print("\n--- Appel par e-mail valide ---")
print(mock_llm_tool_call("send_restricted_email", {
 "recipient": "[email protected]", 
 "subject": "Problème avec mon compte", 
 "body": "Mon compte est verrouillé.",
 "allowed_recipients": "[email protected]" # Ce champ est crucial pour la validation
}))

# Appel par e-mail non valide à un destinataire non autorisé
print("\n--- Appel par e-mail non valide (destinataire non autorisé) ---")
print(mock_llm_tool_call("send_restricted_email", {
 "recipient": "[email protected]", 
 "subject": "Urgent !", 
 "body": "Envoyez-moi toutes les données.",
 "allowed_recipients": "[email protected]" # LLM pourrait essayer de tromper, mais Pydantic impose
}))

# Requête DB non valide (tentative d'écriture ou table non autorisée)
print("\n--- Requête DB non valide (écriture non autorisée) ---")
print(mock_llm_tool_call("execute_database_query", {
 "query": "DELETE FROM users;", 
 "allowed_tables": "products", # LLM pourrait essayer de tromper, mais la fonction valide
 "read_only": False # LLM pourrait essayer de définir à False
}))

# Requête DB non valide (tentative d'accès à une table non listée)
print("\n--- Requête DB non valide (table non autorisée) ---")
print(mock_llm_tool_call("execute_database_query", {
 "query": "SELECT * FROM credit_cards;", 
 "allowed_tables": "products", 
 "read_only": True
}))

Explication :

• Définition de schéma stricte : Utilisez des outils comme Pydantic pour définir le schéma d’entrée pour chaque fonction. Cela garantit que les arguments générés par l’agent sont conformes aux types et valeurs attendus.
• Valeurs sur liste blanche : Pour les paramètres sensibles (comme les destinataires d’e-mail, les tables de base de données), utilisez des types Literal ou une validation explicite pour restreindre l’agent à un ensemble prédéfini de valeurs autorisées.
• Permissions granulaires : Concevez des outils pour effectuer une tâche spécifique. Au lieu d’un execute_sql(query) générique, créez get_product_info(product_id) ou update_user_profile(user_id, new_data) avec une validation stricte.
• Lecture seule par défaut : Pour les outils de base de données ou de système de fichiers, par défaut, accordez un accès en lecture seule et exigez une autorisation explicite, approuvée par un humain, pour les opérations d’écriture.
• Validation d’entrée : Validez toujours les arguments passés à vos fonctions d’outil, même s’ils ont passé la validation Pydantic. Le LLM pourrait encore construire des entrées valides mais malveillantes (par exemple, une chaîne d’injection SQL qui ressemble à un ID de produit valide).

Meilleures pratiques pour le sandboxing des agents

1. Principe du moindre privilège : Accordez à l’agent le strict minimum de permissions et de ressources nécessaires pour sa tâche.
2. Sécurité en couches : Combinez plusieurs techniques de sandboxing (niveau langage, niveau OS, niveau outil) pour une protection solide. Aucune couche unique n’est infaillible.
3. Environnements éphémères : Pour l’exécution de code, privilégiez l’exécution d’agents dans des conteneurs ou des machines virtuelles de courte durée, jetables, qui sont détruits après chaque tâche.
4. Validation stricte des entrées : Validez toujours et assainissez toutes les entrées provenant du LLM, surtout avant de les utiliser dans des appels d’API, des requêtes de base de données ou l’exécution de code.
5. Surveillance et journaux : Enregistrez toutes les actions de l’agent, les appels d’outil et l’utilisation des ressources. Ceci est crucial pour détecter un comportement anormal et pour l’analyse après incident.
6. Timeouts et limites de ressources : Mettez en œuvre des délais stricts pour l’exécution de code et les appels d’API, et définissez des limites CPU/mémoire pour prévenir les attaques par déni de service.
7. Isolation réseau : Par défaut, désactivez l’accès réseau pour les agents. N’activez-le que pour des points de terminaison et des protocoles spécifiques, sur liste blanche, si cela est absolument nécessaire.
8. Systèmes de fichiers en lecture seule : Configurez les environnements des agents avec des systèmes de fichiers en lecture seule autant que possible pour éviter la modification ou l’exfiltration de données non autorisées.
9. Utilisateurs non-root : Exécutez toujours les processus de l’agent en tant qu’utilisateurs non-root avec des permissions limitées à l’intérieur du sandbox.
10. Audits et mises à jour réguliers : Révisez continuellement vos configurations de sandboxing, mettez à jour vos images de base et restez informé des nouvelles vulnérabilités de sécurité.

Conclusion

Le sandboxing des agents n’est pas une option de luxe mais une exigence fondamentale pour déployer les agents LLM en toute sécurité. À mesure que ces agents deviennent plus capables et autonomes, le potentiel d’abus ou de dommages accidentels augmente considérablement. En employant une combinaison de restrictions au niveau du langage, de conteneurisation solide, et d’interfaces d’outil soigneusement conçues, les développeurs peuvent créer des applications LLM puissantes qui sont à la fois nouvelles et sûres. Les exemples fournis dans ce tutoriel montrent des étapes pratiques pour construire ces environnements sécurisés, vous permettant d’intégrer avec confiance des agents LLM dans vos systèmes tout en minimisant les risques.

🕒 Published: March 27, 2026