Agent IA + cloud functions : la posture IAM minimale à imposer

Beaucoup d'agents IA en 2026 sont implémentés comme des chaînes de cloud functions : l'agent reçoit une demande, invoque une Lambda pour interroger une base, une autre pour envoyer un email, une autre pour générer un PDF. Architecture pratique, scalable, fragile sur un point précis : chaque function tourne avec un rôle IAM dont les permissions sont héritées par l'agent. Un scope IAM trop large transforme un agent compromis en accès cloud large.

La posture IAM minimale est l'un des leviers les plus efficaces — et les plus négligés — de la sécurité des agents IA.

Le pattern courant et son défaut

Architecture typique :

`` user → agent (orchestrateur, EC2 ou Lambda) → Lambda A (lit la base clients) → Lambda B (envoie email via SES) → Lambda C (génère PDF dans S3) ``

Le pattern courant : chaque Lambda a un rôle IAM, ces rôles ont souvent des permissions trop larges ("AmazonSESFullAccess", "AmazonS3FullAccess") parce que c'est ce qui passe les tests le plus vite et qu'il faut shipper.

Conséquence : si l'agent est compromis et qu'il invoque la Lambda B avec des paramètres détournés, il peut potentiellement envoyer un email à n'importe qui (pas juste le client demandé). Si C est détourné, l'agent peut écrire n'importe où dans S3.

Les 5 principes IAM pour un agent IA

1. Un rôle IAM par function, jamais partagé

Chaque cloud function a son propre rôle. Aucun rôle "agent générique" partagé entre fonctions. Si la function A est compromise, son rôle est révoqué sans casser B et C.

2. Permissions au niveau de la ressource, pas du service

Mauvais : ``json {"Effect": "Allow", "Action": "s3:", "Resource": ""} ``

Bon : ``json { "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::weesec-pdfs/clients/${aws:PrincipalTag/UserId}/*" } ``

Permission limitée à l'action exacte (s3:PutObject, pas s3:*) et à un sous-périmètre de bucket. Si la fonction est compromise, l'attaquant ne peut écrire que dans le dossier du user courant — pas dans tout S3.

3. Conditions IAM pour la contextualisation

IAM permet d'ajouter des conditions : seulement depuis tel VPC, seulement pendant les heures ouvrées, seulement sur les objets matching un pattern.

``json { "Condition": { "StringEquals": {"aws:SourceVpc": "vpc-internal-prod"} } } ``

Très utile pour limiter l'usage d'une permission au contexte exact prévu. Une compromission depuis un attaquant externe ne pourrait pas activer la permission.

4. Tagging et ABAC (attribute-based access control)

Pour les agents multi-tenant, ABAC permet de scoper les permissions par tenant via des tags. Le rôle IAM contient une permission générique, les tags du principal et de la ressource font le matching.

``json { "Effect": "Allow", "Action": "dynamodb:Query", "Resource": "*", "Condition": { "StringEquals": { "dynamodb:LeadingKeys": "${aws:PrincipalTag/TenantId}" } } } ``

L'agent peut interroger la base, mais uniquement les enregistrements dont la clé matche son tenant. Isolation cross-tenant garantie au niveau IAM, pas seulement au niveau code.

5. Pas de credentials long-terme dans le runtime de l'agent

L'agent ne stocke jamais d'AWS_ACCESS_KEY_ID long-terme. Il utilise :

• Instance role s'il tourne sur EC2.
• Task role s'il tourne sur ECS / Fargate.
• Function role s'il tourne en Lambda.
• OIDC federation s'il tourne ailleurs (GitHub Actions, on-prem, autre cloud).

Token éphémère récupéré à la volée, pas de credentials persistants. Cf. Agent et secrets : injection runtime.

Erreurs spécifiques aux agents

L'agent qui peut "tout interroger" pour "comprendre le contexte"

Tentation classique : donner à l'agent un accès lecture large "pour qu'il puisse trouver ce dont il a besoin". C'est un anti-pattern. Un agent qui a besoin de lire 30 tables différentes a probablement été mal cadré côté UX — il faudrait des outils plus spécifiques.

L'agent qui écrit dans la même base que les services humains

Si l'agent écrit dans la base de prod avec un rôle élargi, un bug ou une manipulation peut corrompre des données critiques. Pattern défensif : écrire dans une table intermédiaire ou un outbox que l'agent peut alimenter librement, et qu'un process séparé valide avant intégration dans la base de référence.

L'agent qui assume un rôle au-dessus de son périmètre

Avec AssumeRole, un agent peut prendre temporairement un rôle plus puissant. Cette capacité doit être strictement contrôlée :

• Liste d'allow explicite des rôles assumables.
• Audit trail de chaque AssumeRole.
• Pas d'AssumeRole permettant d'élever vers un rôle administrateur.

La revue IAM périodique

Tous les 3 mois, pour chaque rôle utilisé par un agent :

1. Lister les actions effectivement utilisées sur la période (via CloudTrail / GCP Audit Logs / Azure Monitor).
2. Comparer avec les actions autorisées par la policy.
3. Retirer les actions autorisées non utilisées.

Cette opération est partiellement automatisable. AWS propose IAM Access Analyzer pour suggérer des policies basées sur l'usage réel. Bonne baseline, à compléter par revue humaine.

Le cas spécifique des outils MCP qui tournent en cloud function

Si vous exposez un outil MCP qui s'exécute via une Lambda, les permissions de cette Lambda deviennent indirectement les permissions de l'agent qui appelle l'outil. À traiter avec le même niveau d'attention.

Bonne pratique : créer un rôle IAM dédié à chaque outil MCP, jamais réutilisé entre outils. Si l'outil "send_email" est compromis, "delete_file" garde son rôle propre.

La règle de validation

Avant un go-live d'agent qui invoque du cloud :

• [ ] Chaque cloud function a son propre rôle IAM.
• [ ] Aucun rôle n'a : (ni Action: , ni Resource: non scopé).
• [ ] Les ressources sont nommées précisément ou matchées via pattern restrictif.
• [ ] Pas de credentials long-terme dans le runtime de l'agent.
• [ ] Audit log activé sur toutes les fonctions sensibles.
• [ ] Revue IAM trimestrielle planifiée.

Si vous avez 5 oui sur 6, vous êtes dans le top 10% des déploiements. Si vous avez 3 oui, c'est un bon point de départ mais il reste du travail. Si vous avez 0-2, l'agent ne devrait pas être en prod sur un périmètre sensible.

Pour la rotation des secrets sous-jacents, Agent et secrets : injection runtime. Pour les 7 surfaces de threat model, Threat model d'un agent.