Calipia : le blog

Il existe dans la vie d’un administrateur Microsoft 365 un genre littéraire à part entière : la note du Message Center dont le titre commence par « Action may be required ». Traduction libre : « nous allons changer quelque chose dans votre tenant, et si cela ne vous convient pas, c’est à vous de faire le nécessaire ». La note MC1506733, publiée le 13 octobre 2026, appartient à cette catégorie, et elle mérite plus qu’un coup d’œil distrait entre deux réunions. Merci à Fabrice L. de me l’avoir fait remarquer !

Ce que dit la note

Microsoft introduit dans Microsoft Entra ID une nouvelle autorisation au niveau des permissions par défaut des utilisateurs, intitulée « Users can create agent blueprints ». Jusque-là, rien de choquant : ajouter un levier de gouvernance est plutôt une bonne nouvelle. Le problème tient dans sa valeur par défaut. À partir du 4 novembre 2026, avec un déploiement mondial qui doit s’achever fin novembre, ce paramètre sera positionné sur « Oui ». Concrètement, tout utilisateur standard, c’est-à-dire sans aucun rôle Entra intégré ou personnalisé, pourra créer de nouveaux agent blueprints dans l’organisation.

Si l’administrateur bascule le paramètre sur « Non », seuls les administrateurs habilités et les comptes détenteurs du rôle Agent ID Developer conserveront cette capacité. Point important pour la planification : le réglage peut être modifié dès maintenant, mais il ne prendra effet qu’au moment où le déploiement atteindra le tenant. Autrement dit, il est possible (et vivement conseillé) de fermer la porte avant que Microsoft ne l’ouvre.

Un blueprint, c’est quoi au juste ?

Le terme sonne comme un document d’architecture que personne ne lit, mais il s’agit d’un objet bien réel de la plateforme Entra Agent ID. Un agent blueprint est un modèle d’administration et de sécurité destiné à gérer des agents IA à l’échelle. Il porte une description de l’agent, la définition des rôles applicatifs qui peuvent être attribués aux utilisateurs et autres principaux, l’éditeur vérifié, ainsi que les paramètres des protocoles d’authentification, par exemple les claims optionnels injectés dans les jetons d’accès. Toutes les identités d’agents créées à partir de ce modèle héritent de ces propriétés.

Pour un architecte, la ressemblance avec une inscription d’application (app registration) saute aux yeux. Un blueprint joue pour les agents le rôle qu’une app registration joue pour les applications : c’est le moule à partir duquel on fabrique des identités capables d’obtenir des jetons et donc d’accéder à des ressources. Et c’est précisément là que le bât blesse.

Le précédent des inscriptions d’applications

Depuis des années, la plupart des experts Entra ID recommandent de désactiver le paramètre « Users can register applications » (allowedToCreateApps dans la politique d’autorisation du tenant). Le raisonnement est simple : un utilisateur métier n’a quasiment jamais de besoin légitime de créer une application inscrite. En revanche, un attaquant qui compromet un compte connaît parfaitement le fonctionnement des inscriptions et des consentements, et peut s’en servir pour établir une persistance discrète. Les campagnes d’illicit consent grant et les applications OAuth malveillantes ne sont pas des hypothèses d’école.

La même logique s’applique mot pour mot aux agent blueprints. On imagine mal un comptable arriver un lundi matin avec la ferme intention de concevoir le prochain modèle d’identité d’agent de l’entreprise. On imagine beaucoup mieux un compte compromis qui s’en charge à sa place. Tony Redmond, dans son analyse publiée sur Office 365 for IT Pros, ne mâche pas ses mots : il qualifie le choix d’une activation par défaut de déroutant et le juge difficilement compatible avec les principes affichés par Microsoft dans sa Secure Future Initiative. Difficile de lui donner tort. On ne peut pas, d’un côté, prôner le « secure by default » dans chaque keynote et, de l’autre, livrer une capacité de création d’identités non humaines ouverte à tous.

Microsoft précise d’ailleurs que ce nouveau paramètre est indépendant de « Users can register applications ». Un tenant correctement verrouillé côté applications ne l’est donc pas automatiquement côté agents. Les deux réglages doivent être revus séparément, ce qui fera sans doute le bonheur des auditeurs et un peu moins celui des équipes d’exploitation.

Ce que le changement ne fait pas

Pour être juste, la note borne clairement le périmètre. Le paramètre ne concerne que la création de nouveaux blueprints par des utilisateurs standards. Il ne modifie ni ne supprime les blueprints existants, ne change pas qui peut créer des identités d’agents à partir de blueprints déjà présents, n’empêche pas une application ou un agent de créer des identités, et n’affecte pas les prérequis propres aux plateformes comme Microsoft Foundry ou Security Copilot, qui continuent d’exiger licences et abonnements Azure. En clair, ouvrir la création de blueprints ne permet pas à un utilisateur de déployer gratuitement un agent dans Foundry. Mais cela lui permet de créer dans l’annuaire des objets d’identité dont personne n’a validé l’existence.

La note jumelle : MC1506728

Publiée le même jour, la note MC1506728 apporte un éclairage complémentaire, et cette fois dans le bon sens. Aujourd’hui, le principal de service associé à chaque agent blueprint reçoit automatiquement la permission applicative Microsoft Graph AgentIdentity.CreateAsManager, sans approbation d’un administrateur, et la documentation indique que cette attribution ne peut pas être révoquée. Cette permission permet à l’agent de créer, sans utilisateur connecté, des identités d’agents qui lui sont rattachées. Une sorte de passe-partout, en somme.

À partir du 4 novembre, Entra cessera d’accorder automatiquement cette permission. Un administrateur devra la consentir explicitement aux agents qui en ont réellement besoin, et elle deviendra révocable. L’octroi explicite est possible depuis le 16 octobre, via un consentement administrateur à l’échelle du tenant ou une attribution manuelle de rôle applicatif. Les agents qui reposent sur une authentification app-only pour créer leurs propres identités et qui ne disposent d’aucune autre autorisation risquent de recevoir des erreurs HTTP 403 une fois l’application de la règle effective.

Le paradoxe est savoureux : le même jour, Microsoft resserre les permissions des agents eux-mêmes et desserre celles des humains qui peuvent en fabriquer les modèles. On ferme la fenêtre, on ouvre la porte en quelque sorte 🙂

Les conséquences pour les DSI

Le premier risque est sécuritaire. Chaque blueprint est un point d’entrée potentiel vers la création d’identités non humaines. Dans un contexte où les identités de workload et d’agents dépassent déjà largement en nombre les identités humaines dans beaucoup de tenants, laisser n’importe quel compte en créer de nouveaux élargit mécaniquement la surface d’attaque.

Le deuxième risque est organisationnel. Microsoft a un historique bien documenté en matière de création libre d’objets par les utilisateurs. Les équipes Teams créées pour un projet de trois semaines et abandonnées depuis trois ans en sont l’exemple le plus parlant. Reproduire ce schéma avec des agents IA, qui disposent de permissions et agissent de manière autonome, serait autrement plus coûteux qu’une poignée de canaux Teams orphelins.

Le troisième risque concerne la gouvernance et la conformité. Le modèle d’administration d’Entra Agent ID distingue les propriétaires, responsables techniques de la configuration et des secrets, et les sponsors, représentants métier responsables de la finalité et du cycle de vie de l’agent. Ce modèle n’a de sens que si la création des blueprints passe par un circuit maîtrisé. Des objets nés hors de tout processus échapperont naturellement aux revues d’accès et aux registres de traitements, ce qui ne manquera pas d’intéresser les DPO à l’heure de l’AI Act. Autant d’éléments sur lesquels nous reviendrons lors du prochain Briefing Calipia avec une session sur la gouvernance des agents.

Plan d’action recommandé

La première mesure est immédiate : dans le centre d’administration Microsoft Entra, aller dans Entra ID, puis Utilisateurs, puis Paramètres utilisateur, repérer « Users can create agent blueprints » dans la section des permissions par défaut et le positionner sur « Non ». Le réglage peut être fait dès aujourd’hui et s’appliquera au moment du déploiement.

Dans la foulée, vérifier que « Users can register applications » est lui aussi désactivé, puisque les deux paramètres sont indépendants.

Ensuite, définir qui doit pouvoir créer des blueprints et leur attribuer le rôle Agent ID Developer, idéalement de manière éligible plutôt que permanente, via Privileged Identity Management, sur un groupe restreint et documenté.

Puis inventorier les blueprints et agents déjà présents dans le tenant, identifier ceux qui dépendent de l’attribution automatique de AgentIdentity.CreateAsManager et consentir explicitement la permission à ceux qui en ont un besoin avéré avant le 4 novembre, afin d’éviter les erreurs 403 en production.

Enfin, inscrire ces deux paramètres dans les revues de configuration régulières du tenant, au même titre que les politiques d’accès conditionnel. Un commentateur de l’article de Tony Redmond parie qu’une recommandation Secure Score apparaîtra bientôt pour désactiver ce paramètre. Il n’est pas nécessaire d’attendre que Microsoft se donne à lui-même un conseil pour l’appliquer.

En conclusion

La note MC1506733 n’est pas une catastrophe : elle introduit un contrôle utile et laisse plusieurs semaines pour le régler. Mais elle illustre une fois de plus une tension récurrente chez Microsoft entre la volonté d’accélérer l’adoption de l’IA agentique et le discours sur la sécurité par défaut. Pour les organisations, la règle reste la même : ce qui n’est pas explicitement fermé finit toujours par être utilisé. Et dans le cas des agents, de préférence par quelqu’un qui n’était pas invité.