AAIF a annoncé quatre projets supplémentaires le 22 octobre : Agent Skills, Open Responses, OpenEnv et OpenSandbox. Le communiqué de la Linux Foundation place plusieurs couches de l'infrastructure des agents sous une même fondation. Pour les équipes de plateforme, la question opérationnelle est de savoir comment intégrer ces dépendances à un déploiement gouverné.
Le répertoire des projets AAIF décrit Agent Skills comme un format d'instructions, de scripts et de ressources documentaires réutilisables. Un annuaire commun peut aider les équipes à retrouver les projets dont dépendent leurs systèmes. Il ne décide pas des artefacts auxquels une organisation doit faire confiance, des permissions d'un agent ni de la sécurité d'un déploiement précis. Les recommandations suivantes sont l'analyse de Maetra, et non l'affirmation qu'une affiliation à une fondation certifie un système.
Cartographier les composants d'un processus réel
Commencez par un processus capable d'affecter un système métier. Identifiez la connexion au modèle, les paquets d'instructions, les adaptateurs d'outils, l'environnement d'exécution et le dispositif d'évaluation. Consignez les versions et responsables réellement utilisés dans ce déploiement plutôt que le seul nom du protocole ou du framework le plus connu.
Un agent peut dépendre simultanément de plusieurs couches. Une modification d'un paquet d'instructions peut changer sa manière de choisir un outil. Une modification d'un adaptateur peut changer la requête envoyée à une application. Une modification de l'environnement d'exécution peut changer les fichiers ou destinations réseau accessibles. L'inventaire doit rendre ces relations assez visibles pour qu'un responsable évalue une mise à jour proposée.
Le guide Maetra de classification des capacités propose une méthode pratique pour relier la finalité d'un agent à son accès aux données et à ses actions aux conséquences importantes.
Examiner les paquets d'instructions comme des éléments de déploiement
Un format d'instructions portable peut réduire les tâches répétées de configuration. Les équipes doivent néanmoins inspecter le paquet exact qu'elles souhaitent utiliser. Consignez sa source, sa version, son identifiant d'intégrité, ses ressources et ses éventuels scripts exécutables. Identifiez qui peut le mettre à jour et comment les modifications sont reprises dans le déploiement.
Distinguez la lecture d'un paquet de l'autorisation d'exécuter ses suggestions. Un paquet qui explique un processus ne doit pas obtenir le droit d'envoyer des messages, de modifier des enregistrements ou d'installer des logiciels simplement parce qu'un agent peut le charger. Configurez les droits d'exécution dans le système qui contrôle réellement ces effets.
Pour un exercice interne d'acceptation, choisissez un paquet demandant une action sans danger mais hors du périmètre approuvé. Vérifiez que le processus peut lire l'instruction tout en refusant l'effet non autorisé. Vous testez ainsi votre limite de déploiement sans attribuer au format en amont une propriété de sécurité non vérifiée.
Vérifier que les interfaces préservent le sens
Une interface commune n'est utile que si l'application préserve les comportements importants pour ses utilisateurs. Lors d'un changement d'adaptateur de modèle ou d'intégration d'outil, testez la gestion des erreurs, de l'annulation, des nouvelles tentatives, des arguments d'outils et des résultats incomplets.
Utilisez le même scénario délimité avant et après le changement. Comparez l'action voulue à la requête réelle et à l'effet final. Dans un processus de paiement ou de messagerie, un délai d'attente dépassé ne doit pas autoriser automatiquement la répétition d'une action dont l'acceptation demeure inconnue. Un test d'intégration doit rendre cette incertitude visible à l'appelant.
Il s'agit de critères d'acceptation de l'application utilisatrice. Ils ne constituent pas des accusations selon lesquelles un projet AAIF nouvellement annoncé traiterait mal ces situations.
Définir une limite explicite pour l'exécution
Documentez les ressources accessibles à l'agent depuis son environnement d'exécution. Incluez les chemins du système de fichiers, les destinations réseau, l'accès aux identifiants de connexion et les liens vers les systèmes clients. Testez la configuration effective dans l'environnement prévu pour le déploiement.
Un nom de produit évoquant un bac à sable invite à examiner la limite ; il ne démontre pas que votre charge de travail précise est isolée. Vérifiez la configuration administrative des accès, le nettoyage des ressources et l'enregistrement des tentatives bloquées. Maintenez les travaux légitimes dans un périmètre utilisable pour que l'arrêt d'une action non autorisée n'impose pas d'abandonner toute tâche productive.
La liste de contrôle de sécurité des agents en production aide à organiser cette évaluation avec les exigences propres à l'application.
Rendre les mises à jour vérifiables sans figer la pile
Attribuez un responsable à chaque dépendance importante et définissez les changements qui nécessitent un nouveau test d'acceptation. Une correction documentaire, une nouvelle ressource exécutable et un élargissement des permissions réseau ne doivent pas être traités comme un même type de mise à jour.
Conservez la configuration acceptée avec les résultats de test et le contact opérationnel. Lorsqu'une version en amont modifie le comportement, le responsable doit pouvoir identifier les processus concernés et choisir une méthode de déploiement ou de retour arrière. Les équipes peuvent ainsi profiter d'une infrastructure partagée tout en assumant la responsabilité de leur propre déploiement.
L'expansion d'AAIF est une occasion utile de réaliser cette cartographie. Elle ne prouve pas que chaque composant convient à toute charge réglementée ou sensible. Commencez par un agent aux conséquences importantes et utilisez la documentation Maetra pour relier son inventaire, sa politique d'action et ses exigences de preuve avant d'adopter une nouvelle dépendance.