Edera implémente des capacités d'objet limitées pour sécuriser les agents IA

Contexte et problème d'autorité ambiante

Les agents d'IA et les charges de travail Kubernetes reçoivent souvent des identifiants globaux (tokens cloud, clés GitHub). Cette autorité ambiante signifie que la compromission d'un processus expose l'ensemble des ressources accessibles par le credential. Les mécanismes classiques – pare-feu, sandbox, gestionnaire de secrets – tentent de restreindre l'usage d'un credential déjà présent, mais ne suppriment pas le risque fondamental lié à la possession du secret.

Principe des capacités d'objet (OCAP)

Un object capability (OCAP) associe deux dimensions : la désignation d'une ressource précise et l'autorité d'exécuter une opération sur celle‑ci. La possession de la capacité constitue la preuve d'autorisation, éliminant le besoin d'un secret réutilisable. Par exemple, la capacité write(project-a) autorise uniquement l'écriture dans le projet project-a, sans exposer les droits sur d'autres projets. Le modèle repose sur des références non falsifiables, rendant l'autorité explicite, transférable et composable.

Mise en œuvre de l'autorité bornée par Edera

Edera introduit les bounded authorities, une déclinaison d'OCAP adaptée aux agents IA et aux pods Kubernetes. Chaque autorité est restreinte à un triplet (ressource, opération, identité). Le broker d'Edera conserve le credential réel (par ex. le token GitHub) et délivre au workload une poignée sans secret. Le workload invoque la poignée via une API interne, comme illustré ci‑dessous :

github.write(repository="acme/payments")
command.execute("git diff")

Dans le premier appel, le workload ne peut modifier que le dépôt acme/payments. Dans le second, il ne peut exécuter que la commande git diff. Aucun token n’est transmis au processus, ce qui empêche un agent compromis d’étendre ses actions au-delà de la capacité accordée.

Implications pour la sécurité des agents IA

Lorsque l'autorité est encapsulée dans une capacité bornée, la compromission d'un agent ne conduit pas à la fuite du credential sous‑jacent. Un LLM qui subit une injection de prompt ne pourra invoquer que les capacités explicitement accordées, par exemple la modification d’un seul dépôt ou l’émission d’une requête API restreinte. Cette réduction de la surface d'attaque repose sur la séparation stricte entre identité (le broker) et autorité (la capacité). Le modèle ne supprime pas les contrôles traditionnels, mais les complète en déplaçant la source d'autorité du secret vers la référence d'objet. Ainsi, les équipes de sécurité peuvent répondre à la question « quelles actions précises cet agent peut‑il exécuter ? » avec une granularité qui n'est pas disponible dans les approches basées sur les rôles ou les politiques réseau.