Guardrails IA : définition et garde-fous pour sécuriser vos agents

Comment fonctionnent les guardrails ?

Les guardrails contrôlent ce qui entre dans un système d’IA, ce qui en sort et ce qu’il peut faire. Ils agissent à quatre niveaux, et une surveillance en production les complète.

1. L’entrée. Un filtre écarte les requêtes malveillantes ou sans lien avec le métier avant leur envoi au modèle (ANSSI, R25).

2. La sortie. Un filtre retire de la réponse les informations sensibles et en limite la taille (R25). L’OWASP demande aussi de valider chaque sortie avant qu’elle n’atteigne un autre logiciel.

3. Les actions. L’agent IA n’utilise qu’une liste fermée d’outils. Une personne approuve les actions à fort impact : c’est le human in the loop.

4. Les volumes. Des quotas par utilisateur et une limite du nombre de requêtes bornent la consommation, donc la dépense.

Certains filtres sont eux-mêmes des modèles, comme Llama Guard, que Meta a publié en décembre 2023 pour classer requêtes et réponses. Un tel filtre réduit le risque sans le supprimer.

Guardrails ou consigne système : quelle différence ?

Une consigne demande au modèle d’éviter une action ; un guardrail hors du modèle peut la bloquer, même quand le modèle se trompe ou se fait piéger. Selon l’OWASP, aucun contrôle critique ne doit dépendre du modèle : un système extérieur l’exerce, de façon déterministe et vérifiable. Le logiciel que l’agent appelle vérifie donc lui-même chaque autorisation.

Ne confondez pas non plus les guardrails avec le red teaming, qui attaque le système pour en trouver les failles. La prompt injection, elle, désigne l’attaque que ces protections doivent contenir.

Comment sécuriser un agent IA : droits d’accès, OAuth et secrets ?

Sécurisez d’abord les droits de l’agent : il n’atteint que ce que sa tâche exige, selon le principe du moindre privilège. L’OWASP décrit le risque inverse, l’« excessive agency » : trop de fonctions, trop de permissions, trop d’autonomie. L’OWASP cite un exemple : une extension choisie pour lire des documents permet aussi de les modifier et de les supprimer.

• Les autorisations OAuth. OAuth remplace le mot de passe par un jeton d’accès limité à un périmètre (scope) et à une durée. L’OWASP recommande que l’agent agisse au nom de l’utilisateur, avec le périmètre minimal. Donnez-lui pour cela sa propre identité d’agent, distincte du compte de l’utilisateur.

• Les outils connectés. Dans le MCP, l’autorisation reste facultative. Pour un serveur distant, elle repose sur OAuth 2.1, et le serveur doit refuser tout jeton qui ne lui est pas destiné. Un serveur MCP local tourne avec les droits de l’application qui le lance.

• Les secrets. Une clé d’API ne figure jamais dans la consigne : l’OWASP demande de la confier à des systèmes que le modèle n’atteint pas. En mars 2026, un attaquant a repéré sur Internet l’agent d’un chercheur de METR, un organisme qui évalue les modèles d’IA. Il lui a demandé sa clé d’API, puis l’a utilisée pendant trois semaines.

Comment surveiller un système d’IA en production ?

Pour surveiller un système d’IA, suivez en continu ce qu’il fait : requêtes, appels d’outils, réponses, volumes et erreurs. C’est l’observabilité. Le NIST recommande une surveillance régulière après le déploiement (profil NIST AI 600-1, juillet 2024).

• Le journal. L’ANSSI demande de journaliser requêtes, filtrages, appels de plugins et réponses, en respectant les exigences de la CNIL sur la durée de conservation (R29). Pour un système à haut risque, l’AI Act impose au déployeur de garder au moins six mois les journaux générés automatiquement, quand il en a le contrôle (article 26). Cette règle s’applique à partir du 2 décembre 2027 pour l’annexe III et du 2 août 2028 pour l’annexe I.

• Les alertes. METR surveille désormais les usages inhabituels de ses clés et a ajouté des alertes de dépense. Un jeton piège (canary token) complète ce dispositif : un faux secret, comme une fausse clé d’API, dont tout usage déclenche une alerte.

• Les contrôles de l’éditeur. OpenAI décrit un contrôle qui peut arrêter la conversation d’un agent qui semble mal interpréter ses consignes. Ce contrôle tourne en parallèle : une action peut s’achever avant l’alerte, et l’arrêt n’annule rien. OpenAI conseille de garder vos propres garde-fous.

Que changent les guardrails pour votre décision ?

• Réglez chaque garde-fou sur l’effet de l’action. Lire un document, envoyer un courriel hors de l’entreprise et payer une facture n’appellent pas le même contrôle. Plus l’effet pèse, plus la validation humaine s’impose.

• Plafonnez la dépense par clé et par usage. L’OWASP décrit le « déni de portefeuille » (denial of wallet) : l’attaquant exploite la facturation à l’usage des services d’IA. METR ne pouvait fixer aucun plafond sur la clé volée.

• Revoyez les droits chaque mois et à chaque mise à jour. L’ANSSI recommande de revoir régulièrement, par exemple chaque mois, les droits des outils d’IA générative sur vos applications métier (R35). Les réglages par défaut peuvent être trop ouverts. Le NIST demande aussi de revoir régulièrement les guardrails, surtout dans un contexte d’usage nouveau.

• Prévoyez l’arrêt. Désignez qui coupe l’agent, et comment le métier continue sans lui. L’ANSSI demande au minimum une procédure de contournement du système d’IA (R15).