Agents IA et plusieurs comptes cloud : associer chaque action

Des agents IA opérant sur plusieurs comptes cloud ne sont sûrs que lorsque chaque requête nomme une frontière de compte immuable et que l’exécuteur refuse toute discordance. Un agent capable de dire « déployer en production », mais incapable d’identifier le compte AWS, l’abonnement Azure ou le projet Google Cloud associé à ce terme, dispose d’une autorité ambiguë.

Les équipes présentent souvent cela comme un simple nettoyage IAM. C’est un problème de conception de l’exécution. IAM peut accorder correctement des accès à deux comptes alors que l’agent, son wrapper ou un profil shell choisit toujours le mauvais. Dans ce cas, un identifiant parfaitement valide effectue une modification parfaitement valide au mauvais endroit.

La solution est moins spectaculaire qu’un modèle d’autorisations ingénieux. Définissez à l’avance des cibles exécutables, associez chacune à des identifiants attribués par le fournisseur et à une identité d’exécution dédiée, demandez à l’agent de sélectionner une cible par handle, puis vérifiez l’appelant juste avant tout appel qui modifie l’état. Les noms d’environnement lisibles restent utiles, mais ils ne doivent pas décider de l’endroit où le code s’exécute.

Les cibles ambiguës créent une véritable autorité

Une étiquette d’environnement n’est pas une frontière d’autorité. « Production » indique à une personne l’usage prévu des ressources par l’équipe. Elle n’indique pas à une API quel compte AWS, abonnement Azure, projet Google Cloud, locataire, région ou rôle assumé doit recevoir la requête.

Cette distinction peut sembler tatillonne jusqu’à ce qu’une entreprise ait prod, production, prod-old et production-sandbox répartis dans plusieurs organisations. J’ai vu des alias de comptes copiés pendant des migrations, des profils shell obsolètes pointer vers des comptes retirés et une simple opération de lecture arriver dans le compte que les personnes chargées de la réponse à incident tentaient de préserver. Les agents aggravent le problème, car ils prennent les étiquettes en langage naturel au pied de la lettre et peuvent agir bien plus vite que la personne qui remarque l’ambiguïté.

Une cible doit répondre à toutes ces questions avant l’exécution :

• Quel fournisseur possède la ressource ?
• Quelle frontière de compte immuable reçoit l’appel ?
• Quel environnement l’organisation attribue-t-elle à cette frontière ?
• Quelle identité d’exécution peut agir à cet endroit ?
• Quelles limites géographiques ou organisationnelles s’appliquent ?

L’ordre compte. La frontière de compte vient avant l’étiquette d’environnement. Si une requête indique environment: production, mais ne contient pas d’ID de compte ou d’abonnement, elle est incomplète. Refusez-la plutôt que de demander à l’agent de déduire le détail manquant à partir du nom d’un dépôt, du titre d’un ticket ou de sa configuration de terminal actuelle.

Une recommandation fréquente, mais mauvaise, consiste à dire que les conventions de nommage des comptes règlent le problème. Elles aident les personnes à parcourir une liste, mais ne constituent pas un contrôle. Les noms sont des chaînes modifiables. Un ID de compte, un ID d’abonnement, un ID de locataire, un numéro de projet, un UID de cluster et un ARN de rôle sont des références attribuées par le fournisseur qui établissent beaucoup mieux l’identité.

Une étiquette d’environnement ne doit pas choisir un compte

Traitez l’environnement comme une métadonnée contrôlée attachée à une fiche de cible, et non comme une entrée qui résout une cible au moment de l’exécution. Ainsi, une requête comme « appliquer ce correctif de production » ne parcourt pas un inventaire actif pour sélectionner le compte dont une étiquette correspond par hasard.

Cette distinction a une conséquence pratique. Votre catalogue de déploiement peut contenir plusieurs cibles avec environment: production : paiements, outils internes, services régionaux et comptes issus d’acquisitions. Chacune reste une destination distincte. L’agent doit sélectionner un handle approuvé, comme aws-prod-payments, au lieu d’envoyer un sélecteur large tel que environment=production.

Utilisez les identifiants du fournisseur qui établissent la frontière réelle :

| Fournisseur | Associer à | Ne pas utiliser comme référence |\n| --- | --- | --- |\n| AWS | ID de compte, partition, ARN de rôle, région autorisée | Alias de compte, nom de profil, nom d’affichage du rôle |\n| Azure | ID de locataire, ID d’abonnement, portée du groupe de ressources si nécessaire | Nom d’affichage de l’abonnement, sélection de l’annuaire dans le portail |\n| Google Cloud | Numéro et ID de projet, organisation ou dossier si nécessaire | Nom d’affichage du projet, configuration locale active |

L’ID de projet Google Cloud est généralement assez stable pour être utile dans les requêtes, tandis que le numéro de projet fournit un contrôle immuable supplémentaire. Azure nécessite à la fois le locataire et l’abonnement, car un abonnement seul ne décrit pas le contexte d’identité qui a émis un jeton. Dans AWS, un numéro de compte seul n’indique pas quel rôle l’action utilisera. Associez les deux.

Ne dissimulez pas ces informations dans le texte d’une invite. Une instruction d’agent disant « ne touchez jamais à la production » ne peut pas arrêter un identifiant qui autorise déjà l’action. L’exécuteur de confiance doit disposer de la fiche de cible et décider si l’identité et la destination demandées lui correspondent.

Un registre de cibles doit contenir des faits, pas des suppositions

Conservez un registre réduit et révisé des cibles cloud exécutables. Ce n’est pas un second système IAM et il ne doit pas tenter de reproduire toutes les autorisations cloud. IAM cloud décide toujours si un rôle peut appeler une API. Le registre répond à une question plus précise : où cette requête peut-elle aller lorsqu’elle utilise ce handle de cible ?

Cet exemple utilise des identifiants fictifs, mais sa structure est volontaire :

targets:
  aws-prod-payments:
    provider: aws
    environment: production
    account_id: "482901736154"
    partition: aws
    role_arn: "arn:aws:iam::482901736154:role/agent-payments-deploy"
    regions:
      - us-east-1
      - us-west-2

  azure-prod-fulfillment:
    provider: azure
    environment: production
    tenant_id: "2f34c630-1ce8-4ed3-a7ce-8a3286e799a1"
    subscription_id: "841742bf-9db5-4cf8-9f6b-f1778d5b7511"
    scopes:
      - "/subscriptions/841742bf-9db5-4cf8-9f6b-f1778d5b7511/resourceGroups/fulfillment-prod"

  gcp-prod-catalog:
    provider: gcp
    environment: production
    project_id: "catalog-prod-417"
    project_number: "548201736915"
    parent: "organizations/193847561029"

Le registre doit être géré comme une configuration de production. Attribuez à chaque cible une équipe responsable, un processus de révision et une date ou un statut de retrait lorsque le compte quitte le service. Sinon, les anciennes cibles deviennent discrètement une carte des endroits encore accessibles à un agent.

Ne créez pas de fiches à partir d’une découverte libre en autorisant immédiatement leur exécution. Les API d’inventaire cloud sont utiles pour trouver les comptes auxquels il faut attribuer un responsable. Elles ne constituent pas des décisions d’autorisation. Un compte découvert peut être une copie forensique, un abonnement géré par un fournisseur, un reste d’acquisition ou un locataire de test partageant des étiquettes trompeuses avec la production.

Le registre évite aussi un problème subtil de dérive. Une personne peut renommer un abonnement Azure ou un rôle AWS sans modifier l’ID immuable. L’étiquette d’affichage peut changer pour faciliter la lecture, tandis que la liaison reste intacte. Si l’ID immuable change, traitez-le comme une nouvelle cible qui nécessite une révision, même si le nom reste identique.

L’agent doit demander un handle, jamais composer une destination

Un agent doit envoyer une intention et un handle de cible. Il ne doit pas envoyer un ARN de rôle copié depuis une commande, un nom de profil cloud arbitraire ou une commande shell contenant un abonnement choisi par l’utilisateur. Ces champs donnent à l’agent le contrôle de la partie la plus sensible de la requête.

Une requête peut rester aussi simple que celle-ci :

{
  "request_id": "chg-8a31f6",
  "target": "aws-prod-payments",
  "operation": "aws.ec2.reboot_instances",
  "region": "us-east-1",
  "arguments": {
    "InstanceIds": ["i-0abc123def4567890"]
  },
  "reason": "Recover the failed checkout worker after approved release"
}

L’exécuteur résout aws-prod-payments à partir de la fiche qu’il détient déjà. Il assume uniquement le rôle listé, refuse eu-west-1 puisque cette région ne figure pas dans la fiche, puis envoie la requête avec l’identité du compte sélectionné. L’agent ne reçoit jamais d’identifiant cloud réutilisable dans cet échange.

L’échec évité est facile à reconnaître. Un agent exécute une commande avec --profile prod, mais le profil local prod d’un développeur pointe vers le compte de services partagés. La commande est syntaxiquement correcte, l’API l’accepte et l’équipe ne découvre l’erreur que lorsque le worker de paiement attendu fonctionne toujours. Un handle de cible résolu en dehors de l’agent, suivi d’une vérification d’identité, arrête la commande avant que la requête de redémarrage ne quitte l’exécuteur.

N’acceptez pas à la fois un handle et une destination fournie par l’appelant « pour plus de flexibilité ». Vous créeriez deux sources de vérité. Si une requête contient target: aws-prod-payments et un autre ARN de rôle, l’exécuteur doit la refuser. Il ne doit jamais choisir le champ qui semble le plus précis.

Vérifiez l’appelant actif avant une écriture

Une fiche de cible fixe est nécessaire, mais elle ne prouve pas que l’identifiant actif est celui prévu. Les jetons expirent, les changements de rôle échouent ou basculent, des profils locaux se transmettent à des sous-processus et les SDK cloud peuvent utiliser des chaînes de fournisseurs d’identifiants inattendues. Vérifiez l’identité active juste avant tout appel qui modifie l’état.

Pour AWS, AWS documente GetCallerIdentity comme renvoyant le compte, l’ARN et l’ID utilisateur de l’identité appelante. Sa documentation précise aussi que l’appel renvoie ces informations même lorsqu’un refus explicite empêcherait normalement l’opération. Cela en fait un bon outil de diagnostic et de contrôle préalable. Il n’accorde aucune autre permission et ne remplace pas la comparaison avec la fiche attendue.

Une commande de contrôle préalable produit une sortie de ce type :

aws sts get-caller-identity --output json

{
  "UserId": "AROAEXAMPLEID:agent-run-8a31f6",
  "Account": "482901736154",
  "Arn": "arn:aws:sts::482901736154:assumed-role/agent-payments-deploy/agent-run-8a31f6"
}

Comparez Account à account_id de la cible. Analysez l’ARN et comparez le rôle assumé au rôle configuré. N’utilisez pas un test de sous-chaîne tel que « l’ARN contient payments ». Refusez une partition, un compte ou un rôle différent avant l’appel d’écriture.

Appliquez le même modèle ailleurs. Dans Azure, interrogez le locataire et l’abonnement actifs, puis comparez-les tous deux à la cible sélectionnée. Dans Google Cloud, interrogez le projet actif et le principal authentifié, puis validez le projet par rapport à la fiche avant tout appel d’API modificatif. Ces contrôles doivent s’exécuter dans le même contexte de processus que celui qui envoie l’action. Vérifier un terminal et exécuter dans un autre ne procure qu’un faux sentiment de sécurité.

Les contrôles préalables ont une limite : un rôle peut être correct tout en étant trop permissif. Le rôle cloud lui-même doit toujours respecter le principe du moindre privilège pour la cible qui lui est attribuée. La liaison empêche une requête de passer dans un compte inattendu. IAM limite ce que l’identité correcte peut faire une fois arrivée au bon endroit. Les deux contrôles sont nécessaires.

Les rôles intercomptes trop larges cachent l’erreur jusqu’au moment critique

Un rôle administrateur capable d’assumer un rôle dans tous les comptes est populaire parce qu’il réduit le travail de configuration. Il transforme aussi la sélection de cible en décision irréversible et fortement risquée. Si l’agent ou l’exécuteur choisit le mauvais compte, cette même identité large dispose souvent d’un accès suffisant pour mener l’erreur à son terme.

Séparez les rôles d’exécution par compte et par usage. Un rôle de déploiement de production pour les paiements ne doit pas disposer aussi d’un chemin de confiance vers les comptes d’analytique, d’identité ou de reprise après sinistre. Lorsqu’un agent a besoin d’un accès en lecture à plusieurs comptes, utilisez des rôles de lecture distincts et rendez la liaison de cible visible pour chaque appel. L’accès en lecture peut exposer des données client, la topologie de l’infrastructure et des identifiants stockés au mauvais endroit. Le qualifier de lecture seule ne rend pas les erreurs de sélection inoffensives.

Utilisez les conditions de confiance natives du cloud pour limiter la manière dont un rôle peut être assumé. Les politiques de confiance des rôles AWS peuvent restreindre le principal approuvé et exiger un identifiant externe lorsque ce modèle correspond à l’appelant. Les identités de charge de travail Azure peuvent être limitées par les revendications des identifiants fédérés et les attributions de rôles aux ressources. L’emprunt d’identité d’un compte de service Google Cloud peut limiter les personnes autorisées à créer un jeton d’accès. Le mécanisme varie, mais la conception reste la même : une identité d’exécution doit correspondre à une destination et à un usage révisés.

Ne confondez pas une identité de courtier central avec une autorité large. Un courtier peut coordonner les requêtes de nombreuses cibles tandis que chaque requête obtient une identité propre à sa cible. La configuration demande plus de travail qu’un rôle administrateur universel. Elle rend aussi la portée d’une erreur lisible lorsqu’un processus, une invite ou une intégration se comporte mal.

L’approbation doit montrer une destination vérifiable par une personne

Une personne ne peut pas approuver une action sûre si l’approbation masque la frontière du compte. « Redémarrer le worker de paiement en production » demande au réviseur de faire confiance à une logique de résolution invisible. L’approbation doit afficher le handle de cible, l’étiquette d’environnement, l’identifiant de compte immuable, le rôle ou l’identité de service actifs, l’opération et la portée des ressources que l’API va affecter.

Pour le redémarrage d’une instance AWS, une approbation utile ressemble à ceci :

Target: aws-prod-payments
Environment: production
Account: 482901736154
Identity: agent-payments-deploy
Action: ec2:RebootInstances
Region: us-east-1
Resource: i-0abc123def4567890
Reason: Recover failed checkout worker after approved release

Ce niveau de détail n’est pas une mise en scène de l’approbation. Les réviseurs connaissent souvent le numéro de compte ou le handle de cible de leur propre service, tandis que la description en prose d’un agent peut être plausible et fausse. Rendez la destination suffisamment visible pour être parcourue avant la description de l’action. Les personnes remarquent plus facilement un numéro de compte surprenant qu’une divergence subtile enfouie dans une charge de commande.

Ne demandez pas une approbation générale de « tout le travail de cette session » lorsque la session couvre plusieurs comptes de production. Une session peut avoir une frontière légitime, par exemple plusieurs modifications répétées sur une cible de déploiement, mais cette frontière ne doit pas s’élargir discrètement. Exigez une nouvelle approbation lorsque le handle change, lorsqu’une opération passe de la lecture à l’écriture ou lorsqu’une requête touche une portée plus sensible que celle approuvée par le réviseur.

L’autorisation par session de Sallyport identifie le processus connecté et son réglage d’identifiants par appel peut exiger une approbation à chaque utilisation. Cela n’est utile que si la requête d’action porte une cible reconnaissable par le réviseur et si l’exécuteur l’a déjà associée à une seule destination.

Les journaux doivent relier intention, identité et preuves du fournisseur

Les journaux d’audit cloud indiquent quelle identité a appelé une API, mais expliquent rarement l’instruction de l’agent, la sélection de la cible ou la décision du réviseur. Les enregistrements côté agent expliquent l’intention, mais ne prouvent pas que le cloud a reçu l’appel attendu. Conservez les deux types d’enregistrements et reliez-les avec un ID de requête et les identifiants immuables de la cible.

Pour chaque action, enregistrez ces champs avant et après l’exécution :

• Le processus ou la session de l’agent à l’origine de la requête
• Le handle de cible sélectionné et les identifiants immuables résolus
• L’identité d’exécution observée pendant le contrôle préalable
• L’opération, la portée de la ressource, le résultat et l’ID de requête
• La référence de l’événement d’audit du fournisseur lorsqu’il en fournit une

AWS CloudTrail, Azure Activity Log et Google Cloud Audit Logs enregistrent chacun l’activité côté fournisseur, selon les services utilisés et la configuration de journalisation. Conservez ces enregistrements dans leur propre frontière de sécurité. Ne considérez pas le journal d’activité d’un agent comme un substitut aux preuves du fournisseur, car un processus local compromis pourrait mentir sur une requête qu’il n’a jamais exécutée.

Sallyport enregistre les exécutions des agents et les appels individuels dans des journaux distincts, projetés depuis un journal d’audit chiffré et chaîné par hachage. Sa commande sp audit verify peut vérifier cette chaîne hors ligne sur le texte chiffré, ce qui aide à déterminer si les enregistrements locaux d’action ont été modifiés après un incident.

Le test pratique est un exercice d’enquête. Choisissez une modification approuvée et demandez à un ingénieur de répondre à quatre questions sans deviner : quel processus agent l’a demandée, quelle cible il a sélectionnée, quelle identité cloud l’a exécutée et quel événement côté fournisseur la confirme. Si une réponse exige de rapprocher manuellement des horodatages dans trois consoles, vos enregistrements sont trop faibles.

Un incident dans le mauvais compte commence généralement avant l’appel à l’API

L’échec visible est souvent une modification de production dans le mauvais compte. L’échec antérieur est généralement un chemin de résolution incontrôlé. Traitez l’incident comme un défaut de liaison, pas seulement comme le fait qu’une personne a « utilisé le mauvais profil ».

Considérons une séquence plausible. Un dépôt contient un script qui accepte ENV=prod. Son wrapper traduit cette valeur en profil AWS nommé prod. Pendant une migration, un développeur a modifié ce profil pour qu’il pointe vers un compte de services partagés, car l’ancien compte de paiements ne nécessitait plus d’accès direct. Plus tard, un agent reçoit une requête de redémarrage d’un worker de paiement. Il trouve le script, définit ENV=prod et l’exécute. La résolution du profil pointe vers les services partagés. Le rôle dispose de larges permissions EC2, car l’équipe l’utilisait pour simplifier les opérations. Le redémarrage réussit dans le mauvais compte.

Aucune partie de l’API cloud n’était confuse. Le script a envoyé une requête valide avec une identité valide. Une correction post-incident qui se contente de dire aux agents de « vérifier deux fois le compte » échouera à nouveau, car elle conserve le même chemin de résolution.

Corrigez ce type d’échec dans l’ordre suivant :

1. Désactivez la session ou le chemin de rôle concerné et conservez les journaux d’audit de l’agent et du cloud.
2. Identifiez le sélecteur exact qui a choisi la mauvaise destination, comme un nom de profil, un abonnement par défaut, une étiquette d’environnement ou un ARN de rôle fourni par l’appelant.
3. Remplacez ce sélecteur par un handle de cible approuvé, résolu par l’exécuteur.
4. Ajoutez une comparaison de l’identité active qui refuse toute divergence avant les écritures.
5. Divisez le rôle trop large s’il permettait des actions sur des comptes sans rapport.

Testez ensuite volontairement le chemin de refus. Faites pointer une cible de préproduction vers un identifiant d’un autre compte de test et vérifiez que l’exécuteur s’arrête avant l’appel d’API modificatif. Les équipes testent souvent les scénarios de réussite sans jamais démontrer que la liaison de compte échoue de manière sûre.

Le déploiement fonctionne mieux lorsqu’il commence par les écritures les plus risquées

N’attendez pas de disposer d’un inventaire cloud complet pour appliquer une liaison explicite aux actions dangereuses. Commencez par les opérations qui peuvent modifier ou exposer l’état de production : déploiements, changements d’identité, modifications réseau, exports de données, rotation des secrets et commandes d’infrastructure destructrices. La découverte en lecture seule peut aider à constituer le registre, mais elle ne doit pas accorder silencieusement un accès d’exécution aux comptes nouvellement trouvés.

Commencez par lister les comptes susceptibles de recevoir ces actions et attribuez à chacun une étiquette d’environnement et un responsable clairs. Créez ensuite une fiche de cible pour chaque paire compte-usage. Faites alors en sorte qu’un chemin d’exécution résolve les handles, obtienne des identifiants propres à la cible, vérifie l’identité active et écrive l’enregistrement de l’action. Enfin, retirez à l’agent l’accès direct aux profils ambiants, aux abonnements par défaut et aux fichiers d’identifiants.

Attendez-vous à des réticences de la part des ingénieurs habitués à changer de compte dans un terminal avec une seule variable. Cette habitude est rapide parce qu’elle place le contexte dans la mémoire d’une personne. Un agent autonome ne possède pas cette mémoire, pas plus que les personnes qui examinent ses actions. Placez le contexte dans la requête, le registre de cibles et les preuves d’exécution.

Si vous ne pouvez pas indiquer le numéro de compte, l’identité d’exécution et la portée de la ressource avant l’exécution d’une action, l’agent ne dispose pas encore des informations nécessaires pour agir en toute sécurité. Faites-lui recueillir les faits manquants ou confiez l’action à une personne.