Wie heeft deze agents gebouwd?

In een klanttenant met 3.000 gebruikers hebben we bij het eerste inventaris 280 agents aangetroffen. 170 daarvan hadden geen verantwoordelijke meer die nog bij het bedrijf werkte. Ze zijn niet gebouwd door kwaadwillenden, maar door afdelingen die snel een probleem wilden oplossen. Precies zo zijn tien jaar geleden de Service Principals ontstaan die tot op de dag van vandaag niemand heeft opgeruimd. Agents herhalen dat patroon, alleen sneller en op grotere schaal.

Wat een licentie niet kan

E7 bundelt E5, Copilot, de Entra Suite en Agent 365. Wat het pakket inhoudt, is inmiddels voldoende beschreven. Maar een licentie ruimt geen tenant op. Ze geeft ons de middelen om agents te zien, te identificeren en te beheersen. Of een agent er mag zijn, wie er verantwoordelijk voor is en wat die mag benaderen, bepaalt ze niet.

Daar komt het tempo bij. Agents ontstaan tegenwoordig daar waar vroeger Excel-macro's werden gebouwd: in de business, snel en zonder ticket. Dat is de bedoeling, en wij vinden dat ook prima. Het betekent echter dat het aantal niet-menselijke accounts in de directory sneller groeit dan welke andere groep ook.

Wat de registry laat zien en wat niet

Agent 365 verzamelt agents uit Microsoft 365, Copilot Studio, Power Platform en Foundry op één plek. Defender for Endpoint vindt bovendien lokaal geïnstalleerde AI-agents op de clients, inclusief de geconfigureerde MCP-servers. Beide komen terecht in Advanced Hunting en zijn via KQL samen te analyseren. Shadow AI in de letterlijke zin.

Met de volgende query bekijken we welke agents daadwerkelijk worden aangeroepen en welke tools ze daarbij gebruiken:

CloudAppEvents
| where ActionType in ("InvokeAgent", "InferenceCall", "ExecuteToolBySDK", "ExecuteToolByGateway")
| extend RawEventData_parsed = parse_json(RawEventData)
| extend
    Workload          = coalesce(tostring(RawEventData_parsed["Workload"]), "Unknown"),
    TargetAgentName   = coalesce(tostring(RawEventData_parsed["TargetAgentName"]), "Unknown"),
    AgentName         = coalesce(tostring(RawEventData_parsed["AgentName"]), "Unknown"),
    AgentBlueprintId  = coalesce(tostring(RawEventData_parsed["AgentBlueprintId"]), "Unknown"),
    PlatformAgentType = coalesce(
        tostring(RawEventData_parsed["PlatformAgentType"]),
        tostring(RawEventData_parsed["CopilotEventData"]["PlatformAgentType"]),
        "Unknown"
    )
| project-away RawEventData_parsed
| summarize count() by ActionType, Workload, TargetAgentName, PlatformAgentType, AgentName, AgentBlueprintId

Daarbij hoort een kanttekening: de query laat slechts een deel van het beeld zien, voornamelijk Microsoft-eigen agents en agents die op Microsoft-platforms zijn gebouwd. Wat er daarnaast actief is, verschijnt hier niet.

Voor de lokale agents op de clients volstaat Defender for Endpoint Plan 2:

AgentsInfo
| where Platform == "LocalAgents"
| summarize arg_max(Timestamp, Name, Version, LifecycleStatus, RawAgentInfo) by AgentId
| where LifecycleStatus !in~ ("Deleted", "Uninstalled")
| extend AgentMetadata = RawAgentInfo.localAgentMetadata
| extend Vendor = tostring(AgentMetadata.vendor),
         Device = tostring(AgentMetadata.deviceName)
| summarize DeviceCount = dcount(Device) by Agent = Name, Vendor
| sort by DeviceCount desc

Een agent die namens een gebruiker handelt, erft diens rechten. Als die gebruiker toegang heeft tot een veel te ruim vrijgegeven SharePoint-bibliotheek, heeft de agent dat ook. Het verschil is dat de agent sneller en grondiger te werk gaat dan welk mens ook.

Een autonome agent met een eigen identiteit werkt met eigen rechten. Die heeft iemand nodig die verantwoordelijk is, een helder rechtenprofiel en een vervaldatum, net als elk ander account dat toegang heeft tot bedrijfsgegevens.

De registry laat zien wat er is. Of het er mag zijn, moet iemand beoordelen, en die beoordeling is nooit klaar.

Agents hebben identiteiten nodig, geen uitzonderingen

Agents die met Entra Agent ID worden gebouwd, krijgen een eigen, beheerde identiteit. Via Agent Blueprints leg je vast hoe een agent is ingericht en welke rechten hij krijgt, nog voordat hij überhaupt bestaat. En met Entra ID Governance lopen toegangsreviews en levenscyclusbeheer ook voor agents: aanmaken, vrijgeven, eigenaren toewijzen, periodiek toetsen en laten verlopen.

Conditional Access is toe te passen op agent-identiteiten en Blueprints, maar niet één op één zoals bij mensen. Policies voor "alle gebruikers" vangen agent-accounts niet af, en wie via een API-key verbinding maakt, loopt volledig buiten Entra om. Die lacunes moet je kennen voordat je op de policy vertrouwt.

Klinkt vanzelfsprekend. In de praktijk is het dat helaas niet. We zien in veel tenants al hoe moeizaam dat gaat bij klassieke app-registraties en Service Principals: verlaten secrets, rechten uit een of andere testfase, eigenaren die allang elders werken. Agents maken dat niet beter, omdat ze in grotere aantallen en door veel meer mensen worden gebouwd.

Wie zijn Service Principals vandaag niet onder controle heeft, heeft zijn agents morgen ook niet onder controle.

Governance is een doorlopende taak

Elke week komen er nieuwe agents bij. Eigenaren wisselen van rol of van werkgever. Rechten groeien mee, Conditional Access-regels krijgen uitzonderingen, Sensitivity Labels worden niet bijgehouden. Niets hiervan is een project met een go-live-datum, het is gewoon beheer.

En precies zo pakken we het aan. Met Managed Entra beheren we Entra ID voor onze klanten volledig als code. Dat klinkt als een technisch detail, maar het is de eigenlijke reden dat het beheer betrouwbaar verloopt.

Veel organisaties hebben een nette change-procedure volgens ITIL. In het ticket staat wat er gewijzigd moet worden, waarna iemand in de portal klikt. Maar wie controleert of precies dát is aangepast en niets anders?

Wij toetsen niet de beschrijving, maar de wijziging zelf. De regels liggen als code vast. Vooraf staat zwart op wit wat er verandert. Een tweede persoon keurt precies dat goed, en alleen dat wordt uitgerold, met naam en datum. Gaat er toch iets mis, dan is de laatste werkende staat in minuten hersteld, niet na een nachtdienst.

Ook uitzonderingen lopen via dit pad. Heeft een klant een afwijking van de standaard nodig, dan staat die in het repository en niet in een Excel-bestand of in het hoofd van een beheerder. Ze is zichtbaar, versioned en wordt getoetst als elke andere wijziging. Zo verwatert de baseline niet geleidelijk over de maanden, en bij de volgende audit ligt het bewijs van hoe de tenant is geconfigureerd en wie wanneer wat heeft gewijzigd, al klaar.

En we houden onszelf aan wat we voor agents eisen. Onze eigen automatisering is immers ook een niet-menselijke identiteit. Die meldt zich via gefedereerde identiteiten aan op de klanttenant, volledig zonder opgeslagen secret. De rechten zijn gesplitst: één identiteit mag alleen lezen en plannen, een andere mag schrijven. Geen wachtwoord dat kan weglekken, geen certificaat dat op een dag stilletjes verloopt.

Bij de agents zelf zijn we volop bezig. Conditional Access, Access Reviews en Entitlement Management draaien bij ons al als code. Waar we nu aan bouwen, zijn agent-templates in het repository, met identiteit, rechten, Conditional Access, eigenaren en een vervaldatum, en geautomatiseerde controles op verlaten agent-identiteiten, bijvoorbeeld met Maester-checks uit de community. Bij honderden agents is dat het verschil tussen overzicht en hopen.

Hoe Purview de gegevens beschermt die agents lezen en doorgeven, en hoe ons CSOC hun activiteit bewaakt, beschrijven we in een apart artikel over AI-governance.

En de agents in Azure?

Agent 365 ziet ook agents die in Microsoft Foundry draaien. Maar iemand moet het platform daaronder bouwen en beheren: modellen, netwerk, datakoppelingen, evaluatie. Daarvoor hebben we de AI Foundation gebouwd, volledig als code, zodat elk nieuw AI-project met dezelfde vangrails start als het vorige. Meer daarover staat in ons artikel over de drie foundations: The Holy Trinity.

Het belangrijkste punt is de verbinding naar beneden. Elke agent uit de AI Foundation krijgt een eigen identiteit in hetzelfde Entra als de rest van de omgeving, met precies de rechten die hij nodig heeft. Handelt hij namens een gebruiker, dan ziet hij alleen wat die gebruiker mag zien. En hij laat een spoor achter dat te controleren is. Geen aparte route met eigen accounts en eigen uitzonderingen, alleen maar omdat de agent in Azure draait in plaats van in Microsoft 365.

Drie vragen voor morgenochtend

Wie wil weten waar hij staat, kan beginnen met drie vragen:

1. Welke agents hebben geen actieve eigenaar of sponsor meer?
2. Welke Service Principals hebben secrets die ouder zijn dan twaalf maanden?
3. Welke agents verbinden via een API-key in plaats van via Entra?

Wie op alle drie snel een antwoord heeft, is verder dan de meesten.

Waar we beginnen

Bij de huidige situatie, want de agents zijn er toch al. In onze tweedaagse Agent 365 Workshop maken we zichtbaar welke agents er in jullie tenant actief zijn en waar ze vandaan komen. Daarna hebben jullie een inventaris, een risicobeeld en een governance-plan met duidelijke verantwoordelijkheden.

Conclusie

E7 pakt een reëel probleem aan. Maar zien wat er draait, betekent nog niet dat je het onder controle hebt. Daarvoor moet iemand elke dag kijken, identiteiten bijhouden, rechten terugsnoeien en opmerken wanneer een agent zich ineens anders gedraagt dan gisteren.

De licentie is het begin. Het beheer bepaalt de uitkomst.

Hebben jullie E7 al in gebruik of merken jullie dat agents zich bij jullie vermenigvuldigen? En vragen jullie je af wie dat eigenlijk in de gaten houdt? Neem contact met ons op. We kijken samen wat er bij jullie speelt en wat er mag blijven. De eerste stap wordt door Microsoft ondersteund via subsidieprogramma's. Of dat voor jullie van toepassing is, klaren we samen uit.