Mikä on muuttunut ja mikä ei agenttisovellusten todennuksessa ja identiteetissä

Äskettäin tutustuin tähän artikkeliin, ja agenttitodennus mainittiin:

Näemme vihjeitä siitä, miltä tämä voisi näyttää. Uusin MCP-määrittely sisältää valtuutusviitekehyksen perustuen OAuth 2.1:een, mikä viittaa mahdollisuuteen siirtyä kohti AI-agenttien kohdennettujen, peruttavien merkkien antamista raakojen salaisuuksien sijasta. Voimme kuvitella skenaarion, jossa AI-agentti ei saa AWS-avaimiasi, vaan saa sen sijaan lyhytaikaisen tunnuksen tai kykytunnuksen, joka sallii sen suorittaa rajatusti määritellyn toiminnon.

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

Monet ystävät ja turvallisuus- tai CIAM-aloilla toimimattomat ihmiset saavat vaikutelman, että tämä on jotain uutta, mutta se ei todellakaan ole. OAuth on standardoitu, merkkipohjainen valtuutusprotokolla, joka sisältää merkit, joilla on rajatut oikeudet (pääsyoikeusmerkit). Ne ovat aikaherkkäisiä ja rajoitettuja, mikä varmistaa turvallisuuden ja asianmukaisen resurssien ja palveluiden käytön hallinnan. Globaaleilla SaaS-markkinoilla (ennen AI:ta) suurin osa ammattiidentiteettiratkaisuista on jo rakennettu tämän perustalle.

Kun yhdistät Google-tilisi kolmannen osapuolen sovellukseen, kuten Notioniin tai Zoomiin, se käyttää OAuthia pyytämään vain tarvittavat oikeudet, kuten pääsyn kalenteriisi tai yhteystietoihisi, paljastamatta koskaan Google-salasanaasi. Voit peruuttaa pääsyn milloin tahansa Google-tilisi asetuksista. Tämä valtuutettu pääsymalli on juuri sitä, mitä varten OAuth on suunniteltu, ja se on sama perusta, jota laajennetaan agenttisovelluksiin tänään.

Mikä ei muutu agenttimaailmassa#

Todennus ei ole uusi, edelleen perustuu OAuth 2.1:een#

Kaksi suurta protokollaa on nousemassa esiin: MCP ja A2A.

• MCP keskittyy LLM:ien ja sovelluksesi työkalujen ja kontekstin väliseen vuorovaikutukseen.
• A2A keskittyy mahdollistamaan agenttien välisen tehtävien vaihdon.

Mutta kun kyse on todennuksesta ja valtuutuksesta, molemmat luottavat yhä vakiintuneisiin teollisuuden standardeihin, kuten OAuthiin.

MCP-valtuutuspalvelimet TÄYTYY toteuttaa OAuth 2.1, ja niissä on oltava asianmukaiset turvatoimenpiteet sekä luottamuksellisille että julkisille asiakkaille.

A2A-asiakas vastaa tarvittavien tunnistemateriaalien (esim. OAuth 2.0 -merkkien, API-avaimien, JWT:iden) hankkimisesta A2A-protokollan ulkopuolisilla prosesseilla. Tämä voisi sisältää OAuth-virtaukset (valtuutuskoodi, asiakastunnukset), turvallisen avainten jakelun jne.

Kuten Google asian ilmaisee:

Sen sijaan, että keksittäisiin uusia patentoituja standardeja turvallisuudelle ja operaatioille, A2A pyrkii yhdistymään saumattomasti olemassa olevaan yritysinfrastruktuuriin ja laajasti omaksuttuihin parhaisiin käytäntöihin.

Tarvitseeko agentti ainutlaatuisen identiteetin?#

Paljon hypeä ja FOMO-sisältö työntää ajatusta, että kun agentit yleistyvät, meidän on luotava järjestelmä agenttien identiteettien hallintaan.

Vastaus on: kyllä ja ei.

Kyllä, koska olemme esittelemässä uutta kerrosta ihmisten ja koneiden välillä. On todellisia tarpeita:

• Hallita ja tunnistaa agentteja
• Määrittää yksilölliset tunnukset
• Seurata lokeja
• Tarkastaa toimintoja (tietää, suorittiko tehtävän ihminen vai agentti)

Kuitenkin useimmissa teknisissä tapauksissa ei ole tarpeen luoda muodollista käsitettä "Agentti-identiteettiä".

Agentti ≠ Käyttäjä, ≠ Palvelutili.

Jokaisen agentin takana on edelleen käyttäjä, ja käyttäjäidentiteetti on yleensä riittävä.

Tänään useimmat agentit:

• Toimivat käyttäjän valtuutuksen perusteella (esim. OAuth-merkit)
• Suorittavat logiikkaa tai tekevät API-kutsuja
• Suorittavat lyhytaikaisia, kertaluonteisia tehtäviä (ilman seurantatarvetta)

Tässä mielessä agentti on vain toimintona työkaluna eikä tarvitse maailmanlaajuisesti yksilöivää tunnusta.

Esimerkiksi:

• GPT-agentti, joka kutsuu kalenteri-API:ta, tarvitsee vain antamasi käyttöoikeuden.
• LangChain-agentti ei tarvitse identiteettiä, kunhan se voi kutsua oikeita työkaluja, se toimii.

Jo ennen tekoälyä meillä oli käsite koneiden välinen (M2M) todennus.

M2M tarkoittaa automatisoitua tiedonvaihtoa palveluiden välillä ilman ihmistä silmukassa.

Tässä kontekstissa todennus käyttää usein asiakasohjelmaa tai palvelutiliä.

Jos todella haluat agentillesi identiteetin (tarkastuksia varten jne.), voit käyttää sovelluksen tunnusta ja se riittää.

Sinun on vielä määritettävä tuotteesi arkkitehtuuri#

Tämä ei ole muuttunut. Riippumatta siitä, sisältääkö tuotteesi agentteja, identiteettijärjestelmän arkkitehtuuri riippuu siitä, keitä käyttäjäsi ovat ja miten järjestelmäsi on vuorovaikutuksessa heidän kanssaan.

Jos rakennat kuluttajille suunnattua agenttituotetta: Sinun tarvitsee kevyet sisäänkirjautumismetodit (sähköposti, puhelin, sosiaalinen kirjautuminen) ja yhtenäinen käyttäjäryhmä hallitsemaan henkilöitä, jotka ovat vuorovaikutuksessa sovelluksen ja sen agenttien kanssa. Agentit toimivat näiden käyttäjien puolesta käyttämällä valtuutettuja merkkejä (esim. OAuthin kautta).

Esimerkki:

Kuvittele, että rakennat tekoälypohjaista ajanvaraajan avustajaa tai tekoälyohjattua kalenteribottia.

Jokainen käyttäjä kirjautuu sisään henkilökohtaisella Google-tilillään. Järjestelmäsi käyttää OAuthia saadakseen luvan käyttää heidän kalenteriinsa. Agentilla ei ole omaa identiteettiä, se käyttää käyttäjän merkkiä ajoittaakseen kokoukset, tarkistaakseen käytettävyyden tai lähettääkseen muistutuksia. Identiteettiarkkitehtuuri on yksinkertainen: yksi maailmanlaajuinen käyttäjäryhmä, merkkien tallennus ja suostumuksen seuranta per käyttäjä.

Jos rakennat B2B agenttialustaa:

Sinun on tuettava identiteettiä organisaatiotasolla, ei pelkästään yksilöiden. Tämä sisältää:

1. SSO yritysasiakkaille
2. Työtilan tai vuokralaisen tasoinen erottelu
3. Agentin delegointipolitiikat organisaatiotasolla (esim. mitä agentit voivat tehdä tiimien välillä)
4. Admin-tason näkyvyys ja lokit kaikista agenttien toimista työntekijöiden puolesta

Esimerkki:

Kuvittele, että rakennat alustaa, joka tarjoaa AI-agentteja sisäisten työnkulkujen automatisointiin — kuten tietoturvaanalyytikko, joka monitoroi lokeja ja lähettää hälytyksiä, tai myyntiavustaja, joka luo sähköposteja CRM-datasta.

Jokainen yritys, joka käyttää alustaasi, haluaa:

1. Kirjautua olemassa olevan SSO:n kanssa
2. Hallita, mitä agentit voivat käyttää (esim. sisäiset työkalut, dokumenttijärjestelmät)
3. Nähdä, mikä agentti suoritti minkäkin tehtävän, kenellä työntekijän valtuutuksella

Tässä tapauksessa identiteettiarkkitehtuurisi on tuettava monivuokralaisuutta, agentin rajattuja valtuuksia ja organisaatiokohtaisia käytäntöjä. Agentit toimivat käyttäjien puolesta, mutta käyttöoikeudet ja identiteettirajat määritellään yrityskohtaisesti.

Kummassakin tapauksessa identiteettimalli määrittää, kuinka agentit toimivat, mihin niillä on pääsy ja miten järjestelmäsi varmistaa vastuullisuuden.

Käytä tätä opasta auttamaan sinua suunnittelemaan identiteetti- ja tuotearkkitehtuurisi.

https://docs.logto.io/introduction/plan-your-architecture/b2c

https://docs.logto.io/introduction/plan-your-architecture/b2b

Itse tarvitset edelleen suojauskerroksia pitämään agenttivetoiset sovelluksesi turvassa#

Riippumatta siitä, onko kyseessä agenttisovellus vai ei, nämä perustavanlaatuiset suojauskerrokset ovat välttämättömiä käyttäjiesi ja järjestelmiesi suojelemiseksi:

• Monivaiheinen todennus (MFA)

  Estää luvattoman pääsyn, vaikka tunnukset olisivat vaarantuneet.

  Esimerkki: Jos agentti auttaa sinua suorittamaan korkean riskin toimenpiteen, kuten tekemään tapahtuman tai muuttamaan identiteettiasetuksia, sen tulisi pitää ihminen silmukassa ja käyttää MFA:ta toiminnon vahvistamiseksi ennen etenemistä.

• CAPTCHA

  Estää automatisoidun väärinkäytön kuten tunnusten täyttö- tai bottipohjaiset rekisteröinnit.

  Esimerkki: Näytä CAPTCHA kolmen epäonnistuneen kirjautumisyrityksen jälkeen estääksesi bruteforce-hyökkäykset.

• Roolipohjainen pääsynvalvonta (RBAC)

  Varmistaa, että käyttäjät ja agentit pääsevät vain siihen, mihin heillä on lupa.

  Esimerkki: AI-avustaja yrityksen työtilassa voi lukea kalenteritapahtumia, mutta ei voi käyttää laskutustietoja, ellei sille ole nimenomaan myönnetty korkeampaa roolia.

• Salasanaluton kirjautuminen

  Parantaa käyttökokemusta ja vähentää heikkojen salasanojen riskiä.

  Esimerkki: Anna käyttäjien kirjautua sisään käyttämällä linkkiä, joka lähetetään sähköpostitse, tai biometrisyysaloitusta, kuten Face ID.

Nämä ominaisuudet koskevat sekä perinteisiä että agenttipohjaisia sovelluksia, varsinkin kun agentit alkavat toimia kytkettyjen tietojen ja järjestelmien välillä.

Mikä on muuttunut agenttimaailmassa#

Todennus on tärkeämpää kuin koskaan#

Kun agentit ja monien agenttien työnkulut nousevat esiin, näemme uusia käyttötapauksia, joissa käyttäjät, agentit, API:t ja MCP-palvelimet kaikki ovat vuorovaikutuksessa. Näiden skenaarioiden määrä ja kirjo kasvaa nopeasti, huomattavasti enemmän kuin ennen.

Aina kun nämä yhteydet tapahtuvat, valtuutus tulee näkyvämmäksi kuin koskaan. Käyttäjien on annettava selkeä suostumus, ja oikeuksia on hallittava huolellisesti yli järjestelmien. Siksi kaikki puhuvat nyt siitä, että pidetään "ihminen mukana silmukassa" varmistamassa, että käyttäjillä on riittävästi hallintaa ja näkyvyyttä siihen, mitä agentit voivat tehdä ja mitä oikeuksia heille on myönnetty.

Tekoälysovelluksesi saattaa tarvita integraation moniin ulkoisiin palveluihin#

MCP-ekosysteemi laajenee, ja tämä tarkoittaa, että sovelluksesi ei ole enää standalone-palvelu, vaan osa suurempaa, kytkettyä verkostoa.

Tarjotakseen rikkaita, hyödyllisiä konteksteja LLM:ille agenttiesi on ehkä:

• Päästävä useisiin MCP-palvelimiin

  Esimerkki: Kuvittele tekoälyprojektijohtaja, joka saa tehtävien päivitykset Jirasta, tiimin saatavuuden Google-kalenterista ja myyntitiedot Salesforce, ja kukin näistä voi olla eri MCP-palvelimen ohjaama. Laatiakseen viikkoyhteenvedon agentin on oltava turvallisesti vuorovaikutuksessa lukuisten tietolähteiden kanssa. Tässä todennus ja valtuutus astuvat kuvaan suojelemaan jokaista yhteyttä ja hallitsemaan, miten tietoja jaetaan.

• Yhdistettävä ulkoisiin API:ihin ja työkaluihin

  Esimerkki: Asiakaspalveluagentti saattaa joutua hakemaan tilaushistorian Shopifysta, päivittämään tikettejä Zendeskiin ja käynnistämään työnkulkuja Slackissa. Ilman integraatioita agentti eristäytyy ja tehoton.

Kun agentit ottavat lisää vastuuta, integraatioista tulee avain hyödyllisyyteen. Tekoälytuotteesi ei ole vain siitä, mitä se voi tehdä yksinään, vaan mitä se voi käyttää, orkestroida ja pohtia kytketyssä ekosysteemissä. Siksi integroinnin rakentaminen yhteentoimivuuden kannalta, turvallisesti ja joustavasti, on tärkeämpää kuin koskaan.

Sinun on omaksuttava avoimet standardit: OAuth/OIDC ovat tärkeämpiä kuin koskaan#

Tekoälyajalla turvallisten, joustavien integraatioiden tarve kasvaa. Se tekee OAuth 2.0:sta ja OIDC:stä tärkeämpiä kuin koskaan.

Keskeisiä käyttötapauksia ovat:

• Kaukosijaiset MCP-palvelimet: Anna kolmannen osapuolen agenttien päästä tuotteeseesi turvallisesti käyttämällä valtuutettuja merkkejä.
• Kolmannen osapuolen integraatiot: Salli muiden työkalujen tai agenttien yhdistäminen sovellukseesi (esim. projektinhallinta-alusta) ilman raaka-tunnuksia.
• Agentin kehitys: Rakenna tekoälyagentteja, jotka toimivat turvallisesti käyttäjien puolesta palveluissa.
• Älylaitteet: Käytä OAuth/OIDC:tä esimerkiksi tekoälypohjaisten muistiinpanokoneiden käyttäjien tunnistamiseen ja yhteyden muodostamiseen pilveen — erityisesti vähäisellä käyttöliittymällä.

Nämä protokollat tarjoavat turvallisen, merkkipohjaisen, käyttäjän harkinnanvaraisen pääsyn.

Tämä on ratkaisevan tärkeää agenttien täyttämässä, kytketyssä järjestelmässä. Tutustu tähän artikkeliin nähdäksesi miksi OAuth ja OIDC ovat tärkeitä

Suunnitteleminen luottamukselle ja skaalautuvuudelle agenttiohjatun ohjelmiston aikakaudella#

Kun agenttituotteet kehittyvät, identiteetin ja valtuutuksen perusperiaatteet pysyvät samoina, mutta konteksti muuttuu. Agentit lisäävät uusia pintoja delegoinnille, suostumukselle ja pääsylle. Siksi avoimien standardien, kuten OAuthin, noudattaminen, selkeän arkkitehtuurin luominen ja vankkojen tietoturvakäytäntöjen käyttöönotto eivät ole vain parhaita käytäntöjä, vaan ne ovat perustavanlaatuisia. Huolellisesti suunnitteleminen nyt tarkoittaa, että järjestelmäsi skaalautuu luottamuksella, joustavuudella ja luotettavuudella tekoälyohjatussa tulevaisuudessa.