Partager via

Sécurité de l’agent

La création d’agents IA sécurisés est une responsabilité partagée entre agent Framework et développeurs d’applications. Agent Framework fournit les blocs de construction ( abstractions, fournisseurs et orchestration), mais les développeurs sont responsables de la validation des entrées, de la sécurisation des flux de données et de la configuration des outils appropriés pour leur scénario.

Cet article décrit les meilleures pratiques pour la création d’agents sécurisés et sécurisés avec Agent Framework.

Comprendre les limites de confiance

Les données transitent par plusieurs composants lorsqu’un agent s’exécute : entrée utilisateur, fournisseurs d’historique des conversations, fournisseurs de contexte, service LLM et outils de fonction. Chaque limite où les données entrent ou quittent votre application représente une surface d’attaque potentielle.

Les frontières de confiance clés à prendre en compte :

  • Service IA : reçoit des messages de conversation (qui peuvent inclure des informations personnelles et des instructions système) et retourne une sortie générée par LLM.
  • Stockage de l’historique des conversations : les fournisseurs peuvent charger et conserver des messages de conversation via un stockage externe.
  • Services de contexte : les fournisseurs de contexte peuvent récupérer ou stocker des données à partir de services externes (souvenirs, profils utilisateur, résultats RAG).
  • Services accessibles aux outils : les outils de fonction exécutent du code fourni par le développeur qui peut appeler des API ou des bases de données externes.

Toutes les communications de service externe sont gérées par les kits SDK clients choisis par les développeurs. Agent Framework ne gère pas les informations d’authentification, de chiffrement ou de connexion pour ces services.

Bonnes pratiques

Valider les entrées de fonction

L’IA peut appeler n’importe quelle fonction que vous fournissez en tant qu’outil et choisir les arguments. Traitez les arguments fournis par LLM comme une entrée non approuvée, similaire à l’entrée utilisateur dans une API web.

  • Utilisez la liste verte : validez les entrées par rapport aux valeurs connues-bonnes plutôt que d’essayer de filtrer les modèles connus-incorrects. Par exemple, vérifiez qu’un chemin d’accès de fichier se trouve dans un répertoire autorisé plutôt que de vérifier l'absence de .. séquences de traversée.
  • Appliquer les contraintes de type et de plage : vérifiez que les arguments sont du type attendu et dans des plages acceptables (limites numériques, limites de longueur de chaîne, plages de dates).
  • Limiter les longueurs de chaîne : appliquez des longueurs maximales aux arguments de chaîne pour empêcher l’épuisement des ressources ou les attaques par injection.
  • Empêcher la traversée du chemin d’accès : lorsque les fonctions acceptent des chemins de fichier, résolvez-les en chemins absolus et vérifiez qu’ils se trouvent dans des répertoires autorisés.
  • Utilisez des requêtes paramétrables : si des arguments sont utilisés dans des requêtes SQL, des commandes shell ou d’autres contextes interprétés, utilisez des requêtes paramétrables ou des échappements – jamais de concaténation de chaîne.

Exiger l’approbation des outils à haut risque

Par défaut, tous les outils fournis à un agent sont appelés sans approbation de l’utilisateur. Utilisez le mécanisme d’approbation de l’outil pour restreindre les opérations à haut risque jusqu’à leur confirmation par un humain.

Lorsque vous décidez quels outils nécessitent une approbation, tenez compte des éléments suivants :

  • Effets secondaires : les outils qui modifient les données, envoient des communications, effectuent des achats ou ont d’autres effets secondaires doivent généralement nécessiter une approbation.
  • Confidentialité des données : les outils qui accèdent aux données sensibles (PII, données financières, informations d’identification) justifient l’approbation.
  • Réversibilité : les opérations irréversibles (suppression, envoi d’e-mails) sont plus risquées que les requêtes en lecture seule.
  • Portée de l’impact : les outils ayant un impact large (opérations en bloc) doivent nécessiter plus d’examen que ceux limités.

Conserver les messages système contrôlés par les développeurs

Les messages de conversation portent un rôle (system, user, assistant, tool) qui détermine la façon dont le service IA les interprète. Comprendre ces rôles est essentiel :

Rôle Niveau de confiance
system Confiance la plus élevée : forme directement le comportement LLM. Ne doit jamais contenir d’entrée non approuvée.
user Non approuvé : peut contenir des tentatives d’injection d’invite ou du contenu malveillant.
assistant Non approuvé — généré par le LLM, qui est un système externe.
tool Non approuvé : peut contenir des données provenant de systèmes externes ou de contenu influencé par l’utilisateur.

Ne placez pas l'entrée de l'utilisateur final dans les messages de rôle system. Agent Framework associe par défaut le texte non typé au rôle user, mais soyez prudent lors de la construction de messages de manière programmatique.

Fournisseurs d’extensions vétérinaires

Les fournisseurs de contexte et les fournisseurs d’historique peuvent injecter des messages avec n’importe quel rôle, y compris system. Attachez uniquement les fournisseurs que vous approuvez.

N’oubliez pas l’injection d’invites indirectes : si le magasin de données sous-jacent est compromis, le contenu hostile peut influencer le comportement du LLM. Par exemple, un document récupéré via RAG peut contenir des instructions masquées qui entraînent un écart par rapport au comportement prévu ou exfiltrer des données à l'aide d'appels d'outils.

Valider et nettoyer la sortie LLM

Les réponses LLM doivent être traitées comme une issue non fiable. Le service IA est un point de terminaison externe que Agent Framework ne contrôle pas. Soyez attentif aux points suivants :

  • Hallucination : les machines virtuelles peuvent générer des informations plausibles, mais factuelment incorrectes. Ne traitez pas la sortie LLM comme faisant autorité sans vérification.
  • Injection d’invite indirecte : les données récupérées par les outils, les fournisseurs de contexte ou les fournisseurs d’historique de conversation peuvent contenir du contenu contradictoire conçu pour influencer le LLM.
  • Charges utiles malveillantes : la sortie LLM peut contenir du contenu dangereux s’il est rendu ou exécuté sans assainissement (HTML/JavaScript pour XSS, SQL pour injection, commandes shell).

Validez et désinfectez toujours la sortie LLM avant de la rendre au format HTML, en l’exécutant en tant que code, en l’utilisant dans les requêtes de base de données ou en le transmettant à n’importe quel contexte sensible à la sécurité.

Protéger les données sensibles dans les fichiers journaux

Agent Framework prend en charge la journalisation et la télémétrie via OpenTelemetry. Les données sensibles sont journalisées uniquement lorsqu’elles sont activées explicitement :

  • Journalisation — Au niveau de journalisation Trace, la collection complète ChatMessages est consignée. Cela peut inclure des informations personnelles. Trace le niveau ne doit jamais être activé en production.
  • Télémétrie : quand EnableSensitiveData elle est définie, la télémétrie inclut le texte intégral des messages de conversation, y compris les appels de fonction et les résultats. N’activez pas cette option en production.

Sécuriser les données de session

Les sessions (AgentSession) représentent le contexte de conversation et peuvent être sérialisées pour la persistance. Traitez les sessions sérialisées comme des données sensibles :

  • Les sessions peuvent référencer du contenu de conversation ou des identificateurs de session.
  • La restauration d’une session à partir d’une source non approuvée équivaut à accepter une entrée non approuvée. Un back-end de stockage compromis peut modifier les rôles pour augmenter la confiance.
  • Stockez les sessions dans un stockage sécurisé avec les contrôles d’accès et le cryptage appropriés.

Implémenter des limites de ressources

Agent Framework n’impose pas de contraintes sur la longueur d’entrée/sortie ou les taux de requête, car il ne sait pas ce qui est raisonnable pour votre scénario. Vous êtes responsable des opérations suivantes :

  • Limites de longueur d’entrée : limitez la longueur d’entrée pour empêcher le dépassement de contexte ou les attaques DoS.
  • Limites de longueur de sortie : utilisez des limites fournies par le service (par exemple, MaxOutputTokens dans les options de conversation).
  • Limitation du débit : utilisez les installations de limitation de débit pour éviter les dépassements de coûts et les abus des demandes simultanées.

Étapes suivantes

Vue d’ensemble des outils

Contenu connexe

  • Last updated on