Ton premier agent IA ne crée pas “juste” un nouveau workflow. Il crée un nouvel utilisateur.
Un agent IA utile, c’est un agent connecté. Et connecté, ça veut dire : comptes techniques, clés API, OAuth, tokens, connecteurs, permissions sur ta messagerie, ton CRM, ton drive, ta factu, ton support.
Donc oui, tu gagnes du temps. Mais tu ouvres aussi une nouvelle surface d’attaque.
Le vrai sujet n’est pas “est-ce que le modèle hallucine ?”. Le vrai sujet, c’est : qu’est-ce que ton agent a le droit de faire dans tes systèmes, et qu’est-ce qui se passe si ses secrets fuitent.
Microsoft met explicitement les agents IA dans la famille des non-human identities (NHI) avec les applications, bots et identités de workload. Et ils insistent : leur gestion devient critique en environnement cloud. Ce n’est pas une discussion d’admin. C’est une discussion de dirigeant : risques, assurance, continuité, réputation, conformité, coût d’incident.
Pourquoi les agents créent une nouvelle surface d’attaque (et pourquoi tu dois traiter ça comme de l’IAM)
Un agent “agentique” suit une boucle simple : il planifie, puis il agit via des outils (skills, plugins, connecteurs, actions). OWASP maintient même des référentiels dédiés à la sécurité agentique, parce que cette boucle “planifier puis exécuter” change la donne.
1) Tu multiplies les identités techniques
Chaque agent sérieux implique une identité applicative : service principal, managed identity, app OAuth, API key. Tu passes d’un monde “des humains se connectent” à un monde “des workloads se connectent”. Microsoft Entra parle de workload identities comme d’un périmètre IAM à part entière.
Si tu déploies 5 agents, tu ne gères pas 5 prompts. Tu gères 5 identités, 5 jeux de droits, 5 chaînes de tokens, 5 journaux, 5 surfaces de compromission.
2) Les tokens deviennent des actifs à haut risque
Les identités non humaines vivent via des secrets : tokens, certificats, clés. Et certains tokens côté workloads peuvent être long lived (documenté jusqu’à 24h dans certains scénarios). Si un attaquant exfiltre un token, il peut agir sans mot de passe humain, souvent sans MFA, parfois longtemps.
3) Les connecteurs et “skills” sont un nouvel execution layer
Ton agent ne “discute” pas. Il exécute : envoie un email, modifie un champ CRM, crée un ticket, télécharge un fichier, appelle une API. Le risque numéro 1 n’est pas l’erreur de réponse. C’est l’action non désirée sur tes systèmes métiers.
4) La supply chain des outils agentiques est une cible
OWASP documente des problèmes réels de chaîne d’outils, dont des scénarios type “SkillJacking” (dépendances hijackables via comptes supprimés, packages, domaines expirés). Message simple : tu peux être clean, et te faire compromettre “par le côté” via un connecteur.
Décision dirigeant : dès que l’agent peut écrire, ton sujet c’est “contrôle d’accès”
Lecture seule : risques limités mais réels (exfiltration). Écriture : risques opérationnels (fraude, erreurs, sabotage, réputation). Donc tu dois poser un modèle de gouvernance agents IA avant le premier agent, pas après le premier incident.
Le modèle à mettre en place : gouvernance NHI en 12 règles (prêtes à appliquer)
Objectif : avoir un cadre simple, auditable, qui évite le “on a branché ça vite fait” puis panique.
Règle 1 : 1 agent = 1 identité dédiée (interdit : compte partagé)
Pas de “compte service” générique utilisé par 3 automatisations et 2 agents. Tu veux pouvoir dire : cet agent a fait cette action avec ces droits.
- Crée une identité workload dédiée (app OAuth, service principal, managed identity).
- Nomme-la clairement : “Agent-SAV-Triage”, “Agent-Sales-Email-CRM”, etc.
- Assigne un propriétaire humain (un responsable joignable).
Règle 2 : un “purpose statement” écrit avant le moindre droit
Une phrase, pas un roman :
- Finalité : ce que l’agent fait.
- Périmètre : quels systèmes.
- Interdits : actions explicitement bannies.
- Criticité : impact si ça déraille.
Sans ça, tu donnes des droits “au cas où”. Et c’est comme ça que tu te retrouves avec un agent qui peut supprimer 50 000 contacts “par accident”.
Règle 3 : moindre privilège, mais au niveau “actions”
“Accès au CRM” ne veut rien dire. Tu découpes en actions : lire, créer, modifier, supprimer, exporter, envoyer.
- Autorise lecture sur un périmètre strict.
- Autorise écriture uniquement là où il y a un bénéfice clair.
- Interdis suppression et export massif par défaut.
Règle 4 : séparation lecture vs écriture (deux modes, deux jeux de droits)
Très concret : un agent peut analyser des emails en lecture seule. Mais l’envoi de réponse doit être un autre “mode” avec un contrôle renforcé.
- Mode “Observer” : lecture, tagging, draft.
- Mode “Actor” : envoi, changement de statut, création d’objet métier.
Règle 5 : coffre de secrets obligatoire (zéro secret dans un prompt, un doc, un repo)
Les secrets (API keys, refresh tokens, certificats) vont dans un secret manager. Pas dans Notion, pas dans un fichier .env partagé sur Slack, pas dans le code sans contrôle.
- Accès au coffre limité à l’identité de l’agent.
- Journalisation des lectures de secrets.
Règle 6 : rotation planifiée (et testée) des secrets et certificats
Si tu ne sais pas tourner un secret sans casser la prod, tu ne sais pas révoquer en incident. Mets une rotation :
- Clés API : rotation périodique.
- Certificats : dates d’expiration gérées.
- Tokens renouvelables : limite de durée et surveillance.
Règle 7 : approbations humaines sur les actions “irréversibles”
Tu définis une liste d’actions qui nécessitent validation :
- Envoi d’email à un client (si sensible).
- Changement de statut “Deal won/lost”.
- Création d’avoir, remise, commande.
- Suppression (idéalement interdite).
Tu peux faire simple : l’agent propose, un humain clique “Valider”. Ce n’est pas sexy. C’est sûr.
Règle 8 : journaux d’audit exploitables (pas juste “on loggue”)
Tu veux pouvoir répondre à 3 questions en 10 minutes :
- Qu’a fait l’agent, exactement ?
- Avec quelle identité et quel token ?
- Dans quel système et sur quels objets ?
Donc : logs centralisés, horodatés, corrélables (ID de requête, ID d’agent, ID d’outil appelé).
Règle 9 : alerting sur signaux faibles (et signaux forts)
Un agent compromis ne “crie” pas forcément. Il agit doucement. Mets des alertes :
- Volume d’actions anormal (ex : 500 lectures CRM en 2 minutes).
- Accès en dehors des plages horaires prévues.
- Appels API vers des endpoints jamais vus.
- Tentatives d’actions interdites (doivent déclencher une alerte, pas juste un refus).
Règle 10 : segmentation des accès et des réseaux (ne pas tout brancher au même endroit)
Ne donne pas à un agent une route directe vers tous tes outils “par simplicité”. Segmente :
- Un agent marketing n’a rien à faire sur la facturation.
- Un agent finance n’a rien à faire sur l’admin M365.
- Un agent support n’a pas besoin du HR.
Ça limite l’impact si une identité NHI est compromise.
Règle 11 : tests “red team” internes, version light mais régulière
Pas besoin d’une armée. Tu fais des tests ciblés :
- Peut-on pousser l’agent à exécuter une action non prévue via un email piégé ou un texte injecté ?
- Peut-on lui faire appeler un connecteur inattendu ?
- Peut-on provoquer un export massif ?
OWASP publie des exemples d’exploits agentiques : inspire-toi de ces patterns, même en mode “table-top”.
Règle 12 : plan de révocation immédiate (le bouton rouge)
Tu dois savoir couper en 2 minutes :
- Désactiver l’identité workload.
- Révoquer tokens et sessions.
- Tourner les secrets.
- Couper les connecteurs (ou les scopes OAuth).
- Mettre l’agent en “read-only” temporaire.
Si ton plan de révocation est “on appelle le prestataire lundi”, tu es nu.
Mini-cas concret : un agent qui lit la boîte mail + le CRM
Cas classique : tu veux un agent qui lit les emails entrants, résume, classe, et met à jour le CRM. Utile. Et risqué si tu le fais à l’arrache.
Le purpose statement (exemple)
Objectif : qualifier les emails entrants prospects et clients, proposer un résumé et créer ou mettre à jour une fiche contact dans le CRM.
Systèmes : messagerie (lecture), CRM (lecture + création limitée).
Interdits : envoyer des emails, supprimer/modifier l’historique, exporter la base contacts, changer le statut d’opportunité en “gagnée”.
Droits exacts à donner (version propre)
- Messagerie :
- Lecture des emails entrants dans une boîte dédiée (ex : sales-inbox@) ou un dossier dédié.
- Accès interdit aux boîtes perso des commerciaux.
- Autorisation de créer un brouillon seulement (optionnel), pas d’envoyer.
- CRM :
- Lecture des contacts et comptes sur un périmètre défini.
- Création de contact si email inconnu, avec champs autorisés (nom, email, société, source).
- Interdiction de suppression.
- Interdiction d’export.
- Modification limitée : tags, notes, “last contact date”.
- Secrets :
- Tokens OAuth stockés en coffre de secrets.
- Rotation planifiée.
Validations à imposer avant écriture
- Si l’agent veut créer un contact : OK sans humain si champs limités et logs complets.
- Si l’agent veut modifier un contact existant : validation humaine si champ sensible (téléphone, adresse, statut RGPD/opt-in).
- Si l’agent veut créer une opportunité : validation humaine systématique.
Alerting minimal qui te sauve
- Plus de X créations de contacts par heure.
- Accès CRM en dehors des horaires.
- Tentative d’accès à une autre mailbox que sales-inbox@.
- Tentative d’export ou de lecture “bulk”.
Checklist rapide : “sécurité agents IA” avant mise en prod
- Identité dédiée créée et documentée (NHI).
- Purpose statement validé (toi ou ton DG/DSI).
- Scopes OAuth au minimum. Pas de droits globaux “par confort”.
- Coffre de secrets en place, rotation définie.
- Logs centralisés, consultables, conservés.
- Alerting configuré sur volumes, horaires, actions interdites.
- Approbations sur actions irréversibles.
- Bouton rouge testé (révocation + désactivation).
Ce que tu dois décider, toi, pas “l’équipe IT”
Tu dois trancher 4 choses. Sinon ça finit en droits trop larges “pour que ça marche”.
- Quel niveau d’autonomie : lecture seule, écriture limitée, écriture libre.
- Quels systèmes sont connectables : CRM oui, facturation non, par exemple.
- Quel niveau de preuve : logs et audit exigés, ou bricolage toléré.
- Qui porte la responsabilité : propriétaire humain de chaque agent.
Action : monte ton registre NHI “agents IA” en 45 minutes
Tu ouvres un doc (ou un tableur) et tu crées une ligne par agent, même si l’agent n’existe pas encore.
- Nom de l’agent
- Owner humain
- Purpose statement
- Systèmes connectés
- Droits lecture
- Droits écriture
- Secrets utilisés et où ils sont stockés
- Règles d’approbation
- Logs et alertes
- Procédure de révocation
Ensuite seulement, tu branches ton agent.
Si tu veux connecter ton IA à des outils via des connecteurs, va relire MCP (le principe, pas la sécurité) : https://jimmymanin.com/blog/mcp-explique-simplement-le-port-usb-c-qui-connecte-ton-ia-a-tes-outils. Et si tu envisages un agent plus autonome, pose aussi les garde-fous d’exécution : https://jimmymanin.com/blog/agent-ia-autonome-le-garde-fou-anti-debordement-a-poser-avant-quil-pirate-un-site.
Tu peux faire des agents qui font gagner du temps et de la marge. Mais si tu ne traites pas la sécurité agents IA comme un sujet non-human identities et contrôle d’accès IA entreprise, tu crées un super employé… sans badge, sans manager, et sans caméra.
