07 · Implémenter la sécurité pour l'IA

Version : 1.2 · Date : 2026-10-21 · Domaine 3 de l'examen : Calcul sécurisé (20 à 25 %)

En une phrase : sécuriser l'IA, c'est protéger cinq couches à la fois : les données que Copilot et les agents peuvent lire (SharePoint, Purview), l'identité des agents (Entra Agent ID, Conditional Access), les agents eux-mêmes (Copilot Studio, Microsoft 365 admin center), la plateforme et le modèle (AI gateway dans APIM, guardrails Foundry) et la supervision (Defender for AI, Defender XDR).

Attention, sujet très récent : beaucoup de fonctionnalités de ce chapitre sont en préversion ou viennent de changer de nom (Azure AI Foundry → Microsoft Foundry, DSPM pour l'IA → DSPM, rôles « Azure AI User » → « Foundry User »). Le statut est indiqué à chaque fois. Le guide d'étude précise que l'examen peut poser des questions sur des préversions « couramment utilisées ».

Ce que l'examen demande#

Intitulés officiels, en anglais, du guide d'étude SC-500 (la version française du guide traduit Microsoft Entra Agent ID par « Identifiant d'assistant Microsoft Entra ») :

1. Les bases à maîtriser avant tout#

1.1 Pourquoi l'IA change la sécurité#

L'IA n'invente pas de nouveaux droits : Microsoft 365 Copilot respecte les autorisations existantes. Mais elle change trois choses :

1. Elle amplifie la surexposition : un fichier partagé par erreur par un lien Anyone restait introuvable dans un site oublié ; Copilot le retrouve en une question. Le problème n'est pas Copilot, c'est le partage existant.
2. Elle crée de nouvelles attaques : l'injection d'invite directe (jailbreak : l'utilisateur tente de contourner les règles du système) et indirecte (XPIA : des instructions cachées dans un e-mail, un document, une page web ou la réponse d'un outil détournent l'agent).
3. Les agents agissent : un agent appelle des outils (connecteurs, serveurs MCP, API) avec une identité. Un agent trop privilégié et détourné a un blast radius important.

1.2 Le vocabulaire du chapitre#

1.3 Quel outil pour quel risque#

1.4 Les licences (souvent dans les questions)#

2. Surexposition des données dans SharePoint#

2.1 Le principe#

Par défaut, SharePoint règle le partage sur l'option la plus permissive. Avant (et pendant) le déploiement de Copilot, la démarche recommandée par Microsoft est : ajuster les paramètres de partage, mesurer la surexposition, restreindre le temps de corriger, corriger les accès, puis gérer le cycle de vie (archiver, supprimer l'inutile).

Signaux de risque à rechercher (un site qui en cumule plusieurs est à risque élevé) :

• partages larges : liens Anyone, partage avec Everyone except external users (EEEU), liens People in your organization à toute l'organisation ;
• grands publics avec des autorisations excessives, héritage d'autorisations rompu ;
• contenu sensible mal protégé, sites non étiquetés ou publics ;
• sites sans propriétaire, inactifs, jamais revus.

2.2 Les Data access governance reports (DAG)#

SharePoint admin center > Reports > Data access governance (rôle SharePoint Administrator).

Règles des rapports d'autorisations en PowerShell : un rapport par charge de travail (SharePoint, OneDrive), le premier prend jusqu'à 5 jours, les suivants moins de 24 h, données jusqu'à 48 h avant la génération, nouveau rapport possible tous les 30 jours.

# Rapport instantané : sites où au moins un utilisateur a accès (module Microsoft.Online.SharePoint.PowerShell)
Start-SPODataAccessGovernanceInsight -ReportEntity PermissionedUsers -ReportType Snapshot `
  -Workload SharePoint -CountOfUsersMoreThan 0 -Name "OrgWidePermissionedUsersReportSharePoint"

La fonction AI insights (modèle de langage) résume certains rapports et propose des actions. L'agent d'administration SharePoint aide aussi à repérer les sites à risque.

2.3 Restreindre et corriger#

# Restricted Content Discovery sur un site, puis vérification
Set-SPOSite -Identity https://contoso.sharepoint.com/sites/RH -RestrictContentOrgWideSearch $true
Get-SPOSite -Identity https://contoso.sharepoint.com/sites/RH | Select-Object RestrictContentOrgWideSearch

Piège d'examen : « Empêcher Copilot de remonter le contenu d'un site sans changer les autorisations » = RCD. « N'autoriser l'accès qu'aux membres du service Finance, même si un lien a été partagé » = RAC.

3. Purview DSPM pour les applications Copilot et IA#

3.1 À quoi ça sert#

DSPM (Microsoft Purview portal) est la porte d'entrée pour découvrir, sécuriser et appliquer des contrôles de conformité à l'usage de l'IA : Microsoft 365 Copilot et ses agents, Copilot Studio, applications Foundry ou enregistrées dans Entra, et sites d'IA tiers (ChatGPT, Gemini…). Il réutilise les contrôles Purview existants (étiquettes, DLP, Insider Risk Management, Communication Compliance, audit, eDiscovery) avec des rapports et des one-click policies.

Deux versions coexistent : DSPM pour l'IA (classique), remplacée par la nouvelle DSPM qui ajoute des objectifs de sécurité des données (par exemple « Empêcher l'exposition de données dans les interactions Microsoft 365 Copilot », « Empêcher le surpartage de données sensibles »), des workflows guidés et la vue Apps and agents. Les nouveautés n'arrivent que dans la nouvelle version.

3.2 Les prérequis#

Rôles : un compte disposant des autorisations de conformité, par exemple membre du rôle Compliance Administrator ; pour voir le texte des invites et réponses, le groupe de rôles Content Explorer Content Viewer. Avec des administrative units, seul un administrateur non restreint crée les one-click policies. Compter 24 heures avant de voir les résultats.

3.3 Les one-click policies (exemples)#

3.4 Évaluations des risques de données et activité#

• Évaluation par défaut : chaque semaine, sans activation, sur les 100 sites SharePoint les plus utilisés ; elle identifie, corrige et surveille le surpartage. Des évaluations personnalisées (préversion dans la version classique) peuvent cibler d'autres sites, Fabric ou une analyse élément par élément (app registration avec autorisations Graph d'application).
• Activity explorer, onglet AI activities : événements AI interaction, AI website visit, DLP rule match, Sensitive info types.
• Reports : interactions par application, données sensibles partagées, utilisateurs à risque.

À retenir : DSPM ne remplace pas SAM. SAM mesure et restreint l'accès aux sites ; DSPM voit ce qui passe dans les invites et réponses et déploie les contrôles Purview. Les deux se complètent.

4. Real-time protection des agents Copilot Studio#

4.1 Le principe#

Les agents personnalisés de Copilot Studio sont sécurisés par défaut contre les injections d'invite utilisateur (UPIA) et les injections inter-domaines (XPIA). Pour aller plus loin, on configure un système de détection des menaces externe (en préversion) : à chaque fois que l'orchestrateur envisage d'appeler un outil, il envoie le contexte à un point de terminaison qui répond autoriser ou bloquer. Le fournisseur peut être Microsoft Defender, un autre éditeur ou une solution maison.

• Ne s'applique qu'aux agents à generative orchestration (pas aux agents classiques).
• Données envoyées : l'invite récente et l'historique, les sorties des outils précédents, des métadonnées (agent, utilisateur, locataire, déclencheur), l'outil envisagé avec le raisonnement et les entrées proposées. Les règles de traitement du fournisseur peuvent différer de celles de Microsoft (y compris hors de votre région).
• Si aucune décision n'arrive en 1 seconde, l'outil s'exécute par défaut ; réglage Set error behavior pour choisir Block the query.
• En cas de blocage, l'agent s'arrête et indique à l'utilisateur que son message est bloqué.

sequenceDiagram
    actor U as Utilisateur
    participant A as Agent Copilot Studio
    participant D as Defender, real-time protection
    participant T as Outil, connecteur ou MCP
    U->>A: Invite
    A->>A: Generative orchestration, choix d'un outil
    A->>D: Outil envisagé, entrées, historique
    alt Menace détectée
        D-->>A: Bloquer
        A-->>U: Message bloqué, alerte dans Defender
    else Rien de suspect, ou pas de réponse en 1 s avec le réglage par défaut
        D-->>A: Autoriser
        A->>T: Appel de l'outil
        T-->>A: Résultat
        A-->>U: Réponse
    end

4.2 Mise en place avec Microsoft Defender#

4.3 Les règles de real-time protection#

Microsoft Defender portal > Settings > Security for AI > Policies & rules > Real-time protection :

• Règle par défaut : audit de tous les agents (le comportement est enregistré sans bloquer) ;
• Custom rules : blocage, avec une portée (tous les agents ou certains, exclusions possibles pour les agents dotés d'un Entra Agent ID) et des types de détection : exfiltration de secrets, propagation de contenu malveillant, techniques d'évasion, domaine de messagerie non sûr ;
• chaque audit ou blocage est un comportement dans la table d'Advanced hunting BehaviorInfo ; quand une règle de blocage couvre un agent, les alertes quasi temps réel ne sont plus générées pour lui ;
• Prompt evidence collection : extraits d'invites suspects dans les alertes, secrets masqués (activé par défaut, désactivable).

Couverture : outils des agents Agent 365 (via Work IQ MCP), agents Copilot Studio (préversion), agents Foundry (préversion : requêtes, réponses, appels et réponses d'outils), agents locaux des postes (Defender for Endpoint en mode actif).

5. Microsoft Entra Agent ID#

5.1 Pourquoi une identité dédiée aux agents#

Les service principals classiques ont été conçus pour des charges de travail déterministes : pas de sponsor obligatoire, pas de journaux propres aux agents, pas de cycle de vie piloté par un modèle. Un compte utilisateur classique est encore pire pour un agent (stratégies faites pour les humains, détections faussées). Entra Agent ID apporte des objets dédiés, disponibles pour tous les clients Entra ; étendre les fonctions de sécurité d'Entra aux agents demande en revanche la licence Agent 365.

Les personnes responsables :

• Sponsor : responsabilité métier et décisions de cycle de vie, sans accès administratif technique ; obligatoire pour un blueprint. Peut être un utilisateur, un groupe dynamique ou un groupe Microsoft 365 (pas un groupe de sécurité ni un groupe attribuable à des rôles) ;
• Owner (propriétaire) : administrateur technique (recommandé) ;
• Responsable (manager) : pour un agent user account.

Création : Microsoft Entra admin center > Entra ID > Agents > Agent blueprints > New agent blueprint (Preview), ou Microsoft Graph / PowerShell (autorisation AgentIdentityBlueprint.Create). Microsoft Foundry crée automatiquement un blueprint et une identité d'agent par projet, puis une identité dédiée à chaque agent publié ; Copilot Studio peut aussi créer automatiquement des agent identities (préversion).

5.2 Les trois façons dont un agent accède à une ressource#

Un même agent peut utiliser plusieurs modèles : il faut alors une stratégie par sujet de jeton.

flowchart TD
    A[Un agent demande un jeton] --> B{Qui est le sujet du jeton ?}
    B -- "L'utilisateur connecté (OBO)" --> C["Stratégies ciblant les utilisateurs et groupes"]
    B -- "L'agent identity (application seule)" --> D["Stratégies ciblant les agent identities ou leur blueprint"]
    B -- "L'agent user account" --> E["Stratégies ciblant les agent users"]
    C --> F{Contrôles satisfaits ?}
    D --> F
    E --> F
    F -- Oui --> G[Jeton émis pour la ressource]
    F -- Non --> H[Accès refusé]

5.3 Conditional Access pour les agents#

Conditional Access est évalué quand Entra émet ou actualise un jeton (et quasi en temps réel avec la CAE pour les ressources compatibles). Il évalue le sujet et l'audience du jeton.

Une stratégie par sujet :

• une stratégie qui cible des utilisateurs ne s'applique pas aux agent user accounts (même « Tous les utilisateurs ») ;
• une stratégie qui cible des agent identities ne s'applique pas à leur agent user account ;
• cibler un blueprint couvre ses agent identities, pas leurs comptes utilisateur ;
• on ne peut pas cibler les agent user accounts par appartenance à un groupe.

Ce que Conditional Access ne couvre pas : le blueprint qui obtient un jeton Graph pour créer des agent identities, les échanges intermédiaires sur le point de terminaison AAD Token Exchange Endpoint: Public, les locataires avec les paramètres de sécurité par défaut, et tout accès par clé d'API (hors Entra ID).

Stratégies recommandées :

Toujours commencer en Report-only. Les agents ne savent pas satisfaire une MFA interactive : ne pas compter sur les stratégies des humains, vérifier que les stratégies larges (« Tous les utilisateurs : MFA ») ne cassent pas les flux d'agents, et appliquer les stratégies au blueprint pour qu'elles soient héritées. Rôle : Conditional Access Administrator.

5.4 ID Protection pour les agents#

ID Protection détecte les risques des agents qui ont une identité Entra Agent ID (rapport Risky agents, rôles Security Administrator, Security Operator ou Security Reader ; détections conservées 90 jours). Un mode apprentissage évite les faux positifs des agents trop récents.

Actions : Confirmer la compromission (risque Élevé, déclenche les stratégies basées sur le risque d'agent), Confirmer sain, Ignorer le risque, Désactiver. En OBO, le risque est attribué à l'utilisateur, pas à l'agent. API Graph : riskyAgents, agentRiskDetections.

5.5 Gérer l'accès des agent identities#

• Moindre privilège : à la création, une agent identity n'a que des droits limités (autorisations déléguées héritées du blueprint). Le reste se donne par des access packages (Entitlement management) : appartenance à des groupes de sécurité, autorisations OAuth (déléguées et d'application, Graph et autres API), rôles Entra.
• Trois façons de demander un package : l'agent lui-même (API accessPackageAssignmentRequest), son sponsor (portail My Access) ou un administrateur (attribution directe). La demande passe par les approbateurs du package. Dans la stratégie d'attribution : For users, service principals, and agent identities in your directory > All agents.
• Expiration : le sponsor est prévenu avant la fin ; il peut demander une prolongation (nouvelle approbation possible) ou laisser expirer, et l'agent perd l'accès.
• Sponsors : ils activent ou désactivent l'agent et suivent son accès depuis My Account ; si le sponsor quitte l'organisation, la responsabilité passe à son responsable ; les Lifecycle workflows préviennent les cosponsors.
• Bonnes pratiques Microsoft : une identité par instance d'agent, un sponsor et un propriétaire dès la création, des métadonnées descriptives, des politiques posées sur le blueprint (désactiver le blueprint = coupe-circuit pour tous ses agents), ne jamais créer d'agent comme simple app registration en dehors du cadre Agent ID.

6. Le blast radius avec Defender XDR#

6.1 Inventaire et posture des agents#

Microsoft Defender portal > Assets > AI agents : agents Copilot Studio, Foundry, Microsoft 365, plateformes tierces enregistrées dans le registre, et agents locaux des postes (Defender for Endpoint). Pour chaque agent : niveau de risque (Élevé, Moyen, Faible, Aucun risque connu, Non évalué), indicateurs de risque, recommandations, alertes, outils, serveurs MCP, identités.

Le niveau de risque et les recommandations sont calculés séparément : un agent à risque élevé peut n'avoir aucune recommandation, il faut lire les deux. La posture des agents est en préversion.

// Dernier état connu de chaque agent (la table AgentsInfo remplace AIAgentsInfo)
AgentsInfo
| summarize arg_max(Timestamp, *) by AgentId
| where LifecycleStatus != "Deleted"

6.2 Détection, investigation et blast radius#

• Defender détecte quasi en temps réel (préversion) : jailbreak, injection indirecte (XPIA), propagation de contenu malveillant, fuite de secrets et d'identifiants, techniques d'évasion, reconnaissance du modèle, accès suspects. Les alertes sont corrélées en incidents.
• Dans le graphe d'un incident, sur un nœud : View blast radius. Le graphe affiche les 8 attack paths les mieux notés depuis l'élément compromis vers des cibles critiques, la liste complète étant disponible à part. L'analyse (en préversion, bâtie sur le lac de données et le graphe de Microsoft Sentinel) est bornée à 7 sauts depuis le nœud source : 5 pour le cloud, 5 pour le local, 3 pour l'hybride. Prérequis : être intégré au Microsoft Sentinel data lake et avoir au moins Exposure management (read) ; le graphe ne montre que ce que l'étendue RBAC de l'analyste lui permet de voir. La qualité du résultat dépend des charges de travail connectées et de la classification des actifs critiques (Security Exposure Management).
• Les choke points (choke points) de Security Exposure Management montrent où couper plusieurs chemins d'un coup.
• Advanced hunting sur les données d'observabilité d'Agent 365 : retracer les appels d'outils, relier blocages (BehaviorInfo) et alertes, créer des détections personnalisées.

Réduire le blast radius : moindre privilège par outil (pas de permission « pour être tranquille »), une identité par agent, autorisations d'application limitées à des étendues précises, blocage en temps réel, agents à risque bloqués par l'accès conditionnel, actifs critiques classés pour que l'analyse soit juste.

7. L'AI gateway dans Azure API Management#

7.1 À quoi sert l'AI gateway#

L'AI gateway n'est pas un produit séparé : ce sont des fonctionnalités de la passerelle d'API Management (tous les niveaux, avec des différences) pour gérer des API de modèles (OpenAI Chat Completions ou Responses, Anthropic Messages en v2, Google Vertex AI), des serveurs MCP, des API d'agents A2A et des modèles auto-hébergés. Elle répond à cinq besoins : authentifier et autoriser, répartir la charge, journaliser, gérer les jetons par consommateur, donner l'accès en libre-service.

Une intégration directe dans le Foundry portal existe en préversion (associer ou créer une instance APIM comme AI gateway d'une ressource Foundry, puis gérer quotas de jetons, agents et outils MCP depuis Foundry). Il existe aussi une API de modèle unifiée et un niveau AI Gateway, tous deux en préversion.

7.2 Importer l'API Foundry#

Azure portal > instance APIM > APIs > + Add API > Create from Azure resource > Microsoft Foundry. L'assistant crée automatiquement :

• les opérations de l'API ;
• une system-assigned managed identity avec les autorisations nécessaires sur le déploiement ;
• une ressource backend et une stratégie set-backend-service vers le point de terminaison ;
• l'authentification au back-end par la managed identity (plus de clé d'API) ;
• en option, des stratégies de surveillance et de gestion.

Si l'API est ajoutée autrement, on configure soi-même : managed identity d'APIM avec le rôle Cognitive Services OpenAI User (ou Foundry User pour le niveau AI Gateway) sur la ressource Foundry, puis authentication-managed-identity vers https://cognitiveservices.azure.com.

7.3 Les stratégies clés#

Exemple (section inbound) qui combine authentification, quotas, filtrage et métriques :

<policies>
  <inbound>
    <base />
    <!-- L'appelant présente un jeton Entra : audience et application vérifiées -->
    <validate-azure-ad-token tenant-id="{{tenant-id}}" header-name="Authorization"
        failed-validation-httpcode="401" failed-validation-error-message="Unauthorized">
      <client-application-ids>
        <application-id>{{client-app-id}}</application-id>
      </client-application-ids>
      <audiences>
        <audience>{{api-audience}}</audience>
      </audiences>
    </validate-azure-ad-token>
    <!-- 5 000 jetons par minute (429) et 500 000 par mois (403) par abonnement -->
    <llm-token-limit counter-key="@(context.Subscription.Id)" tokens-per-minute="5000"
        token-quota="500000" token-quota-period="Monthly" estimate-prompt-tokens="true"
        remaining-tokens-header-name="x-remaining-tokens" />
    <!-- Content Safety : bloque Hate et Violence à partir de la gravité 4, et les attaques par invite -->
    <llm-content-safety backend-id="content-safety-backend" shield-prompt="true">
      <categories output-type="EightSeverityLevels">
        <category name="Hate" threshold="4" />
        <category name="Violence" threshold="4" />
      </categories>
    </llm-content-safety>
    <llm-emit-token-metric namespace="llm-metrics">
      <dimension name="API ID" value="@(context.Api.Id)" />
      <dimension name="Client IP" value="@(context.Request.IpAddress)" />
    </llm-emit-token-metric>
    <!-- Pool de back-ends Foundry, authentifiés par la managed identity d'APIM -->
    <set-backend-service backend-id="pool-foundry" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

Prérequis de llm-content-safety : une ressource Azure AI Content Safety, un backend APIM vers https://<nom>.cognitiveservices.azure.com authentifié par managed identity (rôle Cognitive Services User sur Content Safety). Attention : un utilisateur qui peut écrire une stratégie peut référencer n'importe quel backend existant.

sequenceDiagram
    participant C as Application ou agent
    participant G as AI gateway APIM
    participant S as Azure AI Content Safety
    participant F as Modèle Foundry
    C->>G: Requête avec jeton Entra
    G->>G: validate-azure-ad-token, llm-token-limit
    alt Quota dépassé
        G-->>C: 429 (par minute) ou 403 (quota de période)
    else Dans les limites
        G->>S: Analyse de l'invite (llm-content-safety)
        alt Contenu nuisible ou attaque
            G-->>C: 403
        else Invite acceptée
            G->>F: Appel avec la managed identity d'APIM
            F-->>G: Complétion
            G->>G: Métriques de jetons, semantic cache
            G-->>C: Réponse
        end
    end

8. Defender for AI Services#

8.1 Ce que fait le plan#

La AI threat protection (plan AI services de Defender for Cloud, disponibilité générale) détecte en temps réel les menaces contre les applications d'IA générative bâties sur Microsoft Foundry (modèles Azure OpenAI et inférence de modèles). Elle s'appuie sur les Prompt Shields d'Azure AI Content Safety et le threat intelligence de Microsoft. Les alertes sont centralisées et corrélées dans Defender XDR.

• Analyse les jetons texte seulement (pas les images ni l'audio).
• Clouds commerciaux seulement (pas Azure Government, pas 21Vianet, pas les comptes AWS connectés).
• Essai gratuit de 30 jours, plafonné à 75 milliards de jetons analysés.

8.2 Activer le plan et ses composants#

Azure portal > Defender for Cloud > Environment settings > abonnement > Defender plans > AI services = On (rôle Owner ou Contributor de l'abonnement). Puis Settings du plan :

Les stratégies de sécurité des données Purview pour Foundry ne s'appliquent qu'aux appels qui portent un contexte utilisateur (jeton Entra de l'utilisateur ou contexte transmis explicitement dans l'appel).

// Abonnement : plan Defender for AI Services (nom 'AI') avec les preuves d'invite (extension AIPromptEvidence)
targetScope = 'subscription'

resource defenderAi 'Microsoft.Security/pricings@2024-01-01' = {
  name: 'AI'
  properties: {
    pricingTier: 'Standard'
    extensions: [
      { name: 'AIPromptEvidence', isEnabled: 'True' }
    ]
  }
}

8.3 Les alertes à connaître#

Défense en profondeur : les guardrails Foundry bloquent (section 9), Defender for AI alerte et corrèle, la AI gateway limite et filtre en amont. Un jailbreak « détecté mais non bloqué » signifie souvent un guardrail trop permissif.

9. Les guardrails de Microsoft Foundry#

9.1 Les notions#

Un guardrail est une collection nommée de contrôles. Chaque contrôle définit un risque à détecter, un point d'intervention où le chercher et une action. Les guardrails s'appliquent aux modèles et aux agents (guardrails d'agents en préversion), grâce aux classifieurs d'Azure AI Content Safety. Rôle requis : Foundry Account Owner (les rôles « Azure AI User / Owner / Account Owner / Project Manager » ont été renommés « Foundry … »).

Niveaux de blocage des quatre risques de contenu : Off, Low (bloque seulement la gravité élevée, le moins strict), Medium (moyenne et élevée), High (faible, moyenne et élevée, le plus strict). Le contenu « Safe » n'est jamais bloqué. Désactiver le filtrage en sortie n'est possible qu'aux clients approuvés (formulaire Modified Guardrails).

Actions : Annotate (modèles seulement) ou Annotate and block (modèles et agents).

9.2 Héritage et valeurs par défaut#

• Les modèles reçoivent par défaut le guardrail Microsoft.DefaultV2 : haine, violence, sexuel, automutilation au seuil Moyen sur les invites et les complétions, User prompt attacks sur les invites, Protected material (texte et code) sur les complétions. La détection des attaques sur les documents est désactivée par défaut. DefaultV2 n'est pas modifiable : on crée un guardrail personnalisé.
• Un agent sans guardrail personnalisé hérite de celui de son déploiement de modèle.
• Un guardrail affecté à l'agent remplace entièrement celui du modèle (pas de cumul) : si l'agent n'a aucun contrôle sur les appels d'outils, ils ne sont pas analysés, même si le modèle avait un guardrail strict.
• Chaque point d'intervention ajoute environ 50 à 100 ms de latence.
• Les agents hébergés peuvent aussi recevoir des contrôles de sortie réseau (préversion) dans le même guardrail.

Mise en œuvre : Foundry portal > projet > Guardrails > Create guardrail > choisir les risques, les points d'intervention et l'action > affecter le guardrail aux déploiements et aux agents. Bonnes pratiques Microsoft : tester dans le playground, régler les Prompt Shields séparément des seuils de contenu, faire du red teaming, mesurer après chaque changement.

10. Le Data and AI security dashboard#

10.1 Le tableau de bord#

Defender for Cloud > Data and AI security dashboard : une vue unique des ressources de données et d'IA, de leurs risques et de leur niveau de protection.

Prérequis pour un tableau de bord complet : Defender CSPM avec l'extension sensitive data discovery, Defender for Storage, Defender for Databases, AI threat protection, et chaque abonnement inscrit au fournisseur Microsoft.Security. Autorisations de lecture : Microsoft.Security/assessments/read, .../subassessments/read, .../alerts/read.

10.2 AI-SPM : la posture de sécurité de l'IA#

Le plan Defender CSPM protège les applications d'IA générative tout au long de leur cycle de vie :

• découverte continue des charges d'IA dans Azure OpenAI, Foundry, Azure Machine Learning, Amazon Bedrock et Google Vertex AI, et constitution de la nomenclature IA (AI BOM) : composants, données, artefacts, du code au cloud ;
• vulnérabilités des bibliothèques (TensorFlow, PyTorch, LangChain) dans le code et les images ;
• recommandations (identité, sécurité des données, exposition à Internet) et attack path analysis (par exemple vers les données de fondement ou d'ajustement) ;
• contrôles IaC : utiliser des private endpoints pour Azure AI Services, restreindre leurs points de terminaison, utiliser une managed identity, utiliser l'authentification par identité (pas de clés).

Il existe aussi le Microsoft Security Dashboard for AI (ai.security.microsoft.com), destiné aux responsables sécurité : inventaire des agents, modèles et applications d'IA (y compris tiers et serveurs MCP) à partir d'Entra, Defender, Purview et Security Copilot.

11. Les agents dans le Microsoft 365 admin center#

11.1 Le registre et les actions#

Microsoft 365 admin center > Agents > All agents : le Agent Registry (Agent Registry) liste tous les agents de l'organisation, quels que soient leur plateforme, éditeur et canal, y compris ceux enregistrés dans Entra. Filtres utiles : Availability (tous les utilisateurs, personne), Missing an owner (agents sans propriétaire à traiter).

Avant de déployer, l'onglet Permissions de la fiche de l'agent montre les autorisations déléguées et d'application demandées, et l'onglet Certification l'attestation de l'éditeur et la certification Microsoft 365 (valable 12 mois). C'est là qu'on évalue le risque de surpartage par l'agent.

11.2 Les paramètres des agents#

Agents > Settings :

Les agents Copilot Studio ont aussi leurs propres réglages dans le Power Platform admin center (environnements, DLP, détection des menaces).

11.3 Les rôles#

Moindre privilège : pour gérer les agents, l'AI Administrator suffit ; le Global Administrator est réservé aux urgences. Les rôles par produit (Power Platform Administrator…) ne gouvernent que leur périmètre.

12. Labs conseillés#

À faire dans un locataire et un abonnement de test (un locataire d'essai Microsoft 365 E5 avec quelques licences Copilot suffit pour les labs 1 et 2 ; les fonctionnalités en préversion peuvent ne pas être visibles partout).

Lab 1 : surexposition SharePoint.

1. Créer un site « RH-test », y déposer un fichier, le partager par un lien Anyone et avec Everyone except external users.
2. SharePoint admin center > Reports > Data access governance : lancer le rapport Site permissions across your organization.
3. Appliquer Restricted Content Discovery au site (Set-SPOSite … -RestrictContentOrgWideSearch $true).
4. Résultat attendu : un utilisateur qui a les droits ouvre toujours le fichier par son URL, mais ne le trouve plus par la recherche d'organisation ni par Copilot.

Lab 2 : DSPM.

1. Vérifier que Purview Audit est actif, puis ouvrir DSPM dans le Microsoft Purview portal.
2. Activer les one-click policies Detect sensitive info added to AI sites et Protect sensitive data from Copilot processing.
3. Résultat attendu : après environ 24 h, les interactions apparaissent dans l'Activity explorer (onglet AI activities).

Lab 3 : AI gateway APIM devant Foundry.

1. Créer une ressource Foundry avec un petit déploiement de modèle et une instance APIM (niveau Developer ou Basic v2).
2. APIs > Create from Azure resource > Microsoft Foundry : vérifier la managed identity et le backend créés.
3. Ajouter llm-token-limit à 500 jetons par minute, puis appeler l'API en boucle.
4. Résultat attendu : réponse 429 au-delà de la limite ; désactiver ensuite les clés de la ressource (disableLocalAuth) et constater que l'API passe toujours par la managed identity.

Lab 4 : Defender for AI Services et guardrails.

1. Activer le plan AI services sur l'abonnement de test, avec Suspicious prompt evidence.
2. Dans le playground Foundry, envoyer une invite de jailbreak classique au déploiement.
3. Créer un guardrail personnalisé avec User prompt attack en Annotate and block, l'affecter au déploiement et rejouer l'invite.
4. Résultat attendu : une alerte « Jailbreak attempt … detected » puis « … blocked » dans Defender for Cloud et le portail Defender.

Lab 5 : agents dans Entra et Microsoft 365.

1. Microsoft Entra admin center > Agents : parcourir les agent identities existantes (un agent Foundry publié en crée une).
2. Créer une stratégie Conditional Access en mode Report-only ciblant All agent identities avec Bloquer.
3. Microsoft 365 admin center > Agents : repérer un agent, consulter ses autorisations, le bloquer puis le débloquer.
4. Résultat attendu : l'impact de la stratégie visible dans les journaux de connexion des agents, sans rien bloquer réellement.

13. Les pièges d'examen#

14. Scénarios d'entraînement#

1. Contoso déploie Microsoft 365 Copilot. Le RSSI craint que des sites Finance trop partagés remontent dans les réponses, mais les propriétaires ont besoin de deux semaines pour revoir les accès. Que faire immédiatement, puis durablement ?

Immédiatement : Restricted Content Discovery sur les sites Finance (hors recherche d'organisation et Copilot, sans changer les droits). Ensuite : rapport Site permissions across your organization et Site access review par les propriétaires, RAC si besoin, sensitivity label de site, puis retirer RCD (mesure temporaire).

2. Le service conformité veut savoir quels utilisateurs collent des numéros de carte bancaire dans des chatbots tiers, et les bloquer quand leur risque est élevé.

DSPM : intégrer les appareils à Purview, déployer la browser extension, activer les one-click policies Detect sensitive info added to AI sites puis Block sensitive info from AI sites (DLP avec Adaptive Protection, blocage avec dérogation pour les utilisateurs à risque élevé).

3. Un agent Copilot Studio lit des e-mails et peut en envoyer. Vous craignez qu'un e-mail piégé lui fasse envoyer des données à un domaine externe. Quelle protection et quelle règle ?

Real-time protection de Defender pour Copilot Studio (app registration avec FIC, configuration dans le Power Platform admin center par environnement, App ID dans Defender), puis une custom rule de blocage avec les types Unsafe email domain et Secret exfiltration, et le connecteur Microsoft 365 pour les alertes.

4. Les agents autonomes de Fabrikam ne doivent accéder qu'aux ressources RH s'ils ont été validés par la RH. Comment l'imposer à grande échelle ?

Custom security attributes sur les agent identities (AgentApprovalStatus) et les ressources (Department), puis une stratégie Conditional Access : Agents > toutes les agent identities, exclure celles dont l'attribut contient HR_Approved, Bloquer, en Report-only d'abord. Licence Agent 365 (ou E7) + au moins P1.

5. ID Protection signale un agent avec « Unfamiliar resource access » et « Suspicious credential usage ». Après analyse, il est compromis. Que faire ?

Confirmer la compromission (risque Élevé), ce qui déclenche une stratégie Agent risk = High : Bloquer si elle existe ; éventuellement désactiver l'agent ou son blueprint (coupe-circuit), retirer les informations d'identification ajoutées au blueprint, ouvrir l'incident dans Defender XDR et regarder le blast radius.

6. Un agent a besoin de lire un site SharePoint pendant trois mois pour un projet. Comment donner cet accès proprement ?

Un access package ouvert aux agents avec approbation et expiration ; le sponsor fait la demande depuis My Access ; à l'approche de l'échéance il est prévenu et peut demander une prolongation ; sinon l'accès expire seul.

7. Trois équipes appellent le même déploiement Foundry ; l'une consomme tout le quota et les autres reçoivent des erreurs. Les développeurs utilisent la clé de la ressource. Que proposer ?

Une AI gateway APIM : import Microsoft Foundry (managed identity vers le back-end, suppression des clés côté clients), llm-token-limit par abonnement (TPM et quota), llm-emit-token-metric pour la refacturation, un pool de back-ends avec un PTU en priorité et un déploiement à l'utilisation en débordement. Désactiver ensuite les clés de la ressource (disableLocalAuth).

8. Le SOC reçoit « A Jailbreak attempt on an Azure AI model deployment was detected by Prompt Shields » plusieurs fois par jour, sans blocage. Pourquoi, et quoi changer ?

Prompt Shields a détecté sans bloquer (réglage du filtrage ou faible confiance). Vérifier que le guardrail du déploiement (ou de l'agent) contient le contrôle User prompt attack en action Annotate and block sur l'entrée utilisateur ; ajouter éventuellement llm-content-safety avec shield-prompt="true" dans la passerelle.

9. Un agent Foundry utilise un modèle protégé par un guardrail strict. Vous lui affectez un guardrail personnalisé contenant seulement des contrôles sur l'entrée et la sortie. Les réponses des outils sont-elles analysées ?

Non. Le guardrail de l'agent remplace entièrement celui du modèle ; il faut ajouter des contrôles aux points Tool call et Tool response (préversion).

10. La direction veut une vue unique de la posture de sécurité des données et de l'IA dans Azure, avec les attack paths vers les données de fondement.

Activer Defender CSPM (avec la sensitive data discovery), Defender for Storage, Defender for Databases et la protection IA, puis utiliser le Data and AI security dashboard (section AI closer look) et l'AI-SPM.

11. Un utilisateur a publié un agent Copilot Studio vers Teams et Microsoft Copilot. Il n'apparaît pas pour les autres. Où le valider, et avec quel rôle minimal ?

Microsoft 365 admin center > Agents : l'agent est une demande ; un AI Administrator vérifie ses autorisations et le publie (ou le rejette), puis l'attribue ou le déploie à des groupes.

15. Pour aller plus loin (au-delà de l'examen)#

• OWASP Top 10 pour les applications LLM (2025) : référence citée par Microsoft. Les risques les plus liés à ce chapitre : LLM01 Prompt Injection (Prompt Shields, real-time protection), LLM02 Sensitive Information Disclosure (Purview, SAM, détection de vol d'identifiants), LLM08 Vector and Embedding Weaknesses (protéger les index de recherche et les données de fondement), et pour les agents l'agentivité excessive (moindre privilège par outil, validation humaine des actions à fort impact). À compléter par MITRE ATLAS.

• Responsabilité partagée de l'IA : Microsoft recommande de commencer par le SaaS (Copilot), puis le PaaS (Foundry) si besoin, et de réserver les modèles personnalisés aux organisations très expertes : plus on descend, plus la part de responsabilité du client augmente. Pour les agents, Microsoft publie un modèle dédié (injection vers action, agentivité excessive, « confused deputy », empoisonnement de la mémoire, boucles sans fin, agents usurpés).

• Sécurité réseau et accès de Foundry : points de terminaison privés, désactivation de l'accès public, managed identity, et désactivation des clés (authentification Entra seule) :

  # Désactiver l'authentification par clé d'une ressource Foundry (Azure AI Services) ; Entra ID devient la seule méthode
  Set-AzCognitiveServicesAccount -ResourceGroupName "rg-ia-prd" -Name "foundry-ia-prd" -DisableLocalAuth $true
  

  À l'échelle : la stratégie Azure intégrée « Azure AI Services resources should have key access disabled (disable local authentication) » (Audit, Deny) ou disableLocalAuth: true dans Bicep. L'effet n'est pas immédiat (cache de la passerelle, jusqu'à quelques heures) : vérifier qu'une ancienne clé renvoie 401. Voir le chapitre 06 pour Private Link.

• Purview DLP pour Copilot : l'emplacement Microsoft 365 Copilot des stratégies DLP permet d'empêcher le traitement d'éléments étiquetés et de détecter les informations sensibles dans les invites.

• Microsoft cloud security benchmark v2, domaine « Artificial Intelligence Security » : contrôles AI-1 (modèles approuvés), AI-2 (filtrage multicouche), AI-3 (méta-invites de sécurité), AI-4 (moindre privilège des fonctions d'agent), AI-5 (humain dans la boucle), AI-6 (surveillance), AI-7 (red teaming continu).

• Liens avec les autres chapitres : identités et Conditional Access au chapitre 01, secrets au chapitre 02, APIM et WAF au chapitre 09, Defender for Cloud et Defender CSPM au chapitre 10, Sentinel au chapitre 11, Security Copilot au chapitre 12.

16. Fiche à retenir#

• Copilot respecte les autorisations : l'IA amplifie la surexposition existante.
• Data access governance reports (SharePoint admin center) : Site permissions (instantané, 1er rapport jusqu'à 5 jours, tous les 30 jours), Sharing links et EEEU (28 jours).
• RCD = hors recherche et Copilot, sans changer les droits, temporaire ; RAC = accès réservé à 10 groupes max ; revue d'accès = déléguée au propriétaire ; RSS = retiré.
• DSPM : audit activé, appareils intégrés + browser extension pour l'IA tierce, stratégies en un clic, évaluation hebdo des 100 sites les plus utilisés.
• DLP « Protect sensitive data from Copilot processing » empêche Copilot de traiter des éléments étiquetés.
• Copilot Studio : UPIA et XPIA intégrés ; real-time protection avant chaque appel d'outil (préversion), generative orchestration seulement, 1 s puis autorisé par défaut, FIC sans secret, Power Platform admin + Security admin, connecteur M365 pour les alertes.
• Règles de protection : par défaut = audit, personnalisées = blocage ; table BehaviorInfo.
• Entra Agent ID : blueprint (détient les identifiants) → agent identities (sans identifiant) → agent user account optionnel 1:1 ; sponsor obligatoire (métier), propriétaire (technique).
• Conditional Access : une stratégie par sujet (utilisateurs / agent identities / agent users) ; clé d'API = pas Conditional Access ; licence Agent 365 ou E7 (+ P2 pour le risque).
• ID Protection : Confirmer la compromission → risque Élevé → stratégie de blocage ; en OBO, le risque va à l'utilisateur.
• Accès des agents par access packages avec expiration, demandés par l'agent, le sponsor ou un admin.
• Defender XDR : AI agents (niveau de risque ≠ recommandations), table AgentsInfo, View blast radius dans l'incident, actifs critiques classés.
• AI gateway APIM : import Foundry = managed identity + backend ; llm-token-limit 429 / 403 ; llm-content-safety seuil 0 à 7, 403 ; semantic cache Redis ; llm-emit-token-metric ; pool à priorités + circuit breaker.
• Defender for AI Services : GA, par abonnement (Owner ou Contributor), texte seulement, 30 jours / 75 milliards de jetons d'essai, preuves d'invite en option, alertes jailbreak, vol d'identifiants, ASCII smuggling, hameçonnage, wallet.
• Guardrails Foundry : contrôle = risque + point d'intervention (entrée, appel d'outil, réponse d'outil, sortie) + action ; DefaultV2 au seuil Moyen ; guardrail de l'agent remplace celui du modèle.
• Data and AI security dashboard : Defender CSPM + sensitive data discovery + Storage + Databases + IA ; AI-SPM = AI BOM, recommandations, attack paths.
• Microsoft 365 admin center : Agent Registry, publier, attribuer, déployer (consent pour les utilisateurs), bloquer (toutes les instances), suppression récupérable 30 jours ; rôle AI Administrator.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn (page en anglais quand la version française n'existe pas encore) :

• Guide d'étude de l'examen SC-500
• Préparer Microsoft Copilot et les agents avec SharePoint Advanced Management
• Data access governance reports
• Gérer les rapports DAG avec PowerShell
• Restricted Content Discovery
• Restricted Access Control des sites SharePoint
• Site access reviews
• Restricted SharePoint Search (retrait)
• Learn about Data Security Posture Management
• Data Security Posture Management for AI (classic)
• Considerations for DSPM for AI (prérequis, one-click policies)
• Enable external threat detection for Copilot Studio custom agents (preview)
• Enable security for AI agents using Microsoft Defender
• Protect AI agents in real time using Microsoft Defender
• Discover AI agents and assess security posture
• AI agent posture risk in Microsoft Defender
• Detect and investigate threats to AI agents
• Investigate incidents : blast radius analysis
• What is Microsoft Entra Agent ID?
• Microsoft Entra Agent ID key concepts
• Create an agent identity blueprint
• Best practices for Microsoft Entra Agent ID
• Conditional Access for agents
• Secure autonomous agents with Conditional Access
• Secure agents that act as users with Conditional Access
• ID Protection for agents
• Governing agent identities
• AI gateway in Azure API Management
• Import a Microsoft Foundry API
• Authenticate and authorize access to LLM APIs
• Limit LLM API token usage (llm-token-limit)
• Enforce content safety checks on LLM requests (llm-content-safety)
• AI threat protection in Microsoft Defender for Cloud
• Enable threat protection for AI services
• Alerts for AI services
• Guardrails and controls overview in Microsoft Foundry
• Default Guardrail policies for Microsoft Foundry
• Prompt Shields
• Data and AI security dashboard
• AI security posture management
• Microsoft Security Dashboard for AI
• Agents admin guide for Microsoft 365
• Governance and lifecycle actions for agents
• Agent settings in Microsoft 365 admin center
• Agent management roles and permissions
• Microsoft Agent 365 service description
• Disable local authentication in Foundry Tools
• AI shared responsibility model
• Microsoft cloud security benchmark v2 : Artificial Intelligence Security