Pourquoi la défense en profondeur s'impose pour les agents IA
Les agents autonomes déployés dans Microsoft 365, Azure AI et Copilot Studio ne sont plus de simples chatbots. Ils appellent des outils, interrogent des API, accèdent à des données sensibles et prennent des décisions sans validation humaine systématique. Un contrôle de sécurité unique ne suffit pas à couvrir cette surface d'attaque étendue.
L'AI Agent Defense Framework répond à ce constat en structurant la protection sous forme d'une pyramide à cinq niveaux, complétée par des contrôles transversaux permanents. Chaque couche compense les failles potentielles des couches adjacentes. L'objectif : rendre l'agent résilient même lorsqu'un contrôle individuel est contourné.
Périmètre du cadre
Ce framework s'applique à tout agent IA opérant dans un environnement d'entreprise : agents Copilot Studio, workflows Azure AI Foundry, orchestrateurs LangChain hébergés sur Azure, ou solutions custom basées sur Azure OpenAI Service.
Les cinq niveaux de la pyramide de sécurité
Niveau 1 — Secure Foundation : durcir l'infrastructure
La base de la pyramide porte sur le durcissement de l'environnement d'exécution avant même que l'agent ne reçoive sa première requête.
Actions concrètes :
- Héberger les modèles sur Azure AI Foundry pour bénéficier des garanties de conformité Microsoft.
- Chiffrer les données au repos (Azure Storage Service Encryption) et en transit (TLS 1.2 minimum).
- Appliquer les Security Baselines Azure via Azure Policy.
- Valider l'intégrité des dépendances tierces (packages, SDK, connecteurs).
Niveau 2 — Least Privilege : limiter l'accès au strict nécessaire
Chaque agent doit disposer uniquement des permissions requises pour accomplir sa tâche définie. Toute permission supplémentaire élargit la surface d'attaque en cas de compromission.
1# Exemple : attribuer un rôle limité à une identité managée dans Azure2New-AzRoleAssignment `3 -ObjectId "<managed-identity-object-id>" `4 -RoleDefinitionName "Cognitive Services User" `5 -Scope "/subscriptions/<subscription-id>/resourceGroups/<rg-name>"- Utiliser des identités managées (Managed Identities) plutôt que des clés d'API statiques.
- Piloter les accès aux données via Microsoft Entra ID et le contrôle d'accès basé sur les rôles (RBAC).
- Restreindre les permissions des connecteurs dans Copilot Studio au niveau de chaque action.
- Réviser périodiquement les attributions de rôles avec les Access Reviews d'Entra ID.
Niveau 3 — Validation : contrôler entrées, sorties et appels d'outils
Un agent non validé est vulnérable aux attaques par injection de prompt (prompt injection) et à l'exfiltration de données via des sorties malformées.
- Assainir systématiquement les entrées utilisateur avant de les transmettre au modèle.
- Valider les paramètres de chaque appel d'outil (type, plage de valeurs, longueur).
- Filtrer les réponses du modèle avant de les exposer à l'utilisateur final.
- Activer les fonctions de content filtering d'Azure AI Foundry pour bloquer les catégories de contenu à risque (violence, données personnelles, contenu haineux).
1// Exemple de configuration content filter dans Azure AI Foundry2{3 "contentFilters": [4 { "name": "hate", "severityThreshold": "medium", "blocking": true },5 { "name": "violence", "severityThreshold": "medium", "blocking": true },6 { "name": "selfHarm", "severityThreshold": "low", "blocking": true },7 { "name": "sexual", "severityThreshold": "medium", "blocking": true }8 ]9}Prompt injection
Les attaques par injection de prompt restent la menace principale sur les agents LLM. Un utilisateur malveillant peut tenter de redéfinir les instructions système via le champ utilisateur. La validation au niveau 3 est la première ligne de défense contre ce vecteur.
Niveau 4 — Guardrails : encadrer le comportement de l'agent
Les guardrails définissent ce que l'agent est autorisé à faire, indépendamment de ce que le modèle pourrait proposer.
- Définir une liste blanche des actions autorisées (allowlist) pour chaque agent.
- Bloquer les opérations destructrices (suppression, modification de masse) sans validation explicite.
- Configurer des politiques de gouvernance dans Copilot Studio pour restreindre les sources de données et les connecteurs accessibles.
- Implémenter des limites de débit (rate limiting) sur les appels d'outils pour éviter les boucles d'exécution runaway.
Niveau 5 — Monitoring & Response : surveiller et répondre
Le sommet de la pyramide assure la visibilité sur le comportement réel de l'agent en production.
- Centraliser les journaux d'activité dans Microsoft Sentinel pour détecter les patterns anormaux.
- Configurer des alertes sur les comportements hors normes : volume d'appels API inhabituel, accès à des ressources non prévues, erreurs répétées de validation.
- Activer Microsoft Defender for Cloud pour la protection des workloads Azure hébergeant l'agent.
- Consulter les journaux d'audit d'Entra ID pour tracer chaque autorisation accordée à l'identité de l'agent.
Les cinq contrôles transversaux : une couche permanente
Ces contrôles ne sont pas liés à un niveau spécifique. Ils s'appliquent à l'ensemble de la pyramide de façon continue.
| Contrôle | Description | Outil Microsoft associé |
|---|---|---|
| Human Oversight | Maintenir une validation humaine pour les actions à haut risque ou irréversibles | Copilot Studio — étapes d'approbation |
| Audit & Logging | Journaliser toutes les actions de l'agent et réviser régulièrement les logs | Microsoft Sentinel, Log Analytics |
| Data Protection | Classifier les données, appliquer le chiffrement et le masquage | Microsoft Purview, Azure Key Vault |
| Test & Red Team | Tester l'agent face à des scénarios d'attaque réels de façon régulière | Azure AI Foundry — Safety Evaluations |
| Continuous Improvement | Analyser les incidents pour renforcer les contrôles existants | Microsoft Defender XDR, Sentinel Incidents |
Red teaming des agents IA
Azure AI Foundry propose des outils d'évaluation de la sûreté (Safety Evaluations) permettant de tester automatiquement un agent face à des jailbreaks connus et des injections de prompt. Ces évaluations sont distinctes des tests fonctionnels habituels et doivent être planifiées séparément.
Mise en œuvre progressive : par où commencer
Face à un déploiement existant, une mise en conformité complète avec le framework peut sembler lourde. Une approche séquentielle est recommandée.
Auditer les identités et permissions actuelles
Identifier toutes les identités (comptes de service, identités managées, clés d'API) utilisées par les agents en production. Supprimer les permissions non justifiées.
1# Lister les role assignments d'une identité managée2Get-AzRoleAssignment -ObjectId "<managed-identity-object-id>" | Select-Object RoleDefinitionName, ScopeActiver le content filtering sur Azure AI Foundry
Naviguer vers Azure AI Foundry > votre déploiement de modèle > Content filters et configurer un profil adapté au niveau de risque de votre agent.
Connecter les journaux à Microsoft Sentinel
Activer le connecteur de données Azure OpenAI ou Azure AI Foundry dans Microsoft Sentinel pour centraliser la télémétrie de l'agent.
Définir les guardrails dans Copilot Studio
Pour les agents Copilot Studio, configurer les politiques de gouvernance via le Centre d'administration Power Platform : sources de données autorisées, connecteurs bloqués, environnements cibles.
Planifier un premier exercice de red teaming
Utiliser les Safety Evaluations d'Azure AI Foundry ou mandater une équipe interne pour tester l'agent avec des prompts adversariaux avant toute extension du périmètre.
Limites et points de vigilance
Aucun framework ne remplace l'analyse des risques métier
L'AI Agent Defense Framework fournit une structure générique. Il ne dispense pas d'une analyse de risques spécifique à chaque agent : les données manipulées, les systèmes en aval, les utilisateurs concernés et les impacts en cas de compromission varient d'un déploiement à l'autre.
Quelques limites à garder en tête :
- Les fonctions de content filtering d'Azure AI Foundry ne couvrent pas tous les vecteurs d'attaque (ex. : exfiltration par encodage, side-channel via timing).
- Les Access Reviews Entra ID nécessitent une licence Microsoft Entra ID P2 ou Microsoft Entra ID Governance.
- La détection d'anomalies dans Microsoft Sentinel requiert une configuration manuelle des règles analytiques : aucune règle prête à l'emploi ne couvre spécifiquement les agents IA par défaut.
- Les agents multi-modèles ou multi-orchestrateurs complexifient la traçabilité des décisions : chaque composant doit journaliser indépendamment.
