Les systèmes multiagents promettent une autonomie certaine, mais ils portent un risque sourd. Lorsqu’un agent délègue une tâche à un autre, le contexte d’autorisation se perd en chemin. Ainsi, un agent peut exécuter des commandes que l’humain n’a jamais approuvées.
Le Top 10 OWASP pour les applications avec agents a déjà baptisé cette menace. On l’appelle ASI03: Abus d’identité et de privilèges. Fondamentalement, le problème naît lorsque l’entité qui agit n’est plus l’humain mais la machine. Par conséquent, les contrôles fondés uniquement sur des rôles échouent lors des transitions automatisées.
Dans cet article, vous allez comprendre comment établir des limites rigides avec AWS Cedar. De plus, vous verrez comment un pipeline à trois couches peut bloquer toute commande non vérifiée avant qu’elle n’atteigne les données de production.
La faille qui naît lorsque qu’un agent délègue une tâche à un autre
Imaginez une chaîne de délégation à multiples sauts. D’abord, l’utilisateur demande quelque chose à l’agent d’orchestration. Ensuite, cet agent déclenche un agent spécialisé. Puis, ce second agent appelle un outil sensible.
À chaque saut, la demande s’éloigne de l’humain qui l’a initiée. Sans limites absolues, l’étendue initiale se dissout. Ainsi, une requête légitime peut faire cascade vers des domaines que personne n’a approuvés.
Le contrôle d’accès basé sur les rôles ne soutient pas ce contexte. Après tout, il a été conçu pour les humains, pas pour les transferts entre machines. Par conséquent, il faut une syntaxe d’autorisation destinée aux agents.
Jetons cryptographiques : où l’identité humaine doit survivre
Chaque mise en production commence par séparer deux éléments. D’un côté, l’établissement de l’identité. De l’autre, l’évaluation des politiques.
Tout d’abord, un fournisseur fiable vérifie l’utilisateur d’origine. Amazon Cognito avec une authentification multifactorielle TOTP remplit bien ce rôle. Ensuite, il délivre un JSON Web Token signé avec des déclarations spécifiques, telles que le rôle, les méthodes d’authentification et les identifiants de session.
Puis, l’utilisateur passe ce jeton et la tâche au premier agent. Ce client du Model Context Protocol intègre le contexte d’origine dans une enveloppe de métadonnées. Ainsi, le système ne fait jamais confiance à des déclarations sans preuve cryptographique.
Le trafic suit ensuite un pipeline séquentiel. Dans un premier temps, AWS WAF applique des filtres contre les vulnérabilités courantes, contrôle du débit et taille du corps. Ensuite, Amazon API Gateway vérifie la signature du jeton contre les clés publiques et rejette les identifiants expirés.
Les requêtes valides passent ensuite à une fonction Lambda dans des sous-réseaux privés. Cette fonction applique les garde-fous d’Amazon Bedrock pour filtrer le contenu. En parallèle, elle fait correspondre les déclarations du jeton avec les attributs de contexte du Cedar.
Préserver l’identité entre les sauts dépend d’une signature. Ainsi, l’adaptateur calcule une signature HMAC avec SHA256 sur le contexte canonique de l’utilisateur. La clé provient du AWS Secrets Manager. Ainsi, chaque évaluateur suivant confirme que le contexte reste intact.
L’échange de jeton OAuth 2.0 restreint encore l’étendue. Lorsque l’orchestrateur délègue une tâche, il remplace le jeton initial par une version réduite. De cette manière, l’agent suivant ne reçoit que l’étendue exacte de la tâche déléguée.
Trois couches Cedar qui bloquent la commande avant la production
Le cœur de la défense réside dans une fonction Lambda d’évaluation. Elle cherche les politiques dans Amazon Verified Permissions. Puis elle évalue trois couches indépendantes en séquence. À la première négation, l’exécution s’arrête.
La première couche régit l’appel des agents vers l’outil. La politique exige que l’agent possède un trust score vérifié, appartienne au namespace correct et opère dans l’étape de production. L’évaluateur lit ces attributs directement depuis le référentiel des entités. Par conséquent, il ne se fie jamais aux métriques rapportées par l’agent lui-même.
Concrètement, un agent avec trust score trois peut accéder à des outils de paiement à risque moyen. Des manipulations de données à risque élevé exigent un trust score quatre.
La deuxième couche régit la profondeur de délégation entre les agents. Un orchestrateur qui déclenche un agent de données doit respecter des limites préétablies. En outre, l’architecture impose un plafond rigide de cinq sauts pour l’ensemble du système. Les tâches demandées doivent aussi correspondre aux capacités enregistrées de l’agent cible. Briser une contrainte met fin à l’exécution.
La troisième couche rattache toute la chaîne au contexte de l’utilisateur. L’agent demeure le principal acteur. Cependant, la politique Cedar inspecte les attributs de l’humain qui a lancé la demande.
Par exemple, effacer des enregistrements de base de données exige une fonction d’administrateur et une authentification multifactorielle vérifiée. Un utilisateur de support qui initie la même chaîne reçoit le refus dans cette troisième couche. De plus, les suppressions à risque élevé respectent un plafond spécifique de deux sauts.
Le test qui sépare le support de l’administrateur
Il est utile de simuler les scénarios pour percevoir la valeur. Considérons un utilisateur de support sans MFA demandant la suppression d’un enregistrement. Le système autorise les interactions entre l’agent et l’outil et entre les agents. Cependant, il bloque l’étape finale faute de privilège humain.
Changez maintenant l’acteur pour un administrateur doté d’une MFA. La même chaîne s’exécute avec succès. Toutefois, si la chaîne automatisée dépasse cinq sauts, même la demande de l’administrateur échoue à la deuxième couche.
Auditabilité qui ne perd aucun événement de décision
Une gouvernance robuste dépend d’une observabilité continue. Pour chaque décision d’accès, la fonction d’évaluation émet un événement OCSF 99001. Cet enregistrement est acheminé vers Amazon CloudWatch Logs.
Les échecs d’envoi des journaux vont directement dans une file d’attente dead-letter sur Amazon SQS. Ainsi, aucune donnée d’audit n’est perdue pendant les pics de trafic. Le payload comporte l’identifiant de la requête, l’identité exacte, la chaîne complète de sauts, les décisions par couche et les métriques de latence.
Enfin, le modèle s’étend sur plusieurs comptes. Vous placez le référentiel de politiques Cedar dans un compte central de sécurité. Ensuite, vous utilisez les service control policies d’AWS Organizations pour imposer une gouvernance centralisée.
Où cela laisse votre équipe
Les architectures multiagent vont se développer, et le risque associé ASI03 croît en parallèle. Les contrôles traditionnels ne parviennent pas à maintenir le contexte lors des délégations complexes entre machines. Par conséquent, des limites cryptographiques et un pipeline Cedar à trois couches offrent le frein qui manquait. Ainsi, votre équipe déploie des agents autonomes en production sans renoncer au contrôle.
Suivez notre profil sur Instagram !
