Kuka rakensi nämä agentit?

Eräästä 3.000 käyttäjän asiakastenantista löysimme ensimmäisessä inventaariossa 280 agenttia. 170 niistä oli vailla vastuuhenkilöä, joka olisi vielä ollut yrityksen palveluksessa. Kukaan ei rakentanut niitä pahassa tarkoituksessa, vaan ne olivat liiketoimintayksiköiden tekemiä, kun jokin asia piti ratkaista nopeasti. Täsmälleen samalla tavalla syntyivät kymmenen vuotta sitten ne Service Principalit, joita kukaan ei ole siivonnut vielä tänäkään päivänä. Agentit toistavat tätä kaavaa, vain nopeammin ja suurempina määrinä.

Mitä lisenssi ei pysty tekemään

E7 niputtaa yhteen E5:n, Copilotin, Entra Suiten ja Agent 365:n. Paketin sisältö on tähän mennessä kuvattu riittävän tarkasti. Lisenssi ei kuitenkaan siivoa tenanttia. Se antaa meille työkalut agenttien havaitsemiseen, tunnistamiseen ja hallintaan. Sitä, pitäisikö agentin ylipäätään olla olemassa, kuka siitä vastaa ja mihin se saa päästä käsiksi, se ei ratkaise.

Tähän tulee lisäksi tahti. Agentteja syntyy nykyään siellä, missä ennen syntyi Excel-makroja: liiketoimintayksiköissä, nopeasti ja ilman tikettiä. Se on tarkoituksellista, ja pidämme sitä myös hyvänä asiana. Se tarkoittaa kuitenkin, että hakemiston ei-inhimillisten tilien määrä kasvaa nopeammin kuin mikään muu ryhmä.

Mitä rekisteri näyttää ja mitä ei

Agent 365 kokoaa agentit Microsoft 365:stä, Copilot Studiosta, Power Platformista ja Foundrysta yhteen paikkaan. Defender for Endpoint löytää lisäksi päätelaitteille paikallisesti asennetut AI-agentit konfiguroituine MCP-palvelimineen. Molemmat päätyvät Advanced Huntingiin, ja niitä voi analysoida yhdessä KQL:llä. Shadow AI sanan varsinaisessa merkityksessä.

Tällä kyselyllä tarkastelemme, mitä agentteja todella kutsutaan ja mitä työkaluja ne silloin käyttävät:

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

Tähän liittyy yksi rajoitus: kysely näyttää vain osan kuvasta, lähinnä Microsoftin omat agentit sekä Microsoftin alustoilla rakennetut agentit. Sitä, mitä niiden rinnalla on käynnissä, tässä ei näe.

Päätelaitteiden paikallisiin agentteihin riittää 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

Käyttäjän puolesta toimiva agentti perii tämän oikeudet. Jos käyttäjällä on pääsy aivan liian laajasti jaettuun SharePoint-kirjastoon, on agentillakin. Se vain toimii nopeammin ja perusteellisemmin kuin yksikään ihminen.

Autonominen agentti, jolla on oma identiteetti, toimii omilla käyttöoikeuksillaan. Se tarvitsee vastuuhenkilön, siistin käyttöoikeusprofiilin ja päättymispäivän, kuten mikä tahansa muu tili, jolla on pääsy yrityksen tietoihin.

Rekisteri näyttää, mitä on olemassa. Sen, pitäisikö sen olla olemassa, joku joutuu arvioimaan, eikä tämä arviointi tule koskaan valmiiksi.

Agentit tarvitsevat identiteettejä, eivät poikkeuksia

Entra Agent ID:llä rakennetut agentit saavat oman, hallitun identiteetin. Agent Blueprintien avulla voi määrittää, miten agentti on rakennettu ja mitkä oikeudet se saa, jo ennen kuin sitä on edes olemassa. Ja Entra ID Governancen avulla käyttöoikeuksien tarkistukset ja elinkaari toimivat myös agenteille: luonti, hyväksyntä, vastuuhenkilöiden nimeäminen, säännöllinen tarkistus, vanhentaminen.

Conditional Accessia voi soveltaa agentti-identiteetteihin ja Blueprinteihin, mutta ei yksi yhteen samalla tavalla kuin ihmisiin. ”Kaikki käyttäjät” -policyt eivät kata agenttitilejä, ja API-avaimella käyttävä ohittaa Entran kokonaan. Nämä aukot on tunnettava, ennen kuin policyyn voi luottaa.

Kuulostaa itsestään selvältä. Käytännössä se ei valitettavasti ole. Näemme jo nyt monissa tenanteissa, kuinka vaikeaa tämä on perinteisten sovellusrekisteröintien ja Service Principalien kohdalla. Orvoiksi jääneitä secretejä, käyttöoikeuksia jostain testivaiheesta, vastuuhenkilöitä, jotka ovat jo kauan työskennelleet muualla. Agentit eivät tee tilannetta paremmaksi, koska niitä rakennetaan suurempina määrinä ja paljon useampien ihmisten toimesta.

Joka ei hallitse Service Principalejaan tänään, ei hallitse agenttejaankaan huomenna.

Governance on jatkuva tehtävä

Joka viikko tulee uusia agentteja. Vastuuhenkilöt vaihtavat roolia tai työnantajaa. Käyttöoikeudet kasvavat, Conditional Access -sääntöihin tulee poikkeuksia, Sensitivity Labeleita ei ylläpidä kukaan. Mikään tästä ei ole projekti, jolla on go-live, vaan kyse on ylläpidosta.

Ja juuri niin me siihen tartumme. Managed Entralla ylläpidämme Entra ID:tä asiakkaillemme kokonaan koodina. Se kuulostaa tekniseltä yksityiskohdalta, mutta se on varsinainen syy siihen, että ylläpito toimii luotettavasti.

Monilla yrityksillä on siisti ITIL:n mukainen muutosprosessi. Tikettiin kirjataan, mitä pitää muuttaa, ja sitten portaalissa klikataan. Mutta kuka tarkistaa, että muutettiin juuri sitä eikä mitään muuta?

Meillä ei tarkisteta kuvausta vaan itse muutos. Säännöt ovat koodina. Etukäteen on mustaa valkoisella, mikä muuttuu. Toinen henkilö hyväksyy juuri sen, ja vain se viedään tuotantoon, nimen ja päivämäärän kanssa. Jos jokin silti menee pieleen, viimeisin toimiva tila on palautettu minuuteissa eikä yövuorossa.

Myös poikkeukset kulkevat tätä reittiä. Jos asiakas tarvitsee poikkeaman standardista, se on repositoriossa eikä Excel-listassa tai jonkun adminin päässä. Se on näkyvissä, versioitu ja tarkistetaan kuten mikä tahansa muu muutos. Näin baseline ei vesity vähitellen kuukausien mittaan, ja seuraavassa auditoinnissa näyttö siitä, miten tenantti on konfiguroitu ja kuka muutti mitä ja milloin, on jo valmiina.

Ja noudatamme itse sitä, mitä vaadimme agenteilta. Oma automaatiommekin on ei-inhimillinen identiteetti. Se kirjautuu asiakkaan tenanttiin federoitujen identiteettien kautta, täysin ilman tallennettua secretiä. Oikeudet on eriytetty: yksi identiteetti saa vain lukea ja suunnitella, toinen saa kirjoittaa. Ei salasanaa, joka voisi vuotaa, eikä varmennetta, joka jonain päivänä vanhenee hiljaa.

Itse agenttien kanssa olemme keskellä työtä. Conditional Access, Access Reviews ja Entitlement Management toimivat meillä jo nyt koodina. Parhaillaan rakennamme repositorioon agenttipohjia, joissa on identiteetti, käyttöoikeudet, Conditional Access, vastuuhenkilöt ja päättymispäivä, sekä automaattisia tarkistuksia orvoiksi jääneille agentti-identiteeteille, esimerkiksi yhteisön Maester-tarkistuksilla. Satojen agenttien kohdalla tämä on ero kokonaiskuvan ja toiveikkuuden välillä.

Sitä, miten Purview suojaa tietoja, joita agentit lukevat ja välittävät eteenpäin, ja miten CSOC-palvelumme valvoo niiden toimintaa, käsittelemme erillisessä artikkelissa AI-governancesta.

Entä agentit Azuressa?

Agent 365 näkee myös Microsoft Foundryssa toimivat agentit. Mutta jonkun on rakennettava ja ylläpidettävä niiden alla oleva alusta: mallit, verkko, datayhteydet, arviointi. Sitä varten olemme rakentaneet AI Foundationin, kokonaan koodina, niin että jokainen uusi AI-projekti alkaa samoilla suojakaiteilla kuin edellinen. Lisää aiheesta kerromme artikkelissamme kolmesta foundationista: The Holy Trinity.

Tärkein asia on yhteys alaspäin. Jokainen AI Foundationin agentti saa oman identiteetin samaan Entraan kuin muu ympäristö, juuri niillä oikeuksilla, joita se tarvitsee. Jos se toimii käyttäjän puolesta, se näkee vain sen, mitä kyseinen käyttäjä saa nähdä. Ja se jättää jäljen, jonka voi tarkistaa. Ei erillistä reittiä omine tileineen ja omine poikkeuksineen vain siksi, että agentti toimii Azuressa eikä Microsoft 365:ssä.

Kolme kysymystä huomisaamuksi

Joka haluaa tietää, missä mennään, voi aloittaa kolmella kysymyksellä:

1. Millä agenteilla ei ole enää aktiivista omistajaa tai sponsoria?
2. Millä Service Principaleilla on secretejä, jotka ovat yli kaksitoista kuukautta vanhoja?
3. Mitkä agentit käyttävät API-avainta Entran sijaan?

Joka pystyy vastaamaan kaikkiin kolmeen nopeasti, on pidemmällä kuin useimmat.

Mistä me aloitamme

Nykytilasta, sillä agentit ovat joka tapauksessa jo olemassa. Kaksipäiväisessä Agent 365 -työpajassamme teemme näkyväksi, mitkä agentit tenantissanne ovat käynnissä ja mistä ne ovat peräisin. Sen jälkeen teillä on inventaario, riskikuva ja governance-suunnitelma selkeine vastuineen.

Yhteenveto

E7 tarttuu todelliseen ongelmaan. Se, että näkee, mitä on käynnissä, ei kuitenkaan vielä tarkoita, että tilanne olisi hallinnassa. Sitä varten jonkun on katsottava joka päivä, ylläpidettävä identiteettejä, karsittava käyttöoikeuksia ja huomattava, kun agentti yhtäkkiä käyttäytyy eri tavalla kuin eilen.

Lisenssi on alku. Ylläpito ratkaisee.

Onko teillä E7 jo käytössä, tai huomaatteko, että agentit lisääntyvät teillä? Ja mietittekö, kuka niitä oikeastaan seuraa? Ottakaa meihin yhteyttä. Katsomme yhdessä, mitä teillä on käynnissä ja mikä siitä saa jäädä. Microsoft tukee alkuvaihetta tukiohjelmien kautta. Sen, sopiiko se teille, selvitämme yhdessä.