Sécurité d'un agent IA : suivre la chaîne jusqu'à l'effet réel

Un modèle de langage isolé produit du texte. Un agent IA relié à des outils produit des effets : un ticket fermé, un virement préparé, un fichier supprimé, un e-mail envoyé. Sécuriser l'agent revient donc à sécuriser la chaîne qui relie une demande à un effet, maillon par maillon.

Chaque maillon peut être influencé, mal configuré ou contourné. Le schéma ci-dessous regroupe ces maillons en surfaces ; les sections suivantes les parcourent dans l'ordre où une action les traverse.

1. Prompt et contexte

Le modèle décide à partir de tout ce qui entre dans son contexte : instructions système, message de l'utilisateur, documents récupérés, résultats d'outils, mémoire. Ces contenus n'ont pas tous le même niveau de confiance, mais le modèle les reçoit sous la même forme : du texte.

OWASP distingue la prompt injection directe, portée par l'utilisateur, et indirecte, portée par des contenus externes comme des documents ou des pages web.^[1]

• RAG : un document indexé peut contenir des instructions qui seront récupérées plus tard, pour n'importe quel utilisateur dont la requête le fait remonter ;
• mémoire : une information écrite pendant une session peut influencer les suivantes ;
• résultats d'outils : la réponse d'une API tierce entre dans le contexte au même titre qu'un document.

Filtrer et structurer ce contexte réduit la probabilité d'une mauvaise décision. Cela ne rend pas la décision sûre : OWASP indique qu'aucun mécanisme opérant uniquement dans le modèle ne prévient de façon infaillible la prompt injection.^[1]

2. Identité et credentials

Quand l'agent appelle un système, deux identités sont souvent en jeu : celle de l'agent lui-même, identité non humaine enregistrée dans votre IAM, et celle de l'utilisateur à l'origine de la demande. Les confondre conduit à deux erreurs symétriques : l'agent agit avec plus de droits que l'utilisateur, ou l'on perd la trace de qui a demandé quoi.

L'identité et le credential sont distincts. L'identité dit qui agit ; le token, la clé ou le certificat est le moyen d'agir. Un token longue durée stocké dans la configuration d'un serveur d'outils donne à quiconque le lit la capacité d'agir sous cette identité, sans passer par l'agent.

• Quelle identité l'API voit-elle réellement : l'agent, l'utilisateur, un compte de service partagé ?
• Où le credential est-il stocké, qui peut le lire, quelle est sa durée de vie ?
• Sa portée correspond-elle à la mission de l'agent ou à tout ce que l'API permet ?

3. Outils et MCP

L'agent choisit un outil et construit ses paramètres. Avec MCP, ces outils sont souvent exposés par des serveurs tiers qui détiennent leurs propres credentials. Le guide OWASP consacré à MCP traite notamment de l'empoisonnement des définitions d'outils, des permissions excessives et des tokens trop larges.^[2]

Quatre questions structurent l'analyse : quels outils sont exposés à cet agent, quels paramètres il peut fournir, quelles permissions l'outil utilise en aval, et vers quelles destinations les données peuvent sortir. Un outil export_report qui accepte une adresse de destination libre est un canal d'exfiltration potentiel, même si l'agent n'a jamais été conçu pour l'utiliser ainsi.

4. Autorisation

Le plus petit rôle disponible dans une API reste souvent trop large pour une mission précise. L'autorisation contextuelle pose une question plus fine : cet agent, pour cet utilisateur, peut-il effectuer cette action sur cette ressource, dans ce contexte ?

Le modèle ABAC décrit par le NIST fonde la décision sur des attributs du sujet, de la ressource, de l'opération et de l'environnement, évalués au regard de politiques.^[3]

Dans une architecture agentique, la décision est prise par un Policy Decision Point et appliquée par un Policy Enforcement Point placé sur le chemin de l'appel. Le PEP peut être un proxy MCP, une passerelle d'API ou le service lui-même. La décision n'a d'effet que sur les chemins qui traversent ce point.

5. Runtime

Tout ce que fait un agent ne passe pas par un tool call. Un agent qui exécute du code généré, lance un sous-processus ou dispose d'un accès réseau peut produire des effets qu'aucune politique d'outil ne voit :

• processus : un script lance un binaire non prévu ;
• fichiers : lecture d'un fichier de credentials monté dans le conteneur ;
• réseau : connexion vers une destination absente de toute liste d'outils ;
• credentials : utilisation d'un token de service récupéré dans l'environnement.

La runtime security observe et contraint ce comportement réel du workload. Elle ne dit pas si une action métier est légitime ; l'autorisation ne voit pas ce qui se passe hors des appels qu'elle contrôle. Les deux se complètent.

6. Preuve

Après un incident, ou simplement lors d'un audit, il faut pouvoir reconstruire l'action. Une trace utile relie quatre éléments :

• l'intention : la demande initiale et, si possible, l'étape de raisonnement qui a conduit à l'appel ;
• la décision : la politique évaluée, les attributs utilisés, le résultat ;
• l'action : l'outil, les paramètres, l'identité et le credential employés ;
• le résultat : l'effet observé sur la ressource et au niveau du runtime.

Des journaux épars dans le modèle, le serveur MCP, l'API et le conteneur ne suffisent pas s'ils ne partagent pas un identifiant de corrélation.

Une grille de lecture

Sécurité Agentique organise ces couches selon cinq fonctions. C'est notre grille d'analyse, pas un référentiel externe.

Pour une action sensible donnée, pouvez-vous identifier son identité, son autorisation, son point d'enforcement et son effet ?