Lorsque l’agent Hermes doit se connecter à des bases de données de production, des comptes cloud, des systèmes de tickets ou des dépôts de code, la première étape doit être la permission en lecture seule, et non la délivrance directe de clés d’écriture. Plus les capacités de l’agent sont fortes, plus il doit séparer les configurations de lecture, écriture, publication et suppression.
Pourquoi simplement le lire en premier ?
Les outils en lecture seule peuvent vous aider à vérifier les connexions, les permissions, les formats de retour et la compréhension du modèle, donc même si les prompts sont mal écrits, cela risque moins de réelles pertes. Si l’outil d’écriture est mal configuré, le risque passe de « réponses inexactes » à « correction de données incorrectes, envoi de mauvais contenu, déclenchement de déploiements incorrects ».
Avant de connecter les outils de production, posez-vous d’abord trois questions : où pouvez-vous consulter les enregistrements d’appels ? Comment révoquer une clé après une fuite ? Une mauvaise opération peut-elle être annulée ? Si ces trois questions restent sans réponse, ne connectez pas l’outil à un agent ou à un point d’entrée distant couramment utilisé.
Ordre de lancement recommandé
La première étape n’accorde que la permission de requête ; Étape deux : autorisations d’écriture sur l’environnement de test ; Troisième étape : écrire les autorisations de production mais réserver l’approbation ; Ce n’est qu’alors que nous devrions envisager l’exécution automatisée. Chaque niveau doit avoir sa propre clé et son journal uniques ; plusieurs environnements ne doivent pas partager un seul jeton.
Pour les équipes, la description de l’outil doit également clairement définir les limites. Un outil appelé « base de données » est trop vague, rendant difficile pour les modèles et les humains d’évaluer les risques ; L’écrire comme « statut d’ordre d’enquête en lecture seule » ou « bibliothèque de test rédigeant des notes d’ordre de travail » clarifie beaucoup les limites de sécurité. Les outils de production ne sont pas inacceptables, mais ils doivent d’abord être auditables, révocables et restreignables.
Si l’entreprise a vraiment besoin d’écrire en production, il est recommandé de décomposer l’action d’écriture en petits outils clairs, tels que « Créer un brouillon », « Note de mise à jour » ou « Déploiement des présets déclenchés », plutôt que de fournir une interface d’exécution universelle. Plus l’outil est spécifique, plus il est difficile pour le modèle de franchir les frontières, et plus il est facile pour les gens d’auditer.
Après la mise en ligne, relisez régulièrement les journaux : quels outils sont les plus appelés, lesquels ont échoué et quelles requêtes ont été rejetées. Les outils de production ne sont pas tous configurés en même temps ; le rétrécissement continu des permissions est la clé d’une stabilité à long terme.
