Microsoft Entra wijzigt wie agent blueprints mag maken: zo houdt u de regie

Microsoft wijzigt wie in Microsoft Entra agent blueprints kan maken. Volgens Message Center-bericht MC1506733 begint de uitrol op 4 november 2026. Als de tenantinstelling Users can create agent blueprints niet op No staat, kunnen gewone gebruikers in de tenant agent blueprints maken. Microsoft verwacht dat de uitrol eind november 2026 is voltooid.

Dit verdient een bewuste keuze van de Entra-beheerder. Een agent blueprint is niet alleen een sjabloon: deze vormt de basisconfiguratie voor agentidentiteiten, met instellingen voor authenticatie, toegangsrechten en logging. De wijziging is dus vooral relevant voor organisaties die de creatie van nieuwe AI-agentidentiteiten centraal willen laten beoordelen of deze juist gecontroleerd aan een beperkte groep makers willen delegeren.

Wat verandert er precies?

Vanaf de start van de uitrol op 4 november 2026 kunnen standaardgebruikers in Microsoft Entra agent blueprints maken, tenzij de organisatie de tenantinstelling Users can create agent blueprints op No zet. De instelling bepaalt specifiek wie een agent identity blueprint en het bijbehorende principal-object kan maken. Het is daarmee een keuze over het ontstaan van nieuwe Entra-agentidentiteiten, geen algemene aan- of uitknop voor alle bestaande AI-functies in Microsoft 365.

Microsoft beschrijft een agent blueprint als de basisconfiguratie waaruit agentidentiteiten worden gemaakt. De blueprint kan onder meer kenmerken voor authenticatie, rollen en OAuth-toegang bevatten. Eén blueprint kan meerdere agentidentiteiten voortbrengen. Toegang en wijzigingen op blueprintniveau verdienen daarom dezelfde governanceaandacht als andere applicatie-identiteiten, zeker wanneer een agent met bedrijfsgegevens of API’s gaat werken.

Wat blijft mogelijk als u de instelling uitschakelt?

Wanneer Users can create agent blueprints op No staat, kunnen gebruikers niet meer op basis van de algemene tenantinstelling zelf een blueprint maken. Microsoft documenteert dat gebruikers met de rol Agent ID Developer of Agent ID Administrator dan wel agent blueprints en blueprint principals kunnen maken. Dat maakt een beheerst self-servicemodel mogelijk: niet iedere gebruiker krijgt standaard dit recht, maar een beperkte groep makers kan het krijgen via een toewijsbare Entra-rol.

De rolkeuze is relevant. Microsoft omschrijft Agent ID Developer als de rol waarmee een gebruiker een agent blueprint en bijbehorende blueprint principal maakt; de maker wordt vervolgens eigenaar van beide objecten. Kies daarom voor de minst ruime rol die het werk ondersteunt, wijs die tijdelijk of gericht toe waar dat past bij het eigen beleid, en leg vast wie eigenaar en sponsor van een blueprint is.

Waar stelt u dit in?

Een beheerder met ten minste de rol Cloud Application Administrator kan in het Microsoft Entra-beheercentrum naar Entra ID > Users > User settings gaan. Zet daar Users can create agent blueprints op No als blueprintcreatie niet breed beschikbaar mag zijn. Doe dit vóórdat de uitrol in uw tenant is afgerond wanneer een beperkte creatiegroep het uitgangspunt is.

Maak de wijziging niet los van de rest van het identiteitsbeleid. Controleer wie al toepassings- of agentgerelateerde beheerdersrollen heeft, welke delegatiemodellen voor applicatieregistraties bestaan en hoe nieuwe agents worden geregistreerd. Zo voorkomt u dat de ene route wordt afgesloten terwijl dezelfde bevoegdheid via een andere, al bestaande toewijzing breed beschikbaar blijft.

Scope en belangrijke beperkingen

De instelling beheerst het aanmaken van agent blueprints in Entra. Zij verleent of verwijdert niet automatisch toegang tot gegevens, verandert geen bestaande appregistraties en is geen vervanging voor beheertoestemming, Conditional Access, monitoring of een productspecifieke agentinstelling. Beoordeel die lagen afzonderlijk voordat een agent productiegegevens mag benaderen.

Ook nadat de algemene instelling op No staat, is eigenaarschap van belang. Microsoft documenteert dat eigenaren van een agent blueprint of blueprint principal agent identities voor die blueprint kunnen maken zonder zelf een Microsoft Entra Agent ID-rol te hebben. Als u de creatie van nieuwe agent identities wilt beheersen, moet u dus niet alleen de initiële blueprintcreatie beperken, maar ook de eigenaren, sponsors, machtigingen en activiteiten van bestaande blueprints periodiek beoordelen.

Een praktische governanceaanpak

Neem een beleidsbesluit. Bepaal of iedereen blueprints mag maken, of alleen een aangewezen groep makers. Leg vast welke typen agents zijn toegestaan, welke gegevens zij mogen gebruiken en welke beoordeling vooraf nodig is.
Controleer de huidige tenantinstelling. Bekijk vóór 4 november hoe Users can create agent blueprints staat en zet deze op No wanneer brede selfservice niet gewenst is. Leg de gekozen stand, eigenaar en reden vast in het wijzigingsregister.
Delegeer gericht. Ken Agent ID Developer alleen toe aan makers die het aantoonbaar nodig hebben. Vermijd een brede permanente toewijzing wanneer een tijdelijke of beperkte roltoewijzing voldoet.
Vereis eigenaar en sponsor. Een sponsor is in de Microsoft-documentatie verplicht bij het maken van een blueprint. Gebruik die verantwoordelijkheid in de praktijk: leg doel, proceseigenaar, gegevensbronnen, beoogde gebruikers en beëindigingsdatum vast voordat een blueprint in productie komt.
Beoordeel rechten apart. Een blueprint kan vereiste toegang en overerfbare machtigingen (inheritable permissions) beschrijven, maar beheertoestemming is een afzonderlijk besluit. Kies de minimale benodigde rechten, laat toestemming via het bestaande proces lopen en controleer welke toegang uiteindelijk effectief is.
Monitor en herbeoordeel. Gebruik de Entra-audit- en aanmeldingsgegevens om wijzigingen en gebruik te volgen. Beoordeel regelmatig inactieve blueprints, ongebruikte rechten, vertrokken eigenaren en agents die niet meer bij de oorspronkelijke bedoeling passen.

Waarom beheertoestemming en overerfbare rechten apart moeten worden beoordeeld

Een blueprint kan aangeven welke API’s en machtigingen een agent nodig heeft. Volgens Microsoft is zo’n verklaring op zichzelf geen autorisatie: een beheerder moet beheertoestemming voor het principal-object of een afzonderlijke agentidentiteit nog steeds apart verlenen. Verwar een toegestane blueprintcreatie dus niet met goedgekeurde toegang tot bedrijfsgegevens.

Bij overerfbare machtigingen kan een blueprint een basisset met gedelegeerde scopes of applicatierollen laten doorgeven aan agentidentiteiten. Dat kan beheer vereenvoudigen, maar vergroot ook het effect van een onzorgvuldig gekozen basisrechtenpakket. Begin daarom met de kleinst noodzakelijke, expliciet opgesomde rechten en controleer in auditlogs welke rechten werkelijk worden gebruikt. Breid pas uit wanneer een aantoonbare praktijktoepassing dit vereist.

Tijdlijn en volgende stap

MC1506733 noemt 4 november 2026 als start van de wijziging en eind november 2026 als verwachte voltooiing van de uitrol. Inventariseer daarom nu het gewenste selfservicebeleid, de doelgroep voor Agent ID Developer en het goedkeuringsproces voor nieuwe agents. Zo wordt de wijziging geen verrassende uitbreiding van rechten, maar een bewuste inrichting van identiteit en governance voor AI-workloads waarin agents taken uitvoeren.