Avant d’invoquer un outil via MCP ou d’agir en autonomie sur plusieurs étapes, un agent repose sur un mécanisme fondamental : le function calling (appel de fonction). Le function calling permet à un LLM de traduire une demande en langage naturel en une instruction structurée (format JSON), directement exploitable par du code ou une API. En d’autres termes, le modèle ne se contente plus de répondre avec du texte, il prépare l’action technique et en extrait les paramètres.
En passant du simple générateur de texte au système capable de déclencher des actions réelles (requêtes en base, API tierces, outils métier), le LLM change d’échelle. C’est précisément cette transition qui introduit une nouvelle famille de risques, au moment exact où le langage devient une donnée structurée.
Fonctionnement du Function Calling : Du langage naturel à l’appel d’API
Le principe technique est resté stable depuis sa généralisation en 2023 : un modèle reçoit la description d’une ou plusieurs fonctions disponibles, sous forme d’un schéma qui précise leur nom, leur objectif et le type attendu de chaque paramètre. Face à une requête utilisateur, le modèle décide s’il doit invoquer une fonction, laquelle, et avec quels arguments, extraits de la conversation.
Cette structuration en JSON validé contre un schéma a éliminé le parsing fragile et les hallucinations des premières intégrations. Mais si la validation de schéma garantit le format, elle ne garantit en rien l’intention ni la sécurité des données transmises.
Confusion de type et prompt injection : Les failles du function calling
C’est le risque le plus spécifique au function calling, distinct du prompt injection général déjà traité dans l’article dédié, bien qu’il en partage la logique de fond. Lorsqu’un modèle extrait un paramètre depuis le langage naturel (un montant, une date, un identifiant) pour le faire correspondre au schéma attendu, il applique une opération de coercition de type qui peut être détournée.
Une recherche de sécurité récente sur les agents à function calling documente comment cette étape peut être détournée : un texte contenant une indication de type explicite, formulée en langage naturel, peut influencer la valeur que le modèle extrait et transmet à la fonction cible, sans qu’aucun garde-fou classique ne s’en aperçoive, puisque le résultat reste, en apparence, un paramètre valide au format attendu.
Le risque s’aggrave dans les architectures multi-agents, où le paramètre extrait par un premier agent alimente directement l’appel d’un second. Dans ce type de chaîne, chaque point d’extraction constitue une occasion supplémentaire pour une valeur corrompue d’échapper au contrôle à une étape intermédiaire, avant de se répercuter jusqu’à l’appel final.
Gestion des Permissions IA : Éviter les accès excessifs aux API
Le function calling en tant que tel ne porte pas de risque intrinsèque : une fonction qui consulte un horaire d’ouverture ou calcule un itinéraire n’expose rien de sensible même en cas de manipulation réussie. Le risque naît de l’écart entre les fonctions exposées au modèle et celles réellement nécessaires à sa tâche : une fonction d’envoi d’e-mail exposée à un assistant censé uniquement consulter des données, un accès en écriture accordé là où une lecture seule suffirait, une fonction de suppression rendue disponible sans validation intermédiaire.
Dans chacun de ces cas, une manipulation du modèle par injection hérite directement de ce surplus de capacité, indépendamment de la robustesse du mécanisme d’extraction de paramètres lui-même. Chaque fonction exposée à un modèle devrait être traitée comme une extension de son périmètre d’action, avec la même rigueur de revue qu’un nouvel accès accordé à un compte de service.
Bonnes pratiques pour sécuriser le function calling à la source
- Revalider chaque paramètre côté serveur, pas seulement côté schéma : ne pas se contenter de vérifier la conformité au schéma de type ; mettre en place une validation applicative indépendante du modèle (plage de valeurs, contexte métier, règles de cohérence) avant toute exécution.
- Limiter strictement le catalogue de fonctions exposées à chaque contexte : un assistant dédié à une tâche précise ne devrait avoir accès qu’aux fonctions requises pour cette tâche, jamais à un catalogue large exposé par commodité de développement.
- Réappliquer la validation à chaque maillon d’une chaîne multi-agents : ne jamais présumer qu’un paramètre validé par un agent en amont reste fiable une fois transmis à un agent en aval ; revalider les arguments et le contexte à chaque frontière de confiance (chaque appel d’outil, chaque passage d’un agent à l’autre).
- Exiger une confirmation humaine pour les fonctions à impact irréversible : Imposer une validation explicite pour toute fonction susceptible d’avoir un effet irréversible ou à haut risque : suppression de données, envoi de communication externe, transaction financière, modification de permissions, etc.
FAQ : Sécurité du Function Calling et des Agents IA
Qu’est-ce que le Function Calling ?
Le function calling (ou appel de fonction) est la capacité d’un modèle d’IA à convertir une demande en langage naturel en une instruction structurée (ex. JSON) exploitable par une API.
Comment vérifier qu’un agent IA ne dispose pas de privilèges excessifs ?
Commencez par inventorier les fonctions, API, comptes techniques et données accessibles à chaque agent. Retirez les droits inutiles, séparez les accès en lecture et en écriture, et limitez chaque permission à une ressource, une durée et un environnement précis. Cette approche applique le principe du moindre privilège aux agents IA.
Quels appels de fonction doivent obligatoirement être soumis à une validation humaine ?
Prévoyez une confirmation explicite avant toute suppression de données, transaction financière, communication externe, modification de droits ou intervention en production. La demande de confirmation doit présenter l’outil utilisé, la cible et les paramètres exacts afin de permettre une décision éclairée.
Comment documenter et auditer ces contrôles pour nos auditeurs, assureurs et régulateurs ?
En conservant des traces structurées : schémas de fonctions, catalogues exposés par agent, logs d’appels (fonction, paramètres, résultat), décisions du modèle (si disponibles) et validations humaines. Ces éléments permettent de démontrer le respect des principes de moindre privilège, de validation et de traçabilité attendus par les cadres de conformité (RGPD, AI Act, référentiels de sécurité).
Auditer les fonctions exposées à vos systèmes IA
Nos experts évaluent le périmètre réel des fonctions accessibles à vos modèles et agents, et testent leur résistance à la manipulation dans le cadre de notre offre de pentest IA.
Vous souhaitez échanger sur votre projet ou évaluer vos besoins ? Contactez nos experts.