AI-agents registreren in je eigen tenant: van n8n en Bedrock naar Entra Agent ID

Je agents draaien op n8n, LangChain of Bedrock, dus dat hele Agent 365-verhaal gaat niet over jou. Dat klopt precies één laag lang. Zodra zo'n agent iets uit Microsoft 365 nodig heeft, een agenda, een map in SharePoint, een lijst gebruikers, logt hij in. Meestal met de sleutel van een medewerker, of met een client secret in een omgevingsvariabele die niemand meer roteert. Vanaf dat moment staat er in je auditlog een mens waar een machine handelde.

Microsoft heeft daar sinds de algemene beschikbaarheid van Agent 365 op 1 mei 2026 een uitgewerkt pad voor, en dat pad is uitdrukkelijk ook bedoeld voor agents die je níet bij Microsoft bouwde. Deze gids loopt de handeling door: van inventariseren wat er al draait tot de eerste regel in je logboek waarin de naam van je agent staat in plaats van die van een collega.

Een agent identity is een apart soort service principal in Microsoft Entra ID: het account waaronder één AI-agent handelt. Hij heeft geen eigen wachtwoord, sleutel of secret. De inloggegevens zitten op een blueprint, de herbruikbare template waaruit de agent is gemaakt, en die blueprint vraagt de tokens namens de agent op. Elke agent identity heeft verplicht een sponsor: een mens of groep die verantwoordelijk is.

Dat ontwerp is het antwoord op één concreet probleem: een agent op geleende inloggegevens zet zijn acties in het logboek op naam van een medewerker en is niet te stoppen zonder die medewerker te raken. De vraag is niet meer of dat moet. De vraag is hoe je het doet voor de agents die je vandaag al draait.

Wat je nodig hebt

Twee dingen bepalen of dit een middag of een kwartaal wordt: welke rollen je mag activeren, en of je runtime in een container past. Regel dat vooraf, dan loop je niet halverwege vast.

Licenties. Entra Agent ID zelf, de identiteitslaag met blueprints en agent-identiteiten, is beschikbaar voor alle Entra-klanten. De beheerlaag erboven is dat niet: Microsoft Agent 365, met de agentregistratie in het Microsoft 365-beheercentrum, is sinds 1 mei 2026 algemeen beschikbaar en wordt per gebruiker gelicentieerd. Er moet minstens één gebruiker een kwalificerende licentie hebben voordat je Agent 365 kunt aanzetten, en Microsoft noemt E5 de voorkeursbasis. Agent 365 zit ook in het E7-pakket dat Copilot, E5, de Entra Suite en Agent 365 samenvoegt.

Rollen. Verdeel ze bewust, want ze zijn niet even zwaar. Agent ID Developer of Agent ID Administrator om blueprints en agent-identiteiten te maken. Privileged Role Administrator om Graph-applicatiepermissies toe te kennen. Cloud Application Administrator of Application Administrator voor delegated permissies. Voor de eerste opzet van een derde-partij-integratie vraagt de documentatie Global Administrator, met de nadrukkelijke aantekening dat je die rol just-in-time activeert via Privileged Identity Management in plaats van hem permanent uit te delen.

Zo breng je bestaande agents onder je eigen tenant

Je brengt agents die buiten Microsoft draaien onder je eigen tenant door eerst te inventariseren wat er loopt, dan per soort agent één blueprint te maken, de credential op die blueprint te zetten, per agent een identiteit met sponsor aan te maken, je runtime aan die identiteit te koppelen en tot slot te controleren wat er in je auditlog verschijnt. Zes stappen, in deze volgorde. Sla stap 1 over en je registreert keurig de agents die je toch al kende.

Drie onderdelen van dit pad bewegen nog, status augustus 2026: de wizard in het Entra-beheercentrum heet New agent blueprint (Preview), agent-identiteiten maak je in stap 4 nog via het /beta-endpoint van Graph, en synchroniseren op een schema kan nog niet. De rest, van het aanmaken van de blueprint tot de federated credential, loopt over v1.0 en is algemeen beschikbaar.

Stap 1: Inventariseer wat er nu al draait

Er lopen twee sporen naast elkaar, en je hebt ze allebei nodig.

Het eerste spoor zijn de platformen die je kent. In het Microsoft 365-beheercentrum ga je naar Agents > All Agents, en in het onderdeel Connected platforms kies je Manage > Connect a platform. Zes platformen worden ondersteund: Amazon Bedrock, Google Vertex AI, Salesforce Agentforce, Databricks Genie, Anthropic Claude Managed Agents (in preview, omdat Anthropics Managed Agents-API zelf nog beta is) en Oracle Generative AI Agents. Je levert per omgeving leesrechten aan. Voor Bedrock is dat een IAM-gebruiker met onder meer bedrock:ListAgents, bedrock:GetAgent en bedrock:ListAgentAliases; voor Vertex AI een serviceaccount met aiplatform.reasoningEngines.list en .get. Na het valideren van de gegevens druk je op Sync agents. Synchroniseren op een schema kan nog niet, dat staat volgens de documentatie voor een latere release gepland.

Het tweede spoor is lastiger: agents die als gewone app-registratie in je tenant leven, aangemaakt door een ontwikkelaar die deed wat hij altijd deed. Die staan in geen enkele agentlijst. Microsoft geeft een bruikbare heuristiek om ze te vinden: applicatiepermissies op Azure OpenAI, Azure AI Services of Bot Framework, redirect-URI's die naar token.botframework.com wijzen, niet-interactieve aanmeldingen met hoge frequentie zonder gebruikerscontext, en weergavenamen met agent, bot, copilot, assistant of orchestrator erin. Draai dat over GET /servicePrincipals en behandel de uitkomst als kandidaten, niet als bevindingen. Een backend-microservice die Azure OpenAI aanroept is geen agent.

De valkuil zit in je bewaartermijn. Aanmeldlogs blijven in Entra standaard 30 dagen staan. Een agent die maandelijks een rapportage draait, is in dat venster onzichtbaar. Heb je Sentinel of een andere SIEM met langere retentie, gebruik die dan als bron.

Stap 2: Maak één blueprint per soort agent

De blueprint is geen administratieve formaliteit maar je bedieningspaneel. Conditional Access-regels, API-permissies en governance-instellingen die je op de blueprint zet, erven alle agent-identiteiten eronder automatisch. En een blueprint uitzetten blokkeert in één klap elke agent die eruit is gemaakt. Dat is je noodrem.

De snelste route is de wizard: entra.microsoft.com > Entra ID > Agents > Agent blueprints > New agent blueprint (Preview). Die maakt de blueprint én het bijbehorende blueprint principal aan, en vraagt om owners en sponsors. Programmatisch gaat het zo:

Connect-MgGraph -Scopes "AgentIdentityBlueprint.Create","User.Read" -TenantId <tenant-id>

$body = @{
  "@odata.type"         = "Microsoft.Graph.AgentIdentityBlueprint"
  "displayName"         = "Agent-VerkoopOfferteFlow"
  "sponsors@odata.bind" = @("https://graph.microsoft.com/v1.0/users/<sponsor-id>")
  "owners@odata.bind"   = @("https://graph.microsoft.com/v1.0/users/<owner-id>")
} | ConvertTo-Json -Depth 5

Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/applications/microsoft.graph.agentIdentityBlueprint" `
  -Headers @{ "OData-Version" = "4.0" } `
  -Body $body -ContentType "application/json"

Noteer de appId uit het antwoord. Twee details kosten je hier stilletjes de kop: zonder -Depth 5 kapt PowerShell de geneste arrays af, en zonder de OData-Version-header weigert het endpoint. De Graph PowerShell SDK heeft er geen eigen cmdlet voor, dus je valt terug op ruwe REST-aanroepen met Invoke-MgGraphRequest, zoals ontwikkelaar Will Velida in februari 2026 uitschreef.

Maak je de blueprint via de API in plaats van via de wizard, dan moet je het principal er zelf achteraan aanmaken met een POST op /v1.0/serviceprincipals/microsoft.graph.agentIdentityBlueprintPrincipal. Sponsors mogen gebruikers zijn, groepen met dynamisch lidmaatschap (security of Microsoft 365) en Microsoft 365-groepen met toegewezen lidmaatschap; security-groepen met toegewezen lidmaatschap en roltoewijsbare groepen worden geweigerd.

Stap 3: Zet de credential op de blueprint, nooit op de agent

Dit is de omkering die het hele model draagt. De agent identity heeft geen eigen sleutel, dus valt er op de agent niets te stelen. De blueprint houdt de credential en wisselt die in voor tokens.

Voor productie is een federated identity credential met een user-assigned managed identity de aanbevolen vorm, omdat er dan helemaal geen secret bestaat om te lekken of te roteren:

Connect-MgGraph -Scopes "AgentIdentityBlueprint.AddRemoveCreds.All" -TenantId <tenant-id>

New-MgApplicationFederatedIdentityCredential -ApplicationId "<blueprint-app-id>" -BodyParameter @{
  Name      = "agent-offerteflow-mi"
  Issuer    = "https://login.microsoftonline.com/<tenant-id>/v2.0"
  Subject   = "<managed-identity-principal-id>"
  Audiences = @("api://AzureADTokenExchange")
}

Draait de agent buiten Azure, op AWS of GCP, dan configureer je workload identity federation met die provider. Draait hij on-premises, gebruik dan een certificaat. Een client secret is alleen voor lokaal testen; Microsoft raadt hem expliciet af voor productie en adviseert certificaten minstens jaarlijks te roteren, ook al staan blueprints langere looptijden toe.

Stap 4: Geef elke agent zijn eigen identiteit, met een naam erop

Eén identiteit per agent-instantie. Deel er nooit een tussen twee agents, want dan ben je precies het onderscheid kwijt waar je dit voor doet. Omdat de credential op de blueprint zit, kost een extra identiteit je niets aan sleutelbeheer.

Via de wizard: Entra ID > Agents > Agent identities > New agent identity (Preview), blueprint kiezen, naam invullen, owners en sponsors zetten. Via Graph:

POST https://graph.microsoft.com/beta/serviceprincipals/Microsoft.Graph.AgentIdentity
OData-Version: 4.0
Content-Type: application/json

{
  "displayName": "Agent-VerkoopOfferteFlow-Prod",
  "agentIdentityBlueprintId": "<blueprint-app-id>",
  "sponsors@odata.bind": ["https://graph.microsoft.com/v1.0/users/<sponsor-id>"]
}

Wacht 30 tot 60 seconden tussen het aanmaken van de blueprint en de eerste agent identity. Doe je dat niet, dan krijg je een 400 Bad Request: Object not found door read-after-write-vertraging, en dat leest als een fout in je script terwijl er niets mis is.

Het verschil tussen owner en sponsor is de moeite waard om te snappen, want het bepaalt wie er 's nachts iets kan repareren. De owner is de technische beheerder: die mag authenticatie-instellingen wijzigen, credentials beheren en, als enige, een uitgezette identiteit weer aanzetten of een soft-deleted identiteit terughalen. De sponsor is zakelijk verantwoordelijk en werkt bewust met minder rechten: uitzetten en soft-deleten mag, terugdraaien niet. Een agent identity mag maximaal 100 sponsors hebben, waarvan hooguit vijf groepen.

Stap 5: Koppel je runtime aan die identiteit

Nu pas raak je de agent zelf aan. Er zijn twee gedocumenteerde patronen, plus één route die specifiek voor n8n bestaat.

Sidecar. De Microsoft Entra ID Auth SDK draait als losse container náást je agent, uit het kant-en-klare image mcr.microsoft.com/entra-sdk/auth-sidecar. Je agent vraagt geen token maar een kant-en-klare header op: GET /AuthorizationHeader/{api}?AgentIdentity={agent-app-id} voor een aanroep namens een ingelogde gebruiker, en /AuthorizationHeaderUnauthenticated/{api}?AgentIdentity={agent-app-id} voor de autonome variant. De sidecar doet de OAuth-uitwisseling met Entra en cachet de tokens. Let op de poort: de integratiepagina van Microsoft noemt 7000 als standaard, terwijl de voorbeelden in microsoft/entra-agentid-samples de sidecar met ASPNETCORE_URLS=http://+:5000 vastzetten en hem bewust géén host-poort geven, zodat alleen containers in hetzelfde netwerk tokens kunnen opvragen. Dat Bedrock-voorbeeld draait drie containers op één Docker-bridge: de agent met een chat-UI op poort 3001, de sidecar zonder host-poort, en een downstream-API die het JWT bij elk verzoek valideert op handtekening, uitgever, de claim xms_par_app_azp en audience. Welk credentialtype de sidecar gebruikt, zet je met één omgevingsvariabele, AzureAd__ClientCredentials__0__SourceType: ClientSecret in de lokale docker-compose.yml, SignedAssertionFromManagedIdentity in de Azure Container Apps-uitrol. Je gaat dus van dev naar productie zonder een regel agentcode te wijzigen. Dit patroon werkt met elke gecontaineriseerde agent, van een Bedrock-agent met LangGraph tot een lokale Ollama met LangChain.

Federatie. Geen sidecar, geen tweede container. Je wisselt het token dat je agent toch al krijgt van AWS STS of Google Workload Identity direct om voor een Entra-token, via een vooraf geconfigureerde federated identity credential. Dit is de route als je agent geen container kan draaien, of als je federatie-infrastructuur er al staat.

n8n. Hier loopt het anders. De token-aanvraag gebeurt in de workflow zelf, met de community-node @astaykov/n8n-nodes-entraagentid, en de gedocumenteerde uitrol zet n8n met één azd up op Azure Container Apps neer, inclusief PostgreSQL, Azure OpenAI en drie voorbeeld-workflows. Handig om te zien hoe het werkt. Alleen zet Microsoft er zelf bij dat het voorbeeld geen richtlijn is voor het in productie draaien van n8n op Azure. Neem dat serieus, en tel er twee dingen bij op. De node staat op npm op versie 0.1.1, één enkele publicatie van 9 maart 2026, van één maker. En n8n waarschuwt dat een community-node volledige toegang heeft tot de machine waarop n8n draait en tot de data in je workflows. Voor een proof of concept is dat prima. Voor een agent die bij je HR-data mag, zou ik de sidecar nemen.

Draaide je agent al op een gewone app-registratie? Dan is er geen snelweg: een bestaande app-registratie of service principal is niet ter plekke om te zetten naar een agent identity. Je maakt de nieuwe identiteit ernaast, repliceert de permissies, draait beide een tot twee weken parallel met eerst 5 tot 10 procent van het verkeer op de nieuwe, en ruimt de oude pas daarna op.

Stap 6: Controleer wat er in je logboek verschijnt

Dit is de stap die bewijst dat het werkte, en de stap die het vaakst wordt overgeslagen.

In de aanmeldlogs (Entra ID > Monitoring & health > Sign-in logs) filter je op Agent type met de waarden Agent ID user, Agent Identity of Agent Identity Blueprint, of simpelweg op Is Agent. Omdat agents zowel met gebruikersgedelegeerde als met app-only-rechten inloggen, kunnen hun aanmeldingen in alle vier de logtypes opduiken.

In de auditlogs zie je geen aparte agent-categorie. Agent-activiteit valt onder de bestaande gebeurtenissen: een blueprint verschijnt als "Add application", een agent identity als "Add service principal", een agent-gebruikersaccount als "Add user". Het onderscheid zit in twee velden op initiatedBy, performedBy en targetResources.

Elke andere waarde dan notAgentic betekent dus dat er een agent in het spel was. Wil je dit uit Graph halen in plaats van uit de portal, dan werkt GET /beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and agent/agentType eq 'AgentIdentity'. Vraag de nieuwere enum-waarden op met de header Prefer: include-unknown-enum-members, anders krijg je ze niet terug.

Vanaf hier sluit het aan op de rest van je toezicht. Hoeveel tokens een agent verstookt en welke noodrem daarop staat, regel je niet in Entra maar in je eigen laag; dat werk ik uit in de gids over logging, budgetten en kill-switches voor AI-agents, die via een eigen proxy loopt.

Waar het in de praktijk misgaat

Vijf faalmodi die uit de documentatie zelf komen en die je niet ziet aankomen als je alleen de gelukkige route leest.

Eén medewerker die op akkoord klikt, zet een fabriek in je tenant. Meldt iemand zich voor het eerst aan bij een externe agent, dan toont Entra een toestemmingsscherm, en met die klik komt er een blueprint principal in je tenant. Dat principal krijgt automatisch de applicatiepermissie AgentIdentity.CreateAsManager en mag tot 250 agent-identiteiten aanmaken, waarbij die permissie niet in te trekken is. De enige manier om het te stoppen is het principal uitzetten of uit de tenant verwijderen. De mitigatie is dus preventief: stel je toestemmingsbeleid voor applicaties in vóórdat je dit aanzet, niet erna.

Je Conditional Access blokkeert je eigen agent. Een agent kan geen MFA-prompt beantwoorden en geen passkey registreren. Een breed beleid in de trant van "alle gebruikers moeten MFA doen" hakt er dus dwars doorheen. Sluit agent-identiteiten uit van je gebruikersbeleid en maak aparte agent-policies die sturen op identiteitsfilters, risicosignalen en benoemde locaties, en zet ze eerst in report-only. Dit is het spiegelbeeld van de beweging waarin je mensen juist naar phishing-bestendige inlog met passkeys in Entra ID duwt: dezelfde tenant, twee tegengestelde besturingsmodellen.

De opruiming die niets opruimt. azd down --purge haalt je Azure-resources weg en docker compose down je containers, maar de Entra-objecten blijven staan. Blueprints, agent-identiteiten en agent-gebruikersaccounts overleven elke infrastructuur-opruiming en moet je handmatig verwijderen in het beheercentrum. Doe je dat niet, dan bouw je in je testomgeving precies de wildgroei op die je in productie wilde voorkomen.

De sponsor die vertrekt. Sponsorschap is verplicht bij het aanmaken, maar daarna houdt niets het vanzelf actueel. Vertrekt de sponsor, dan draait de agent gewoon door zonder verantwoordelijke, en Microsoft schrijft zelf dat je sponsorschap moet onderhouden om opvolging te borgen. Het gereedschap daarvoor zit al in je tenant, dus bouw geen eigen spreadsheet. Een sponsor is namelijk geen naamplaatje: hij mag toegangsverzoeken indienen en goedkeuringen geven in lifecycle workflows, en hij kan namens zijn agent access packages aanvragen, zodat toegang tijdgebonden en met een goedkeuringsstap loopt in plaats van als een permanente permissietoekenning. Drie dingen regelen het samen. Zet een groep met dynamisch lidmaatschap als sponsor in plaats van een persoon, zodat opvolging automatisch meebeweegt met de rol. Neem agent-identiteiten mee in je toegangsbeoordelingen in identity governance: Microsoft adviseert sponsors elke 6 tot 12 maanden te laten bevestigen dat de agent nog nodig en juist geconfigureerd is, en het uitblijven van die bevestiging is je signaal om op te ruimen. En zet daarnaast één kwartaalcontrole op wezen: agents zonder sponsor, met verouderde metadata of zonder recente activiteit, die je herbelegt of opruimt.

De secret die blijft staan. Elk voorbeeld begint met een client secret, want dat werkt lokaal meteen. Precies daarom staat hij er drie maanden later nog. Zet in je definition of done dat de blueprint bij livegang op een managed identity of certificaat draait, en houd dev, test en productie op gescheiden blueprints met eigen credentials.

Welke route past bij jouw situatie

De eerlijke afweging gaat hier niet over kant-en-klaar versus maatwerk, want die twee bestaan naast elkaar. Ze gaat over hoe diep je gaat: alleen zien wat er draait, of je agents echt onder een eigen identiteit laten handelen.

De vuistregel die ik zelf aanhoud: draaien er minder dan vijf agents die alleen lezen, begin dan met registry-sync en één blueprint, en je bent in een dag klaar. Schrijven er agents in je systemen, dan is de sidecar het werk waard, ook al kost hij je een tweede container per agent. En begin je vandaag aan iets nieuws, pak dan meteen de Agents SDK, want alles wat je nu handmatig knoopt mag je later opnieuw doen.

Uitgewerkt: drie agents bij een technische groothandel

Stel je een groothandel voor met 120 medewerkers op Microsoft 365 E5, en drie agents die in de loop van een jaar zijn ontstaan. Een n8n-flow die binnenkomende offerteaanvragen classificeert en in het CRM zet. Een Python-agent in een container die op Bedrock draait en productdocumentatie doorzoekt. En een rapportagebot die een ontwikkelaar ooit als gewone app-registratie in Entra zette. Zo ziet de klus er dan uit.

Dag 1, inventarisatie. De Bedrock-agent komt via Connected platforms binnen: IAM-gebruiker met leesrechten, koppeling valideren, Sync agents. De rapportagebot komt boven water via de heuristiek: geen interactieve aanmeldingen, applicatiepermissies op Azure OpenAI, "bot" in de naam. De n8n-flow staat nergens, want die logt in met het account van de commercieel manager. Dat is het echte gat.

Dag 1, blueprints. Drie blueprints, geen twee: Agent-VerkoopOfferteFlow voor de n8n-agent, Agent-Productdocumentatie voor de Bedrock-agent, en een derde voor de rapportagebot, omdat die bij een ander team en een andere sponsor hoort. Sponsor van de eerste wordt de Microsoft 365-groep van het salesmanagement, niet de commercieel manager persoonlijk. Owner is de ontwikkelaar.

Dag 2, credentials en identiteiten. Op elke blueprint een federated identity credential met een user-assigned managed identity uit de Container Apps-omgeving. Daaronder per agent één identity: Agent-VerkoopOfferteFlow-Prod, Agent-Productdocumentatie-Prod, plus test-varianten op een aparte testblueprint. De permissies worden gerepliceerd van de oude registratie, waarbij twee van de vijf Graph-permissies sneuvelen omdat niemand kan uitleggen waar ze voor waren. Dat is winst, geen bijvangst.

Dag 3 tot 5, runtime. De Bedrock-agent krijgt de sidecar ernaast in dezelfde Docker Compose: agent, sidecar zonder host-poort, downstream-API die het token valideert. De n8n-flow gaat voorlopig niet naar de community-node, maar krijgt zijn Graph-aanroepen via een klein eigen endpoint dat wél naast een sidecar draait. De rapportagebot loopt twee weken parallel op oud en nieuw, met het verkeer dat stapsgewijs verschuift.

Week 3, controle. In de aanmeldlogs levert het filter Is Agent = Yes een lijst met drie namen op. In de auditlogs staat bij het aanmaken agentType: agenticAppInstance met de blueprintId erbij. De oude app-registratie gaat naar soft-delete, waar hij dertig dagen blijft staan voor het geval er iets vergeten is. En de commercieel manager komt niet langer voor in het logboek van een proces dat hij niet uitvoerde.

De kosten van zo'n week zitten niet in licenties. Ze zitten in de discipline om de rechten van de oude registratie niet klakkeloos over te nemen, en in het geduld om parallel te draaien in plaats van om te knallen.

Wat je hiermee echt koopt

Registratie klinkt als administratie, en dat is precies waarom het blijft liggen. Maar wat je hier inricht is geen lijst. Het is het verschil tussen een agent die je kunt uitzetten en een agent die je alleen kunt uitzetten door een collega buiten te sluiten.

De timing helpt. De handeling is inmiddels gedocumenteerd tot op het niveau van poortnummers en headers, terwijl het aantal agents in de meeste organisaties nog te overzien is. Over een jaar staat die volgorde om: dan draai je de inventarisatie op een tenant waarin niemand meer weet wie wat heeft aangezet. Elke agent die je nu een naam geeft, is er één die je later niet hoeft te zoeken.