Comment le contrôle d’accès basé sur les capacités limite-t-il les autorisations des outils des agents ?
Le contrôle d’accès fondé sur les capacités limite un agent en faisant de l’autorité une capacité explicite et liée à une ressource, plutôt qu’une permission ambiante héritée par chaque appel d’outil.
Sur un serveur domestique, cela peut permettre à un agent d’inspecter une cible de sauvegarde, à un autre de redémarrer un service précis et à un troisième de lire un dossier de photos, sans partager un identifiant maître.
Une capacité lie l’autorité à une ressource précise
Le contrôle d’accès fondé sur les capacités représente l’autorité sous la forme d’un jeton ou d’une référence qui identifie un objet et porte les droits disponibles sur celui-ci.
seL4 décrit une capacité comme un jeton infalsifiable qui accorde la permission d’accéder à une entité ou à un objet. La possession fait partie du mécanisme d’autorisation. seL4 représente l’autorité au moyen de capacités qui référencent des objets précis du noyau, fournissant un exemple concret d’autorité liée aux ressources dans le modèle de capacités seL4.
Pour un agent d’IA domestique, un outil de sauvegarde peut recevoir l’autorité sur un seul dépôt plutôt qu’un accès ambiant à l’ensemble du système de fichiers. La connaissance d’un chemin ne suffit pas à accorder une permission.
La possession remplace l’autorité ambiante par une délégation explicite
Les environnements traditionnels exposent souvent une autorité ambiante par l’intermédiaire des identifiants de processus ou de jetons d’API étendus.
Les systèmes de capacités rendent l’autorité explicite dans les références qu’un composant détient réellement.
capDL de seL4 décrit quelles parties d’un système possèdent des capacités sur quelles autres parties. Ces distributions définissent les limites du contrôle d’accès. Wasmtime décrit une isolation orientée capacités pour les ressources WASI, illustrant comment la possession explicite peut remplacer un accès ambiant étendu dans le modèle de sécurité fondé sur les capacités de Wasmtime.
Un sous-agent chargé d’organiser des photos peut ainsi recevoir un accès en lecture à un dossier d’importation et un accès en écriture à une zone de préparation, sans obtenir l’autorité de supprimer des éléments de l’archive.
Les droits peuvent être plus restreints que la ressource
Une capacité peut porter des droits qui limitent les opérations disponibles sur l’objet référencé.
Deux agents peuvent détenir des capacités sur le même objet, avec des niveaux d’autorité différents.
seL4 explique qu’une capacité encapsule une référence d’objet ainsi que des droits d’accès qui contrôlent les opérations autorisées. La Bytecode Alliance a décrit WASI autour de la sécurité fondée sur les capacités, ce qui confirme que les droits accordés peuvent être plus restreints que la ressource hôte elle-même dans la sécurité WASI fondée sur les capacités.
Un workflow de supervision peut détenir l’autorité de lire l’état, tandis qu’un workflow de maintenance détient l’autorité de redémarrer le service. Le service est le même, mais les opérations utilisables ne le sont pas.
La délégation peut transmettre une capacité plus restreinte à une sous-tâche
Les systèmes de capacités conviennent à la décomposition des agents, car l’autorité peut être transmise avec la tâche. Un agent parent peut déléguer uniquement ce dont un assistant a besoin, au lieu de lui transmettre un identifiant maître.
Cap'n Proto modélise les références RPC comme des références qui confèrent également l’autorité d’appeler un objet. Transmettre la référence revient à transmettre une capacité précise. Cap’n Proto RPC traite les références d’objet comme des capacités pouvant être transmises à d’autres composants, ce qui constitue un modèle utile pour l’autorité déléguée dans les capacités d’objet de Cap’n Proto.
Un assistant chargé d’inspecter un seul dossier de journaux peut recevoir une capacité de lecture limitée à ce dossier. Son prompt peut mentionner d’autres ressources, mais l’autorité ne peut pas s’étendre à sa demande.
Les mécanismes de capacité et la portée des outils sont deux niveaux distincts
La portée des outils est un choix de politique qui détermine à quel point l’action d’un agent doit être restreinte.
Le contrôle d’accès fondé sur les capacités est un mécanisme d’exécution qui représente et applique cette autorité.
L’analyse de ZimaSpace sur la portée des outils des agents d’IA domestiques explique pourquoi la portée des actions, des ressources, des arguments et des identifiants doit se réduire à mesure que l’autonomie augmente. Les travaux actuels de l’IETF sur les jetons d’agent avec atténuation étudient une autorité déléguée pouvant être restreinte pour les agents en aval, illustrant la limite de délégation dans le projet sur les jetons d’agent avec atténuation.
L’application des capacités reste importante lorsque la logique de l’agent échoue. L’analyse de ZimaSpace sur les boucles d’appels répétés d’outils montre pourquoi les défaillances comportementales et les limites d’autorité doivent être traitées séparément.
La révocation et les API héritées restent des limites d’implémentation
Les systèmes pratiques doivent toujours pouvoir révoquer une autorité compromise, faire expirer un accès temporaire et faire communiquer des services qui ne comprennent que les utilisateurs, les rôles ou les jetons porteurs.
seL4 expose des opérations de dérivation et de suppression des capacités, mais le comportement de révocation dépend de l’architecture environnante. Le projet cap-std expose les ressources externes sous forme de valeurs de capacité plutôt que de variables globales ambiantes, tout en montrant que les API héritées et la révocation restent des enjeux d’ingénierie distincts dans les API cap-std fondées sur les capacités.
La robustesse d’un wrapper de capacité autour d’une API NAS dépend de celle de la passerelle située derrière. Si chaque requête utilise finalement un jeton administrateur sans restriction, la granularité apparente peut disparaître en aval de cette limite.
Produits recommandés
Centre Tech & IA
Plus à lire
État d’exécution vs état persistant dans Home Assistant : que doit survivre à un redémarrage ?
Home Assistant ne conserve pas chaque valeur en temps réel ; la configuration, les registres, certains états restaurés, l’historique et les données de déploiement...
Comment Home Assistant authentifie-t-il les sessions locales et distantes ?
Les sessions Home Assistant locales et distantes utilisent le même modèle d’identité côté serveur ; l’accès à distance modifie le chemin et la limite...
Pourquoi les requêtes d’historique de Home Assistant peuvent-elles ralentir à mesure que les données de l’enregistreur augmentent ?
L’augmentation du nombre d’enregistrements peut accroître le coût des requêtes d’historique lorsque la plage demandée concerne davantage de lignes, que les défauts de cache...
