Votre bot de support IA est devenu votre plus grande surface d’attaque : verrouillez-le

Si votre bot de support IA peut réinitialiser un compte, changer un e-mail ou émettre des remboursements, il est de facto votre nouveau compte root. Et oui, des attaquants ont commencé à mener des attaques de social engineering contre des flux de support pilotés par LLM pour obtenir exactement ces pouvoirs. Les incidents récents où des chatbots de support ont été dupés pour accorder des accès devraient clore le débat : placer un large modèle de langage devant la récupération de compte sans garde-fous de capacités n’est pas de l’automatisation, c’est une délégation d’autorité à un système probabiliste entraîné à être serviable.

Ce billet est un plan d’action franc et pratique pour CTO : comment livrer un support piloté par IA qui ne peut pas être amadoué au point de compromettre vos clients. Nous traiterons le LLM comme une interface non fiable, lierons chaque action sensible à des preuves cryptographiques et ferons de la politique la seule voie vers des effets de bord. Les objectifs sont simples et mesurables : zéro prises de contrôle de compte irréversibles (ATO) via le support, moins de 30 secondes de friction ajoutée pour les flux à haut risque, et des preuves auditables pour chaque action privilégiée.

Le schéma d’incident que vous devez présumer

Voici le mode de défaillance courant observé dans les rapports et les exercices de red team :

1. L’attaquant engage l’agent de support IA, invoque une perte de compte urgente (téléphone volé, e-mail compromis, compte d’influenceur attaqué, etc.).
2. L’agent est entraîné à être serviable, il cherche donc des signaux ressemblant à une preuve d’identité (ancien e-mail, chiffres partiels de carte, données publiques), puis déclenche un chemin de récupération via des appels d’outils/fonctions.
3. Des garde-fous de capacité faibles ou absents permettent à l’agent d’initier des changements d’e-mail ou des réinitialisations d’AMF (MFA) à l’aide de signaux ambigus ou usurpables (SMS, e-mail, questions basées sur la connaissance).
4. Résultat : prise de contrôle irréversible, peu de preuves médico-légales sur qui a autorisé quoi et pourquoi.

Si votre pile permet au LLM d’appeler directement des endpoints sensibles lorsqu’il « se sent confiant », vous n’êtes qu’à un prompt d’un gros titre sur une faille.

Premier principe : le LLM est une interface non fiable, pas un acteur

Le modèle de langage ne doit jamais avoir d’accès direct aux API privilégiées. Considérez-le comme un shell activé à la voix qui ne peut que demander des capacités à un moteur de politique. Chaque effet de bord doit être :

• Décrivable explicitement par une capacité typée (pas du texte libre).
• Lié au sujet vérifié (utilisateur, appareil, session).
• Limité dans le temps et le contexte (usage unique, TTL en secondes, cadré par le risque).
• Auditable avec un journal à altération détectable de l’intention, des preuves et de l’approbation.

Le cadre de conception : cinq portes que l’attaquant doit franchir

1) Cadrage : gardez le bot à jeun de PII

Privez l’agent de données sensibles par défaut. La génération augmentée par recherche (RAG) ne doit jamais tirer de la PII brute dans le contexte du LLM sans qu’un contrôle de politique ne l’autorise. Structurez vos outils pour que l’agent puisse poser des questions oui/non ou à divulgation minimale à un « oracle de PII » plutôt que d’ingérer des dossiers complets.

• À faire : exposer des outils comme « vérifier si les 2 derniers chiffres du téléphone de récupération correspondent à X », ne renvoyant qu’un booléen.
• À ne pas faire : exposer à tout moment au LLM des outils « obtenir le profil client complet ».

Cela réduit les fuites et diminue la probabilité que le modèle utilise des signaux faibles comme preuve.

2) Capability DSL, not raw endpoints

Remplacez les appels de fonctions en texte libre par un DSL de capacités étroit et signé. Au lieu de tool : update_email(new_email), définissez tool : request_email_change(user_id, reason), qui renvoie une action en attente nécessitant une confirmation cryptographique hors bande. L’agent propose, votre moteur de politique dispose.

Modèle à copier : des jetons de capacité avec caveats (macaroons). Chaque action sensible requiert un jeton émis par un service de politique qui affirme :

• Sujet : user_id 12345, session_id abc
• Contexte : ip_hash X, device_binding Y, risk_score ≤ 30
• Action : change_email vers le candidat Z
• Contraintes : usage unique, TTL 60s, nonce anti-rejeu N

Sans ce jeton, le service d’action ne peut pas muter l’état — quoi que dise le bot. Inspirez-vous des macaroons, ou utilisez des habilitations de capacité structurées signées par votre clé de politique.

3) Liaison d’identité et réauthentification récente

Les flux à haut risque exigent une preuve de présence, pas des souvenirs. Vous devez imposer :

• WebAuthn/passkeys comme principale réauthentification pour les utilisateurs avec appareil présent. Pas de passkey, pas de récupération instantanée.
• Step-up authentication via une poussée (push) sur l’app mobile avec texte de transaction (par ex., « Approuver le changement d’e-mail vers alice+new@domain.com »).
• Confiance appareil : liez la récupération à un appareil existant et attesté quand c’est possible. Si tous les appareils sont perdus, augmentez le risque et ralentissez.

Les OTP par SMS et e-mail sont des signaux faibles ; traitez-les comme des entrées du score de risque, pas comme un feu vert.

4) Hors bande, cryptographiquement lié à l’intention

Toute récupération qui modifie des identifiants (e-mail, téléphone), désactive l’AMF ou ajoute une nouvelle méthode de récupération doit être confirmée hors bande par un défi signé qui embarque les paramètres exacts de la transaction. Ainsi, même si un attaquant amène le bot à initier un flux, le défi visible par l’utilisateur requiert toujours que l’appareil de la victime approuve le changement spécifique.

Règles de base :

• Les confirmations sortantes doivent afficher précisément les détails de la transaction (nouvel e-mail, dernière IP vue, géolocalisation, horodatage).
• Les défis expirent vite (≤ 5 minutes) et sont liés par nonce au jeton de capacité.
• Si aucun canal de confiance n’existe, imposez une période de refroidissement (p. ex. 24–72 heures) et une revue manuelle.

5) Humain dans la boucle là où ça compte

Vous ne robotiserez pas 100 % de la récupération de compte en toute sécurité. Maintenez une file nearshore staffée pour les flux à haut risque. En règle générale, tout ce qui change simultanément un identifiant et désactive un facteur requiert une personne. Le LLM peut collecter le contexte et rédiger la réponse, mais un humain doit cliquer sur « approuver ». Avec des analystes basés au Brazil, vous obtenez toujours 6–8 heures de chevauchement avec les fuseaux US et 20–30 % de coût en moins vs. un staffing US, sans basculer ce travail en horaires de nuit.

Plan d’architecture livrable ce trimestre

Composants

• Orchestrateur LLM : gère la conversation, planifie les actions, mais ne peut pas appeler directement des API privilégiées.
• Moteur de politique : encode les règles en code (par ex., OPA/Rego ou équivalent). Seul ce service émet des jetons de capacité pour les outils sensibles.
• Service de risque : calcule un score de risque par requête (signaux ci-dessous). La politique le consulte.
• Services d’action : effectuent des mutations uniquement lorsqu’appelés avec un jeton de capacité valide.
• Confirmeur hors bande : push mobile ou cérémonie WebAuthn qui signe l’intention.
• Registre de preuves : journal immuable (stockage WORM) de qui a demandé, qui a approuvé, quel jeton, quel risque.

Signaux de risque qui comptent vraiment

• Provenance de session : première vs. session de retour, âge du cookie, stabilité de l’empreinte TLS.
• Réputation de l’appareil : liaison à un appareil attesté, signaux de jailbreak/root, détection d’émulateur.
• Géovélocité : distance et délai depuis la dernière connexion de confiance ; changements soudains de pays.
• Qualité réseau : qualité d’ASN, IP résidentielle vs. datacenter, rapports d’abus récents.
• Langue et comportement : décalage avec la langue historique de l’utilisateur ; frappes rapides, schémas de copier-coller.
• Contexte de compte : ancienneté, dépense, tentatives de récupération antérieures, statut admin, portée du créateur.

Générez un score de risque continu de 0–100. Définissez des seuils nets dans la politique : en dessous de 20 = self-service + passkey ; 20–60 = step-up + hors bande ; au-dessus de 60 = revue humaine et période de refroidissement. Calibrez sur vos propres données, pas sur des tableaux génériques.

Jetons de capacité : faites de la politique la seule voie vers des effets de bord

Pour chaque outil sensible que l’agent pourrait invoquer, exigez un jeton de capacité signé et à usage unique. Détails d’implémentation pour éviter les ennuis :

• Séparation de l’émetteur : seul le moteur de politique possède la clé privée pour signer les jetons. Les services d’action n’acceptent aucun jeton au porteur provenant de l’agent ou du client web.
• Caveats : embarquez user_id, session_id, seuil de risque, action et paramètres exacts, liaisons IP/appareil, TTL ≤ 60 secondes, nonce.
• À usage unique : les jetons sont consommés à la première utilisation, réussite ou non ; toute relance requiert une nouvelle décision de politique.
• Anti-rejeu : stockez les nonces 10–15 minutes dans un KV store rapide pour détecter les répétitions.

Que vous utilisiez des caveats à la macaroons ou des JWT signés avec des claims structurées, l’idée est la même : le LLM ne détient jamais un pouvoir à usage général, seulement des jetons de capacité à portée étroite.

Confirmations hors bande qui tiennent devant un tribunal

Les confirmations doivent être cryptographiquement liées à la transaction exacte. Bonnes options :

• Défi signé WebAuthn dans une session navigateur connectée.
• Push in-app avec matériau de clé unique à l’appareil stocké dans la Secure Enclave/TPM et attestation distante.

Stockez le défi signé, le texte affiché et un hachage de la conversation dans votre registre de preuves. Si des régulateurs ou des plaignants frappent à la porte, vous pouvez montrer une traçabilité complète et immuable de l’intention et de l’approbation.

Hygiène des prompts et des outils

• Prompts système : ne jamais instruire le modèle de contourner la politique au nom de l’empathie. Supprimez toute variante de « si vous êtes confiant ». La confiance est un trait d’interface, pas un signal de sécurité.
• Décodage contraint pour l’invocation d’outils : les appels d’outils doivent être en JSON avec un schéma vérifié ; rejetez toute déviation.
• Minimisation des données : gardez des fenêtres de contexte courtes ; passez des IDs, pas des blobs ; récupérez à la demande via des outils approuvés par la politique.

Arbitrages à reconnaître auprès de votre CEO

• Friction vs. sécurité : attendez-vous à 15–30 secondes ajoutées pour les flux à haut risque. C’est moins cher qu’un gros titre et une action collective.
• Plafond d’automatisation : vous limiterez les récupérations autonomes à 70–90 % selon votre base d’utilisateurs et l’adoption des passkeys. Le reste part en file humaine.
• Investissement mobile : les confirmations hors bande exigent un support mobile solide. Si vous êtes web-only, priorisez les passkeys ce trimestre.
• Le choix du modèle importe peu comparé à la politique et à la conception des capacités. La différence entre modèles, c’est le vernis UX ; la différence entre conceptions, c’est brèche ou pas brèche.

Ce qu’il faut mesurer : la sécurité est un indicateur produit

• ATO irréversibles via le support : cible 0 pour 100 000 sessions de support/mois.
• Taux de faux négatifs sur les flux risqués captés par la revue humaine : cible ≥ 90 % des demandes réellement malveillantes détournées.
• Latence médiane ajoutée pour les récupérations risquées : cible ≤ 30 s.
• Volume de revue humaine : suivez-le en % du total ; utilisez-le pour dimensionner votre équipe nearshore. Ratio de départ : 1 analyste pour 10–20 k MAU pour les apps grand public ; le B2B est plus bas mais à plus forte conséquence.
• Mauvaise utilisation des jetons : tout jeton de capacité rejeté pour violation de caveats doit alerter l’astreinte. Si ce nombre est non nul, investiguez des trous de politique.

Faire du red teaming de votre bot comme un attaquant

N’attendez pas qu’internet teste vos garde-fous. Construisez un « parcours de jailbreak » interne et faites-y passer chaque révision de modèle/prompt. Utilisez des transcriptions adversariales sélectionnées qui tentent de :

• Déclencher des réinitialisations avec des narratifs empathiques et de l’urgence.
• Exploiter des prompts non anglophones ou des mots de code.
• Demander au bot de résumer ou reformater des secrets (tentative de tirer de la PII dans le contexte).
• Contraindre le bot à contacter « la sécurité » à une adresse contrôlée par l’attaquant.

Publiez les taux de réussite/échec à votre direction et incluez-les dans les critères de release. Envisagez d’emprunter des modèles issus des travaux académiques sur la sécurité des agents et l’usage des outils ; les poids exacts des modèles comptent moins que la discipline des tests et de la politique.

Un plan 30–60–90 jours qui ne mourra pas en comité

Jours 0–30 : arrêter l’hémorragie

• Retirez l’accès direct à tout endpoint qui change des identifiants ou désactive l’AMF de vos outils LLM.
• Introduisez un service de politique qui doit signer des jetons de capacité pour les outils sensibles ; simulez le reste.
• Livrez une confirmation hors bande minimale viable pour les changements d’e-mail via push in-app ou WebAuthn.
• Commencez à journaliser chaque tentative d’action sensible et le hachage de la conversation vers un stockage WORM.

Jours 31–60 : relever la barre

• Déployez un service de scoring de risque et implémentez des seuils de politique pour l’activation d’outils.
• Contraignez l’invocation d’outils à un schéma JSON strict avec vérification de signature ; rejetez les appels mal formés.
• Activez des périodes de refroidissement pour les flux à haut risque quand aucun appareil de confiance n’est disponible.
• Staffez une file de revue nearshore en heures ouvrées ; mesurez le taux de diversion et la latence de décision.

Jours 61–90 : rendre ça banal

• Durcissez les jetons de capacité avec liaisons appareil/IP, TTL de 60 secondes et nonces à usage unique.
• Étendez le hors bande à tous les changements d’identifiant et réinitialisations AMF ; soignez le libellé de la transaction.
• Codifiez la politique dans OPA/Rego (ou votre moteur choisi) et soumettez-la à revue de code et CI, comme votre code applicatif.
• Automatisez les tests de régression de red team et exigez des scores de passage pour chaque changement de prompt/modèle.

Pourquoi le nearshore au Brazil aide ici

Quand vous acceptez que 10–30 % des flux doivent être revus par des humains, votre économie unitaire dépend du staffing et du chevauchement horaire. Le Brazil vous offre 6–8 heures de chevauchement avec les fuseaux US, des analystes seniors à l’aise en anglais et portugais/espagnol, et 20–30 % d’économies vs. un recrutement US. Plus important, vous gardez la prise de décision privilégiée dans vos fuseaux internes — pas d’escalades à 2 h du matin, pas de « validation automatique » offshore.

L’essentiel

Vous ne résoudrez pas ce problème avec des prompts. La bonne réponse est architecturale : des jetons de capacité émis par la politique, limités dans le temps et le contexte ; des confirmations hors bande cryptographiquement liées à l’intention exacte ; et un moteur de risque qui accélère ou détourne les flux suspects vers des humains. Le LLM est une interface brillante pour collecter du contexte et expliquer des décisions, mais tant qu’il ne peut pas détenir une crédential de sécurité, il ne doit jamais être celui qui tire le levier.

Points clés

• Traitez le LLM comme une interface non fiable ; il propose, il ne dispose pas.
• Utilisez des jetons de capacité signés, à usage unique et avec des caveats stricts pour chaque action sensible.
• Liez la récupération à une preuve de présence (passkeys, push in-app), pas à des souvenirs ni au seul e-mail/SMS.
• Construisez un moteur de risque et définissez des seuils de politique qui conditionnent l’activation des outils.
• Attendez-vous à 10–30 % d’humain dans la boucle pour les flux à haut risque ; le nearshore aide à contenir les coûts et la latence.
• Journalisez intentions, jetons, approbations et hachages de conversation dans un registre de preuves WORM.
• Automatisez des tests adversariaux et intégrez-les aux critères de release pour prompts/modèles.