Hverjir smíðuðu þessa agents?

Í tenant hjá einum viðskiptavini með 3.000 notendur fundum við 280 agents í fyrsta birgðaskránni. 170 þeirra áttu sér engan ábyrgðaraðila sem var enn starfsmaður í fyrirtækinu. Enginn illgjarn aðili smíðaði þá, heldur sérfræðideildir sem vildu fljótt leysa eitthvað. Nákvæmlega svona urðu til Service Principals fyrir tíu árum sem enn hefur enginn hreinsa upp. Agents eru að endurtaka þetta mynstur, bara hraðar og í mun stærri stærðargráðu.

Hvað leysingur getur ekki gert

E7 sameinar E5, Copilot, Entra Suite og Agent 365. Það sem felst í pakkanum hefur verið lýst nægilega vel. En ein leysingur hreinsar ekki upp tenant. Hann gefur okkur verkfæri til að sjá, auðkenna og stjórna agents. Hvort agent ætti að vera til, hverjir bera ábyrgð á honum og hvað hann má nálgast, það ræðst ekki af leysinum.

Að auki kemur hraðinn. Agents verða til þar sem Excel-fjölvi voru áður: í sérfræðideildunum, fljótt og án þjónustubeiðni. Þetta er meðvituð stefna, og við finnum hana rétta. En það þýðir að fjöldi ómannlegra reikninga í skránni vex hraðar en nokkur önnur hópur.

Hvað skráin sýnir og hvað ekki

Agent 365 safnar saman agents úr Microsoft 365, Copilot Studio, Power Platform og Foundry á einn stað. Defender for Endpoint finnur auk þess staðbundið uppsettar AI-agents á clients, þar á meðal skilgreindar MCP-þjónar. Báðar heimildir lenda í Advanced Hunting og er hægt að meta saman með KQL. Shadow AI í bókstaflegum skilningi.

Með þessari fyrirspurn skoðum við hvaða agents eru í raun kallaðir og hvaða verkfæri þeir nota:

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

Hér á við ein fyrirvari: fyrirspurnin sýnir aðeins hluta af myndinni, einkum agents frá Microsoft sjálfu og þá sem voru smíðaðir á Microsoft-kerfum. Það sem keyrir við hliðina á þessu sést ekki hér.

Fyrir staðbundna agents á clients nægir 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

Agent sem virkar fyrir hönd notanda erfir réttindi hans. Ef sá notandi hefur aðgang að SharePoint-safni sem er allt of opið, á agent það sama við. Hann er bara hraðari og þorpulegri en nokkur manneskja.

Sjálfstæður agent með eigið auðkenni vinnur með eigin heimildir. Hann þarf einhvern sem ber ábyrgð, skýrt heimildarmynstur og gildistíma, eins og hver annar reikningur sem kemst að gögnum fyrirtækisins.

Skráin sýnir hvað er til staðar. Hvort það ætti að vera þar þarf einhver að meta, og sú mat lýkur aldrei.

Agents þurfa auðkenni, engar undantekningar

Agents sem eru smíðaðir með Entra Agent ID fá sitt eigið, stýrða auðkenni. Með Agent Blueprints er hægt að skilgreina hvernig agent er smíðaður og hvaða réttindi hann fær, áður en hann er til yfirleitt. Og með Entra ID Governance keyra aðgangsskoðanir og líftímastjórnun einnig fyrir agents: stofna, samþykkja, úthluta ábyrgðaraðilum, skoða reglulega, láta renna út.

Conditional Access er hægt að beita á agent-auðkenni og Blueprints, en ekki beinlínis eins og á fólk. Reglur fyrir „alla notendur" ná ekki til agent-reikninga, og þeir sem fara inn með API-lykli komast alveg framhjá Entra. Þessar eyður þarf að þekkja áður en maður treystir á regluna.

Þetta hljómar sjálfsagt. Í framkvæmd er það því miður oft ekki svo. Við sjáum í mörgum tenants þegar í dag hversu erfitt þetta gengur með hefðbundnar app-skráningar og Service Principals. Yfirgefin leyndarmál, heimildir úr einhverri prófunarfasa, ábyrgðaraðilar sem eru lengi farnir í annað starf. Agents gera þetta ekki betra, þar sem þeir eru smíðaðir í mun stærra magni og af mun fleiri aðilum.

Þeir sem hafa ekki Service Principals á hreinu í dag munu ekki hafa agents á hreinu á morgun heldur.

Governance er stöðugt verkefni

Í hverri viku bætast við nýir agents. Ábyrgðaraðilar skipta um hlutverk eða fyrirtæki. Heimildir stækka, Conditional Access-reglur fá undantekningar, Sensitivity Labels sér enginn um. Ekkert af þessu er verkefni með ákveðinn opnunardag, þetta er rekstur.

Og nákvæmlega þannig nálgumst við það. Með Managed Entra rekum við Entra ID fyrir viðskiptavini okkar að fullu sem kóða. Þetta hljómar sem tæknilegt smáatriði, en það er í raun ástæðan fyrir því að reksturinn er áreiðanlegur.

Mörg fyrirtæki hafa skýrt breytingaferli samkvæmt ITIL. Í þjónustubeiðninni stendur hvað á að breyta, svo er smellt í gáttina. En hverjir skoða hvort nákvæmlega það var gert og ekki eitthvað annað?

Hjá okkur er ekki lýsingin skoðuð heldur breytingin sjálf. Reglurnar liggja fyrir sem kóði. Áður en eitthvað er gert stendur svart á hvítu hvað breytist. Önnur manneskja samþykkir nákvæmlega það, og aðeins það er sett í gildið, með nafni og dagsetningu. Ef eitthvað fer þrátt fyrir það úrskeiðis er síðasta virka ástand endurheimt á nokkrum mínútum, ekki í næturvinnu.

Jafnvel undantekningar fara þessa leið. Þarfnast viðskiptavinur frávik frá staðlinum, er það í geymslusafninu en ekki í Excel-lista eða í huga einhvers stjórnanda. Þetta er sýnilegt, útgáfustillt og farið yfir eins og allar aðrar breytingar. Þannig þynna grunnlínurnar sig ekki hægt og rólega yfir mánuðina, og þegar næsta úttekt kemur liggur sönnunargögn um hvernig tenant er stillt og hverjir breyttu hvað og hvenær, þegar tilbúin.

Við höldum okkur sjálf að því sem við krefjumst af agents. Eigin sjálfvirkni okkar er líka ómannlegt auðkenni. Hún skráir sig inn á tenant viðskiptavinar með federated identity, alveg án geymds leyndarmáls. Réttindin eru aðskilin: eitt auðkenni má aðeins lesa og skipuleggja, annað má skrifa. Ekkert lykilorð sem getur lekið, ekkert skírteini sem rennur hljóðlægt út á einhverjum tímapunkti.

Varðandi agents sjálfa erum við midt í þessu. Conditional Access, Access Reviews og Entitlement Management keyra hjá okkur þegar í dag sem kóði. Það sem við erum að byggja núna eru agent-sniðmát í geymslusafninu, með auðkenni, heimildum, Conditional Access, ábyrgðaraðilum og gildistíma, auk sjálfvirkra athuganir á yfirgefnum agent-auðkennum, til dæmis með Maester-athugunum úr samfélaginu. Við hundruð agents er þetta munurinn á yfirsýn og von.

Hvernig Purview verndar gögnin sem agents lesa og deila, og hvernig CSOC okkar fylgist með virkni þeirra, lýsum við í sérstakri grein um AI governance.

Og agents í Azure?

Agent 365 sér líka agents sem keyra í Microsoft Foundry. En einhver þarf að byggja og reka kerfið undir þeim: líkön, net, gagnatenging, mat. Fyrir það höfum við smíðað AI Foundation, að fullu sem kóða, þannig að sérhvert nýtt AI-verkefni byrjar með sömu leiðarljósum og það síðasta. Meira um þetta er í greininni okkar um þrjár foundations: The Holy Trinity.

Mikilvægasta atriðið er tengingin niður á við. Sérhver agent úr AI Foundation fær sitt eigið auðkenni í sama Entra og restinn af umhverfinu, með nákvæmlega þær heimildir sem hann þarf. Virkar hann fyrir hönd notanda sér hann aðeins það sem sá notandi má sjá. Og hann lætur eftir sig slóð sem hægt er að skoða. Engin sérlausn með eigin reikninga og eigin undantekningar, bara vegna þess að agent keyrir í Azure í stað Microsoft 365.

Þrjár spurningar fyrir morgundaginn

Þeir sem vilja vita hvar þeir standa geta byrjað á þremur spurningum:

1. Hvaða agents eiga sér engan virkan eiganda eða styrktaraðila lengur?
2. Hvaða Service Principals hafa leyndarmál sem eru eldri en tólf mánuðir?
3. Hvaða agents fara inn með API-lykli í stað Entra?

Þeir sem geta svarað öllum þremur fljótt eru lengra komnir en flestir.

Hvar við byrjum

Við núverandi stöðu, því agents eru þegar til staðar. Í tveggja daga Agent 365 Workshop gerum við sýnilegt hvaða agents keyra í tenantinum þínum og hvaðan þeir koma. Að því loknu hefurðu birgðaskrá, áhættumynd og governance-áætlun með skýrum ábyrgðum.

Conclusion

E7 tekst á við raunverulegt vandamál. Að sjá hvað er í gangi þýðir þó ekki að hafa það á hreinu. Til þess þarf einhver að skoða hlutina á hverjum degi, viðhalda auðkennum, klippa niður heimildir og taka eftir þegar agent hegðar sér skyndilega öðruvísi en í gær.

Leysingurinn er upphafið. Reksturinn ræður úrslitum.

Ert þú þegar með E7 í gangi eða tekur eftir því að agents eru að fjölga sér hjá þér, og veltir fyrir þér hverjir hafa í raun yfirsýn? Hafðu samband við okkur. Við skoðum saman hvað er í gangi hjá þér og hvað má vera þar. Microsoft styður byrjunina með styrktarforriti. Hvort það hentar þér, leysum við úr saman.