Hvem bygde disse agentene?

I en kundetenant med 3 000 brukere fant vi 280 agenter i det første inventaret. 170 av dem hadde ingen ansvarlig igjen som fortsatt var i selskapet. Det var ikke noen med onde hensikter som bygde dem, men fagavdelinger som raskt ville løse et problem. Nøyaktig slik oppstod Service Principals for ti år siden, de som ingen har ryddet opp i den dag i dag. Agenter gjentar dette mønsteret, bare raskere og i større antall.

Hva en lisens ikke kan

E7 samler E5, Copilot, Entra Suite og Agent 365 i én pakke. Hva som ligger i pakken er godt beskrevet. En lisens rydder likevel ikke opp i tenanten. Den gir oss verktøyene til å se, identifisere og kontrollere agenter. Hva en agent har noe å gjøre der, hvem som er ansvarlig for den og hva den har tilgang til, avgjør den ikke.

I tillegg kommer tempoet. Agenter oppstår i dag der Excel-makroer oppstod tidligere: i fagavdelingene, raskt og uten ticket. Det er tilsiktet, og vi synes det er bra. Men det betyr at antallet ikke-menneskelige kontoer i katalogen vokser raskere enn noen annen gruppe.

Hva registeret viser og hva det ikke viser

Agent 365 samler agenter fra Microsoft 365, Copilot Studio, Power Platform og Foundry på ett sted. Defender for Endpoint finner i tillegg lokalt installerte KI-agenter på klientene, inkludert konfigurerte MCP-servere. Begge deler havner i Advanced Hunting og kan evalueres samlet via KQL. Shadow AI i ordets bokstavelige forstand.

Med denne spørringen ser vi hvilke agenter som faktisk kalles og hvilke verktøy de bruker:

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

Her er det viktig å ta med en begrensning: spørringen viser bare en del av bildet, primært Microsofts egne agenter og de som er bygget på Microsoft-plattformer. Det som kjører ved siden av, er ikke synlig her.

For lokale agenter på klientene er Defender for Endpoint Plan 2 tilstrekkelig:

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

En agent som handler på vegne av en bruker, arver brukerens rettigheter. Har den brukeren tilgang til et SharePoint-bibliotek som er delt altfor bredt, har agenten det også. Og agenten er bare raskere og grundigere enn noe menneske.

En autonom agent med egen identitet opererer med egne tillatelser. Den trenger en ansvarlig, et gjennomarbeidet rettighetsprofil og en utløpsdato, akkurat som alle andre kontoer som kommer i kontakt med virksomhetens data.

Registeret viser hva som finnes. Om det skal være der, må noen vurdere, og den vurderingen blir aldri ferdig.

Agenter trenger identiteter, ingen unntak

Agenter som bygges med Entra Agent ID, får en egen, administrert identitet. Med Agent Blueprints kan man fastsette hvordan en agent er bygget og hvilke rettigheter den får, før den i det hele tatt eksisterer. Og med Entra ID Governance kjører tilgangsprøvinger og livssyklushåndtering også for agenter: opprette, godkjenne, tildele ansvarlige, jevnlig gjennomgå og la dem utløpe.

Conditional Access kan anvendes på agentidentiteter og Blueprints, men ikke på nøyaktig samme måte som for mennesker. Policies for «alle brukere» fanger ikke opp agentkontoer, og den som bruker API-nøkkel for tilgang, går helt utenom Entra. Disse hullene må man kjenne til før man stoler på policyen.

Dette høres selvfølgelig ut. I praksis er det dessverre sjelden det. Vi ser allerede i dag i mange tenanter hvor krevende dette er med klassiske app-registreringer og Service Principals: foreldreløse secrets, rettigheter fra en eller annen testfase, ansvarlige som for lengst jobber et annet sted. Agenter gjør ikke dette bedre, fordi de bygges i langt større antall og av langt flere mennesker.

Den som ikke har kontroll på Service Principals i dag, vil heller ikke ha kontroll på agentene sine i morgen.

Governance er en løpende oppgave

Hver uke kommer det nye agenter til. Ansvarlige skifter rolle eller selskap. Rettigheter vokser, Conditional Access-regler får unntak, og Sensitivity Labels er det ingen som vedlikeholder. Ingenting av dette er et prosjekt med en go-live-dato, det er drift.

Og nettopp slik angriper vi det. Med Managed Entra drifter vi Entra ID for kundene våre fullstendig som code. Det høres ut som et teknisk detalj, men er den egentlige grunnen til at driften fungerer pålitelig.

Mange virksomheter har en ryddig change-prosess etter ITIL. I ticketen står det hva som skal endres, så klikkes det i portalen. Men hvem kontrollerer at nøyaktig det ble justert og ingenting annet?

Hos oss kontrolleres ikke beskrivelsen, men selve endringen. Reglene ligger som code. Svart på hvitt er det klart på forhånd hva som endres. En annen person godkjenner nøyaktig det, og bare det rulles ut, med navn og dato. Skulle noe likevel gå galt, er den siste fungerende tilstanden gjenopprettet på minutter, ikke i løpet av en nattevakt.

Unntak følger også denne veien. Trenger en kunde et avvik fra standarden, ligger det i repositoriet og ikke i en Excel-liste eller i hodet på en admin. Det er synlig, versjonert og gjennomgås som alle andre endringer. Dermed uthules ikke baseline gradvis over månedene, og ved neste revisjon er dokumentasjonen for hvordan tenanten er konfigurert, og hvem som endret hva og når, allerede klar.

Vi holder oss selv til det vi krever av agenter. Vår egen automatisering er jo også en ikke-menneskelig identitet. Den logger seg på kundetenanten via federerte identiteter, helt uten lagret secret. Rettighetene er separert: én identitet kan bare lese og planlegge, en annen kan skrive. Ingen passord som kan lekke, intet sertifikat som stille utløper en dag.

Med agentene selv er vi midt i prosessen. Conditional Access, Access Reviews og Entitlement Management kjører allerede som code hos oss. Det vi bygger nå, er agent-maler i repositoriet, med identitet, rettigheter, Conditional Access, ansvarlige og utløpsdato, samt automatiske kontroller på foreldreløse agentidentiteter, for eksempel med Maester-sjekker fra community-en. Med hundrevis av agenter er det forskjellen mellom oversikt og håp.

Hvordan Purview beskytter dataene som agenter leser og videresender, og hvordan CSOC overvåker aktiviteten deres, beskriver vi i en egen artikkel om KI-governance.

Og agentene i Azure?

Agent 365 ser også agenter som kjører i Microsoft Foundry. Men noen må bygge og drifte plattformen under: modeller, nettverk, datatilkobling, evaluering. For det har vi bygget AI Foundation, fullstendig som code, slik at hvert nytt KI-prosjekt starter med de samme rammeverkene som det forrige. Mer om dette finner du i artikkelen vår om de tre foundations: The Holy Trinity.

Det viktigste punktet er koblingen nedover. Hver agent fra AI Foundation får en egen identitet i samme Entra som resten av landskapet, med nøyaktig de rettighetene den trenger. Handler den på vegne av en bruker, ser den bare det brukeren har tilgang til. Og den etterlater et spor som kan revideres. Ingen særvei med egne kontoer og egne unntak bare fordi agenten kjører i Azure i stedet for i Microsoft 365.

Tre spørsmål til i morgen tidlig

Den som vil vite hvor de står, kan begynne med tre spørsmål:

1. Hvilke agenter har ingen aktiv owner eller sponsor lenger?
2. Hvilke Service Principals har secrets som er eldre enn tolv måneder?
3. Hvilke agenter bruker API-nøkkel i stedet for Entra for tilgang?

Den som raskt kan svare på alle tre, er kommet lenger enn de fleste.

Hvor vi begynner

Med nåsituasjonen, for agentene er der uansett. I vår todagers Agent 365 Workshop gjør vi synlig hvilke agenter som kjører i tenanten din og hvor de kommer fra. Etterpå sitter dere igjen med et inventar, et risikobilde og en governance-plan med klare ansvarsforhold.

Konklusjon

E7 tar tak i et reelt problem. Å se hva som kjører betyr likevel ikke at man har kontroll på det. For det må noen se på det hver dag, vedlikeholde identiteter, beskjære rettigheter og legge merke til når en agent plutselig oppfører seg annerledes enn i går.

Lisensen er begynnelsen. Driften avgjør.

Har dere E7 allerede i bruk, eller merker dere at agentene formerer seg hos dere, og lurer på hvem som egentlig har oversikten? Ta kontakt. Vi ser sammen på hva som kjører hos dere og hva som bør få bli. Microsoft støtter oppstarten gjennom støtteprogrammer. Om det passer for dere, avklarer vi sammen.