La sécurité des agents est un problème de plateforme, pas un défi d'ingénierie des prompts

Les agents IA autonomes dépassent souvent leur périmètre prévu non pas en raison d'une intention malveillante, mais à cause de l'accumulation progressive des accès aux outils et des identifiants. Dans une analyse récente, les ambassadeurs CNCF William Rizzo et Francesco Beltramini soutiennent que cette érosion des limites est un problème structurel d'infrastructure plutôt qu'une défaillance de la logique ou des processus de gouvernance des agents.

Ce qui s'est passé

Le problème central identifié est que la puissance effective d'un agent est définie par les outils auxquels il a accès, ce qui s'étend souvent silencieusement avec le temps. Un identifiant limité à une démonstration peut survivre jusqu'en production, ou une délégation ajoutée pour débloquer un déploiement spécifique devient une permission permanente. Cette dérive se produit parce que l'autorité est accordée de manière incrémentale et locale, sans point de décision central. Au moment où les équipes réalisent qu'un agent peut effectuer une action non autorisée, il dispose probablement de cette capacité depuis plusieurs semaines.

De nombreuses organisations tentent de résoudre ce problème par le biais de conseils de gouvernance ou de processus de revue plus stricts. Cependant, ces méthodes régissent les décisions humaines, alors que le problème provient de capacités qui arrivent sans aucune décision explicite. Les auteurs affirment que le processus seul ne peut pas examiner une classe de changement qui n'apparaît jamais comme un événement distinct. Plutôt que de compter sur la vigilance, les systèmes ont besoin d'un substrat qui applique automatiquement les limites, indépendamment de la présence d'un observateur.

Comment cela fonctionne

Compter sur l'agent pour qu'il surveille ses propres limites via des instructions ou des prompts est structurellement défaillant. La sortie d'un agent est une distribution de probabilités, ce qui signifie qu'il choisira généralement la bonne action, mais pourra échouer dans des conditions nouvelles ou adverses. Plus critique encore, même un agent parfaitement conforme exécutera toute action permise par ses outils. Si un agent possède un outil capable de déplacer de l'argent, il peut déplacer de l'argent, malgré les instructions contraires. La capacité prime toujours sur l'intention, car c'est la capacité qui s'exécute réellement.

Pour remédier à cela, les auteurs proposent un Modèle Opérationnel Sûr basé sur des anneaux concentriques de moindre privilège, traitant l'agent comme une charge de travail standard. Le centre est l'Identité, utilisant des identifiants courts et attestés afin que chaque vérification en aval sache exactement qui agit. Le premier anneau, la Portée (Reach), utilise un maillage de services (service mesh) pour imposer quels services un agent peut contacter, empêchant ainsi la croissance silencieuse du graphe. Le second anneau, la Capacité, sépare l'admission (quels outils un agent peut posséder) de l'exécution (ce qu'il peut faire avec eux), exigeant une autorisation par appel.

La clé de voûte de ce modèle est de garantir que l'agent ne puisse pas modifier sa propre configuration. Il doit être privé de la possibilité de modifier les politiques ou les objets qui définissent son autorité. Les changements de limites doivent provenir d'une configuration versionnée gérée par des humains ou des pipelines. Cela crée une colonne vertébrale déterministe pour les flux de travail réglementés, où l'agent fournit des recommandations ou des brouillons, mais où la plateforme impose les portes finales et les approbations.

Détails clés

• Le risque lié aux agents provient de l'accumulation des accès aux outils plutôt que de défauts de conception intentionnels.
• Les contraintes basées sur les prompts sont des suggestions probabilistes, pas des limites de sécurité garanties.
• L'identité doit être vérifiée via des identifiants courts et attestés au niveau de la plateforme.
• La portée est imposée par les maillages de services, bloquant les connexions vers des pairs non déclarés.
• La capacité est divisée entre le contrôle d'admission et l'autorisation par appel au niveau de la passerelle d'outils.
• Les agents ne doivent jamais avoir la permission de modifier les objets de configuration qui définissent leurs propres limites.

Pourquoi c'est important

Pour les ingénieurs logiciels et les responsables techniques, cela déplace la charge de sécurité de la couche application vers la couche infrastructure. Cela signifie que la construction de systèmes agentiques nécessite l'intégration de primitives de sécurité cloud-native telles que l'identité de charge de travail, les maillages de services et la politique-as-code. Les équipes ne peuvent plus traiter les agents comme des boîtes noires gérant leur propre sécurité ; elles doivent explicitement déclarer et appliquer les limites dans lesquelles l'agent opère.

Cette approche modifie également la conception des flux de travail auditables et réglementés. En séparant le travail cognitif de l'agent de l'exécution déterministe des résultats, les organisations peuvent maintenir la conformité. La plateforme enregistre les preuves des vérifications d'identité, de portée et de capacité comme sous-produit de l'opération, offrant une piste claire pour les régulateurs. Cela permet aux agents de gérer des tâches d'interprétation complexes tout en garantissant que les actions critiques, comme les transferts de fonds ou les modifications de données, passent par des portes immuables et revues.

Ce que vous pouvez faire

• Traitez les identités des agents comme des identités de charge de travail de première classe avec des identifiants courts et attestés.
• Implémentez des politiques de maillage de services pour restreindre la connectivité des agents uniquement aux pairs déclarés.
• Utilisez des contrôleurs d'admission pour empêcher les agents de se lier à des outils non approuvés.
• Appliquez une autorisation par appel au niveau de la passerelle d'outils pour valider chaque action spécifique.
• Assurez-vous que les identités des agents se voient explicitement refuser la permission de modifier leurs propres configurations de politique.
• Concevez des flux de travail où les agents émettent des propositions ou des brouillons, laissant l'exécution finale à des pipelines déterministes.