Accès conditionnel pour agents IA : gouvernance des identités non humaines

Les identités non humaines : un nouveau périmètre de gouvernance

L'émergence des agents IA autonomes recompose en profondeur les stratégies de gestion des identités. Pendant longtemps, les équipes sécurité se sont concentrées sur les utilisateurs humains, puis sur les identités de charge de travail — applications et services. Aujourd'hui, une troisième vague s'impose : des entités capables d'agir de manière autonome, d'enchaîner des appels d'API, de consommer des ressources cloud et d'accéder à des données sensibles, sans intervention humaine directe.

Ces agents, bots et orchestrateurs constituent désormais une surface d'attaque à part entière. Les traiter comme des citoyens de seconde zone dans la stratégie Zero Trust n'est plus tenable. Cet article propose une architecture de référence pour appliquer l'accès conditionnel aux identités non humaines, avec des recommandations concrètes pour les équipes Identity & Access Management.

Cartographie des identités d'entreprise : quatre familles distinctes

Avant de définir des politiques, il est indispensable de comprendre le paysage complet des identités présentes dans un environnement Microsoft 365 et Azure. On distingue quatre grandes catégories :

• Identités humaines : utilisateurs finaux, administrateurs, comptes invités — gérés via Microsoft Entra ID.
• Identités de charge de travail : applications, pipelines CI/CD, services backend — représentés par des principaux de service ou des identités managées.
• Identités non humaines : agents IA, bots conversationnels, orchestrateurs autonomes — la catégorie émergente au cœur de cet article.
• Identités de service : comptes de service, managed identities, service principals dédiés à des automatisations spécifiques.

Cette segmentation n'est pas qu'une question de nomenclature. Chaque famille présente un comportement distinct, une surface d'attaque propre et des exigences de contrôle différentes. Un agent IA peut prendre des décisions, invoquer des outils externes et modifier l'état de systèmes tiers — des capacités qu'un compte utilisateur classique ne possède pas. Appliquer les mêmes politiques à ces entités sans adaptation reviendrait à ignorer leur nature fondamentalement différente.

Le contexte de l'agent : les attributs clés pour l'évaluation conditionnelle

L'accès conditionnel classique évalue trois dimensions : l'identité de l'utilisateur, la conformité de l'appareil et la localisation réseau. Pour un agent IA, ce modèle doit être enrichi avec un ensemble d'attributs contextuels spécifiques :

Attributs d'identité de l'agent

• Agent ID : identifiant unique et immuable de l'agent au sein du registre d'identités.
• Owner / Creator : propriétaire ou équipe responsable de l'agent — indispensable pour l'imputabilité.
• Purpose : finalité déclarée de l'agent (traitement de données RH, analyse de logs, automatisation IT, etc.).
• Capabilities : liste des outils et permissions accordés à l'agent.

Attributs opérationnels et de risque

• Runtime : environnement d'exécution (Azure Container Apps, Azure Functions, on-premises, etc.).
• Data Access Needs : périmètre de données requis pour accomplir la tâche.
• Tooling : outils tiers ou internes que l'agent peut invoquer (Graph API, connecteurs Power Platform, etc.).
• Risk Score : score de risque calculé dynamiquement, tenant compte du comportement récent et des anomalies détectées.

Ce contexte enrichi est la matière première de toute politique d'accès conditionnel efficace. Sans lui, la passerelle de sécurité ne peut évaluer qu'une identité anonyme, sans comprendre ce qu'elle fait ni pourquoi.

Architecture de la passerelle de politique d'accès conditionnel

Entre l'agent IA et les ressources protégées de l'entreprise s'interpose une passerelle de politique structurée en quatre étapes séquentielles. Cette passerelle constitue le point de contrôle central de la gouvernance des identités non humaines.

1curl -X POST https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token \
2  -H "Content-Type: application/x-www-form-urlencoded" \
3  -d "client_id={agentClientId}" \
4  -d "client_secret={agentClientSecret}" \
5  -d "scope=https://graph.microsoft.com/.default" \
6  -d "grant_type=client_credentials"

1# Créer une politique d'accès conditionnel pour les workload identities
2$params = @{
3    displayName = "CA-AgentIA-RiskControl"
4    state = "enabled"
5    conditions = @{
6        clientAppTypes = @("all")
7        servicePrincipalRiskLevels = @("high", "medium")
8        applications = @{
9            includeApplications = @("All")
10        }
11        servicePrincipals = @{
12            includeServicePrincipals = @("All")
13            excludeServicePrincipals = @("excludedAgentGroupId")
14        }
15    }
16    grantControls = @{
17        operator = "OR"
18        builtInControls = @("block")
19    }
20}
21 
22New-MgIdentityConditionalAccessPolicy -BodyParameter $params

1// Requête KQL pour surveiller les accès des agents IA dans Sentinel
2SigninLogs
3| where AppDisplayName startswith "Agent-"
4| where RiskLevelDuringSignIn in ("high", "medium")
5| project TimeGenerated, AppDisplayName, ResourceDisplayName, RiskLevelDuringSignIn, ConditionalAccessStatus
6| order by TimeGenerated desc

Ressources protégées : le périmètre d'application des politiques

Les politiques d'accès conditionnel pour agents IA doivent couvrir l'ensemble des ressources susceptibles d'être atteintes par ces entités autonomes :

• Charges de travail cloud : machines virtuelles Azure, conteneurs (AKS), fonctions serverless.
• API et services : Microsoft Graph API, API internes exposées via Azure API Management, services partenaires.
• Sources de données : bases de données SQL/NoSQL, Azure Data Lake, Azure Blob Storage.
• Outils et plateformes : connecteurs SaaS, pipelines DevOps, plateformes d'automatisation (Power Automate).
• Services IA et analytiques : Azure OpenAI Service, Azure Machine Learning, Azure Cognitive Services.

Trois piliers opérationnels pour une gouvernance efficace

1. Inventaire des identités (Identity Inventory)

Impossible de sécuriser ce que l'on ne connaît pas. L'inventaire est le fondement absolu de toute stratégie de gouvernance des agents IA. Cela implique :

• Découvrir tous les agents déployés, qu'ils soient développés en interne ou issus de solutions tierces.
• Cartographier leurs chemins d'accès : quelles API appellent-ils ? Quelles données lisent-ils ?
• Identifier leurs propriétaires et les équipes responsables.
• Maintenir cet inventaire à jour via des processus automatisés (scanning régulier des principaux de service dans Entra ID).

1# Lister tous les principaux de service actifs dans Entra ID (agents candidats à l'inventaire)
2Get-MgServicePrincipal -All | Where-Object { $_.AppRoles.Count -gt 0 } |
3  Select-Object DisplayName, AppId, CreatedDateTime |
4  Export-Csv -Path "agent-inventory.csv" -NoTypeInformation

2. Attestation d'exécution (Runtime Attestation)

Un agent IA n'a pas d'appareil au sens traditionnel du terme — impossible de vérifier sa conformité Intune. En revanche, son environnement d'exécution peut et doit être attesté :

• Valider que le runtime (conteneur, fonction, machine virtuelle) répond aux standards de sécurité définis.
• Utiliser des mécanismes comme Azure Confidential Computing ou les attestations de workload identity pour garantir l'intégrité de l'environnement.
• Bloquer tout accès depuis des environnements non attestés ou non reconnus.

Référence : Azure Attestation Service

3. Contrôle de dérive des politiques (Policy Drift Control)

Les agents IA évoluent : de nouvelles capacités leur sont régulièrement attribuées, de nouveaux outils connectés. Chaque extension du périmètre d'un agent doit déclencher automatiquement une revue de gouvernance :

• Mettre en place des alertes sur les modifications de rôles ou de permissions des principaux de service.
• Intégrer la revue des accès agents dans les cycles d'Access Reviews d'Entra ID.
• Documenter chaque changement de capacité avec son justificatif métier.

Référence : Entra ID Access Reviews

Comparaison : accès conditionnel utilisateur vs agent IA

Intégration dans une stratégie Zero Trust globale

Les agents IA ne doivent pas être gouvernés en silo. Leur intégration dans la stratégie Zero Trust de l'organisation repose sur les mêmes principes fondamentaux — vérifier explicitement, appliquer le moindre privilège, supposer la compromission — mais avec des contrôles adaptés à leur nature non humaine.

Dans l'écosystème Microsoft 365 et Azure, plusieurs services contribuent directement à cette gouvernance :

• Microsoft Entra ID : registre d'identités, accès conditionnel, Access Reviews.
• Microsoft Sentinel : détection d'anomalies comportementales, corrélation des logs.
• Microsoft Defender for Cloud : protection des workloads et des runtimes.
• Azure API Management : gouvernance et throttling des appels API des agents.
• Microsoft Purview : classification et protection des données accédées par les agents.

Conclusion : l'inventaire comme fondation incontournable

La gouvernance des agents IA autonomes n'est pas une évolution incrémentale de l'IAM traditionnel — c'est un changement de paradigme. Ces entités agissent, décident et accèdent à des ressources sensibles à une échelle et une vitesse que les processus manuels ne peuvent pas suivre.

Le message est clair : l'inventaire des identités est le point de départ non négociable. Sans connaissance exhaustive des agents déployés, de leurs propriétaires, de leurs finalités et de leurs chemins d'accès, aucune politique d'accès conditionnel ne peut être efficace.

À mesure que les agents autonomes prolifèrent dans les environnements Microsoft 365, Azure et Power Platform, intégrer les identités non humaines dans la stratégie Zero Trust n'est plus un projet futur — c'est une obligation de gouvernance à adresser dès aujourd'hui.