Ledgerline achemine la demande d’assistance d’un employé via une API d’assistant, un fournisseur de modèle et un outil de remboursement. Un ticket Jira contenait un texte demandant le remboursement d’un client ; l’assistant a interprété ce texte comme une instruction, puis le module d’exécution de l’outil a utilisé un compte de service de paiement partagé pour effectuer l’opération. L’auteur de la demande ne disposait pas de l’autorisation de remboursement, mais le système dorsal n’a jamais vérifié les droits du demandeur au moment de l’exécution. Aucun logiciel malveillant ni identifiant volé n’a été nécessaire. Le texte non fiable du ticket a pénétré la boucle de l’agent et a abouti à une opération privilégiée rendue disponible par l’application.
Cette défaillance associe l’injection de prompt (où un texte non fiable modifie le comportement de l’application piloté par le modèle) à une autonomie excessive (où l’application confère à ce comportement une autorité dépassant les droits de l’employé à l’origine de la demande). L’OWASP désigne ces vulnérabilités sous les noms de LLM01 (Injection de prompt) et LLM06 (Autonomie excessive) dans ses directives de 2025, publiées par le projet OWASP GenAI Security en novembre 2024. Le libellé du prompt ne peut pas autoriser un remboursement, car le modèle produit uniquement du texte ; c’est le serveur qui décide si une opération de paiement doit être exécutée.
Le remboursement a été effectué parce que Ledgerline a permis à une demande de franchir plusieurs frontières de confiance sans conserver l’identité de son auteur initial. Un message d’employé est considéré comme non fiable. Un document d’assistance récupéré est également non fiable, même s’il a été stocké par Ledgerline. Le résultat d’un outil constitue une entrée non fiable pour l’appel suivant au modèle. La sortie du modèle est elle aussi non fiable, car une action de « remboursement » proposée ne prouve pas que l’employé est autorisé à l’effectuer.
L’API de l’assistant authentifie l’employé avant de constituer le prompt. L’autorisation de récupération restreint l’accès aux documents en fonction du locataire (tenant) et des droits de l’employé avant que le texte du document ne soit intégré au prompt. Le module d’exécution de l’outil reçoit l’identité authentifiée et les paramètres demandés, puis applique la politique relative à l’action avant de contacter le système de paiement. Le journal d’audit enregistre l’identité de l’auteur, l’action demandée, la décision prise et le résultat. Le fournisseur de modèle génère une action candidate, mais n’accorde jamais d’autorisation. Le chemin de la requête rend chaque frontière visible :
Le cheminement sépare le traitement du texte de la gestion des droits. L’authentification peut rejeter un appelant inconnu, l’étape de récupération peut bloquer l’accès à une fiche client non autorisée, et le point de contrôle de l’outil peut refuser un remboursement même si le modèle le recommande vivement. Un enregistrement d’audit ne peut pas empêcher l’action, mais il permet à Ledgerline d’identifier quel acteur (principal), quelle décision de politique et quels paramètres ont produit le résultat.
Comme chaque étape de contrôle rejette un type d’échec spécifique, Ledgerline renvoie un code d’état stable plutôt que de traiter chaque refus comme une erreur du modèle. 401 Unauthorized indique que la requête présente des identifiants manquants, invalides, révoqués ou compromis. 403 Forbidden signifie qu’un employé authentifié ne dispose pas des droits requis (par exemple, demander un remboursement sans y être autorisé ou tenter de récupérer des données hors du périmètre de ses droits).
D’autres étapes utilisent des résultats plus spécifiques :
409 Conflict indique que la première requête utilisant une clé d’idempotence est toujours en cours d’exécution.422 Unprocessable Content signifie que la sortie du modèle n’est pas conforme au schéma d’action requis par Ledgerline, ou qu’une clé d’idempotence a été réutilisée avec des paramètres différents.429 Too Many Requests (accompagné de l’en-tête Retry-After) indique qu’un locataire (tenant) a atteint sa limite de débit ou de dépenses.503 Service Unavailable signifie que Ledgerline ne peut pas gérer un compteur requis ou qu’un disjoncteur (circuit breaker) bloque l’appel vers le fournisseur.504 Gateway Timeout indique que le fournisseur du modèle a dépassé le délai imparti par Ledgerline.Un code d’état permet d’identifier l’étape qui a pris la décision. Si une recherche client est refusée avant la construction du prompt, Ledgerline renvoie 403 Forbidden ; aucun document récupéré n’est transmis au fournisseur. Si un remboursement proposé contient des paramètres mal formés, le serveur renvoie 422 Unprocessable Content avant que l’exécuteur d’outils ne contacte le service de paiement. Ces résultats transforment le refus en un comportement observable côté serveur (backend), plutôt qu’en une simple phrase au sein d’un prompt système.
Règle d’autorité Une identité de service partagé peut acheminer une requête, mais elle ne doit pas se substituer à l’identité de l’employé (principal) utilisée pour autoriser l’action.
L’incident initial relève du problème du « mandataire confus » (confused deputy). Le module d’exécution des remboursements de Ledgerline disposait de larges droits au niveau du service et a exercé ces droits pour le compte d’un employé ne possédant pas l’autorisation correspondante. Bien que l’API de paiement puisse valider les identifiants de service de Ledgerline, elle ne peut pas vérifier les droits manquants de l’employé si Ledgerline ne transmet pas et ne contrôle pas l’identité de ce dernier. Déplacer le contrôle en amont, au stade de la construction du prompt, laisse la possibilité au texte ultérieur, aux résultats de l’outil et à la sortie du modèle de modifier l’action envisagée.
Le point de contrôle fiable se situe au niveau du gestionnaire d’outils côté serveur ; c’est là que Ledgerline dispose des deux éléments nécessaires à la prise de décision : l’identité authentifiée de l’employé et les paramètres concrets du remboursement. Si les règles de prompt peuvent orienter le comportement du modèle et que le fournisseur peut renvoyer une proposition d’appel d’outil, aucun de ces mécanismes ne garantit l’application de la politique d’autorisation de Ledgerline. À quelle étape le remboursement lié au ticket Jira doit-il être bloqué en priorité : les règles de prompt, le modèle, le gestionnaire d’outils ou l’API de paiement ?