AI-agentin todennus: käyttötapaukset ja henkilöllisyystarpeet
Vuosi 2025 on AI:n vuosi. Kun LLM:t ja agenttikokemukset kehittyvät, uudet haasteet tunnistautumisessa ja valtuutuksessa nousevat esiin. Tässä artikkelissa tarkastellaan AI-agenttien vuorovaikutusta ja korostetaan keskeisiä tietoturva- ja tunnistautumisskenaarioita.
Vuosi 2025 on muotoutumassa AI:n vuodeksi. LLM:ien ja agenttikokemusten nopean kasvun myötä meiltä kysytään usein: Miten voimme omaksua tämän uuden aikakauden? Ja mitkä ovat AI-agenttien todennuksen ja valtuutuksen uudet käyttötapaukset? Tässä artikkelissa tutkimme tyypillistä agenttikokemusta ja tuomme esiin tietoturva- ja todennusskenaarioita matkan varrella.
ChatGPT-operaattorin agentin todennuskokemus
Ostin äskettäin ChatGPT-operaattorin ja tutkin muutamia tavallisia työnkulkuja. Yksi esimerkki oli majoituksen varaaminen Tokiossa, Japanissa. Operaattori teki sopivan huoneen löytämisestä uskomattoman helppoa perustuen minulle antamaani ehdotukseen.
Maksun yhteydessä se pyysi minua kirjautumaan sisään ja antoi sitten hallinnan takaisin minulle.
Tämä kokemus teki minut levottomaksi. Vaikka minulla oli hallinta, enkä agentti voinut kirjautua sisään puolestani, minun oli silti syötettävä sähköpostiosoitteeni ja salasanani operaattorin selaimeen. Tämä tarkoittaa, että jos kirjaudut sähköpostiisi (tai mihinkään palveluun) operaattorin kautta, käyttötunnuksesi tallennetaan evästeisiin.
OpenAI:n operaattori ilmoittaa, ettei se koskaan tallenna käyttäjän tunnistetietoja ja noudattaa SOC II:n kaltaisia vaatimustenmukaisuusstandardeja. Kuitenkin kolmannen osapuolen agenttien vuorovaikutuksessa ulkoisten palveluiden kanssa puolestasi tietoturvariskit kasvavat merkittävästi.
Yleisesti ottaen suoraan agentillesi tilin käyttöoikeuden ja tunnistetietojen antaminen on huono idea.
Parannettavaa on vielä paljon. Seuraavassa osiossa syvennyn erilaisiin todennus- ja tunnistetietojen hallintatapoihin, punniten niiden etuja ja haittoja.
Kuten tämä X Threads keskusteli.
Kuinka tunnistetietoja käsitellään ja mitkä ovat tietoturvariskit?
Anna AI-agentille tunnistetietosi suoraan
Tässä lähestymistavassa AI syöttää selväkielisiä tunnistetietoja (kuten sähköpostin ja salasanan) puolestasi. Esimerkiksi AI-agentti saattaa pyytää kirjautumistietojasi ja syöttää ne puolestasi.
Tämä menetelmä sisältää kuitenkin tietoturvariskejä, koska se voi paljastaa arkaluonteisia tietoja. Jos toteuttaminen on tarpeen, turvallisempaa on integroida salasanojen hallintaohjelma tai salaisuudenhallintajärjestelmä. Lisäksi rajoittamalla, kuinka kauan tunnistetiedot tallennetaan, voidaan pienentää vuotoriskiä.
Sen sijaan, että käyttäisit selväkielisiä tunnistetietoja, henkilökohtaiset pääsytunnukset (PAT) tarjoavat turvallisemman tavan myöntää pääsyä ilman salasanan tai interaktiivisen kirjautumisen vaatimista. PAT:t ovat hyödyllisiä CI/CD-työkaluille, skripteille ja automatisoiduille sovelluksille, jotka tarvitsevat ohjelmallisen pääsyn resursseihin. Turvallisuuden parantamiseksi on parasta rajoittaa PAT-alueet, asettaa vanhenemisajat ja sallia peruutus vuotojen ja tilin kaappaamisen estämiseksi.
Käyttäjän delegointi OAuth:n kautta
OAuth (Open Authorization) on laajalti käytetty standardi hajautetulle valtuutukselle verkossa. Se mahdollistaa käyttäjien antaa kolmannen osapuolen sovellukselle rajallisen pääsyn heidän tietoihinsa toisessa palvelussa jakamatta kirjautumistunnuksiaan.
Pohjimmiltaan OAuth ratkaisee turvallisen pääsyn delegoinnin ongelman: esimerkiksi voit valtuuttaa matkustussovelluksen lukemaan Google-kalenteriasi antamatta sovellukselle Google-salasanaasi. Tämä saavutetaan käyttäjän todentaessa tiedontarjoajan kanssa (esim. Google) ja sen jälkeen myöntämällä tokeneita kolmannen osapuolen sovellukselle käyttäjän tunnusten paljastamisen sijaan.
Parempi tapa käsitellä tätä skenaariota on valtuuttaa ChatGPT-operaattori (tai mikä tahansa muu agentti) lukemaan ja kirjoittamaan Airbnb:ssä jakamatta salasanaasi tai tunnistetietojasi. Sen sijaan, että antaisit operaattorin kirjautua suoraan, voit myöntää pääsyn turvallisen valtuutusprosessin kautta.
Mielestäni, jos OpenAI-operaattori haluaa lisätä luottamusta ja identiteettiturvaa, on olemassa useita tapoja saavuttaa tämä.
-
Siirrä kirjautumisprosessi operaattorin ulkopuolelle: Käyttäjän kirjautumisen käsittely ChatGPT-operaattorin ulkopuolella. Tämä tarkoittaa, että voit napsauttaa “Kirjaudu sisään [palvelu]-painikkeella” ja sinut ohjataan palvelun turvalliselle kirjautumissivulle todentamaan itsesi, täysin chatin tai ChatGPT-operaattorin ulkopuolella. Esimerkiksi, jos olisi Airbnb-laajennus, sinut lähetettäisiin Airbnb:n verkkosivustolle syöttämään tunnistetietosi ja valtuuttamaan ChatGPT, ja sitten laajennus saisi tokenin. ChatGPT vastaanottaa vain väliaikaisen pääsytokenin tai avaimen, joka myöntää rajoitetun pääsyn (esim. “lue matkasuunnitelmani”), sen sijaan, että koskaan näkisi todellista salasanaasi.
-
Anna käyttäjän suorittaa suostumusvirta ennen kuin AI-agentti suorittaa mitään tehtäviä. Tämä lähestymistapa on samanlainen kuin miten monet tuotteet käsittelevät integraatioita, markkinapaikkoja ja liitettyjä palveluita.
Notion-yhdistämissivut
Tässä on toinen esimerkki, aivan kuten Slackin markkinapaikan integrointi Notionin kanssa. Slack pyytää pääsyä Notionin tiettyyn työtilaan, se voi lukea artikkelit ja esittää ne Slack-kanavissasi.
Samaan aikaan Slack tarjoaa myös suostumussivun valtuuttaakseen Notionin pääsyn työtilaan tämän prosessin aikana.
ChatGPT-operaattorin tulisi omaksua samanlainen lähestymistapa integroimalla OAuth, jolloin agentti voi turvallisesti käyttää useita kolmansien osapuolten palveluita. Tällä tavalla se voi hankkia pääsytokeneita tarvittavilla oikeuksilla suorittaa tehtäviä turvallisesti.
Vahvistettu todennus herkille toimenpiteille
AI-agentti voi käsitellä rutiinitehtäviä itsenäisesti ja autonomisesti, mutta korkean riskin toimia varten tarvitaan lisävahvistus turvallisuuden varmistamiseksi, esimerkiksi joidenkin rahamääräisten siirtojen tai tietoturva-asetusten muokkaamisen yhteydessä. Käyttäjän on varmennettava identiteettinsä monivaiheisella todennuksella (MFA). Tämä voidaan tehdä push-ilmoituksilla, kertakäyttöisillä salasanoilla (OTP) tai biometrisellä varmistuksella.
Kuitenkin tiuha monivaiheinen todennus voi aiheuttaa käyttäjien turhautumista, erityisesti jos se laukaistaan liian usein. Agenttikokemuksen on harkittava käyttäjäkokemusta tämän uuden paradigman myötä.
Turvallisuuden parantamiseksi heikentämättä käyttäjäkokemusta tulisi käyttää sopeutuvaa todennusta ja MFA:ta määritelmänään, milloin lisävahvistus on tarpeen. Riskiperusteiset laukaisimet, kuten IP-muutokset tai epätavallinen käyttäytyminen, auttavat minimoimaan tarpeettomia todennuspyyntöjä.
Liittoutunut identiteetti ja kertakirjautuminen (SSO) monen agentin ekosysteemeille
Monen agentin yritysekosysteemissä AI-agenttien on usein toimittava eri alustoilla. Tunnistautumisen helpottamiseksi käyttäjät todennetaan kerran id-providerin (IdP) kuten Okta, Azure AD tai Google Workspace kautta. Agenssit todennetaan sitten SAML, OpenID Connect (OIDC) kautta, joissa pääsyä hallinnoidaan roolipohjaisen (RBAC) tai attribuuttipohjaisen (ABAC) pääsynhallinnan avulla.
Tämä lähestymistapa eliminoi käyttäjien tarpeen kirjautua useita kertoja samalla kun parantaa tietoturvaa ja vaatimustenmukaisuutta keskitetyn identiteetinhallinnan avulla. Se mahdollistaa myös dynaamiset pääsypolitiikat varmistaen, että agentit toimivat määriteltyjen oikeuksien puitteissa.
Laajuuden ja luvan hallinta
Koska operaattorit ja agentit voivat toimia käyttäjien puolesta, on tärkeää antaa ihmisille tarpeeksi hallintaa ja määritellä huolellisesti AI-agenttien oikeudet. Kaksi keskeistä periaatetta, joita tulisi noudattaa, ovat:
- Vähimmäisoikeudet – Myönnä vain tehtävään tarvittavat oikeudet.
- Aikaherkä pääsy – Rajoita pääsyoikeuden kestoa tietoturvariskien vähentämiseksi.
Roolipohjainen pääsynhallinta (RBAC) auttaa hallitsemaan agentin laajuutta määrittämällä tiettyjä rooleja tietyille tehtäville. Tarkempaan hallintaan attribuuttipohjainen pääsynhallinta (ABAC) mahdollistaa dynaamisen, kontekstuaalisen luvanhallinnan varmistaen, että AI-agentit pääsevät vain siihen, mitä he tarvitsevat, kun he sitä tarvitsevat.
Yhdistä MCP-palvelimet todennuksen kanssa
MCP:n suosio on kasvanut AI-agenttien parantamisessa tarjoamalla enemmän tilannekohtaisia tietoja, mikä parantaa niiden suorituskykyä ja käyttäjäkokemusta.
Miksi MCP-palvelin liittyy todennukseen ja miksi se on tärkeää?
Olemme aiemmin kirjoittaneet artikkelin auttaaksemme ymmärtämään, mikä MCP-palvelin on.
MCP-palvelin on avainosa Malli-konteksti-protokollasta, joka toimii siltana AI-mallien ja ulkoisten tietolähteiden välillä. Se mahdollistaa reaaliaikaiset kyselyt ja tiedon noutamisen palveluista, kuten Slack, Gmail ja Google Kalenteri. Rakentamalla MCP-palvelimen voit yhdistää nämä etäpalvelut LLM:eihin, mikä parantaa AI-pohjaisten sovellustesi paremman kontekstin ja älykkäämmän tehtävien suorittamisen avulla.
Toisin kuin Retrieval-Augmented Generation (RAG) -järjestelmät, jotka vaativat upotusten luomista ja asiakirjojen tallentamista vektoridatabasseihin, MCP-palvelin pääsee tietoihin suoraan ilman ennakkoindeksointia. Tiedot eivät ole ainoastaan tarkempia ja päivitetympiä, vaan ne integroituvat myös pienemmällä laskentateholla ja tietoturvaa vaarantamatta.
Viite: https://norahsakal.com/blog/mcp-vs-api-konteksti-protokolla-selitetty
AI-agenttien, jotka käyttävät MCP-palvelinta, välillä tapahtuu useita vuorovaikutuksia MCP-palvelimen
, LLM:n
, agentin
ja käyttäjän
välillä.
Tämän päivän AI-vetoisessa maailmassa, jossa agentit hoitavat monia tehtäviä eri palveluiden kautta, niiden integroiminen useille MCP-palvelimille on tulossa korkean kysynnän kohteeksi.
Agentin todennus on nouseva trendi — tuotteesi tulisi sopeutua
Hyvä esimerkki on Composio.dev, kehittäjäkeskeinen integraatioalusta, joka yksinkertaistaa, miten AI-agentit ja LLM:t yhdistyvät ulkoisiin sovelluksiin ja palveluihin. Kutsuttu “Todennus AI-agenteille toimimaan käyttäjien puolesta”, se tarjoaa kokoelman MCP-palvelimia (liittimiä), jotka voidaan helposti integroida AI-pohjaisiin tuotteisiin.
Todennustilassa työskennellessä, mutta todellisuudessa se on vain osa laajempaa CIAM (Customer Identity and Access Management) -kenttää. Se, mitä he ovat rakentaneet, on itse asiassa kokoelma MCP-palvelimia (liittimiä) — hyödyllistä, mutta vain osa siitä, mitä täysi CIAM-ratkaisu kattaa.
Rakentaen aiempiin esimerkkeihin, jos pidämme Google Drivea (etäpalvelut) MCP-palvelimena sen sijaan, että se olisi Airbnb, siitä tulee enemmän kuin vain kolmannen osapuolen integraatio - se toimii ulkoisena tietolähteenä. Tämä mahdollistaa agentin pääsyn kontekstuaalisiin tietoihin, vuorovaikutuksen LLM:n kanssa ja mahdollisesti oikeuksien saannin luoda, lukea, päivittää ja poistaa (CRUD) tiedostoja.
Kuitenkin perus todennus- ja valtuutusvaatimukset pysyvät samana.
Käytä Logtoa hoitaaksesi agenttituotteidesi todennus
Logto on monipuolinen CIAM-ratkaisu, joka tukee SaaS- ja AI-agenttituotteita, tehden tunnistautumisesta ja valtuutuksesta saumatonta. Tässä syyt miksi:
- Hallittu todennus AI-agenttituotteille – Logto tukee OAuth 2.0, SAML, API-avaimet, henkilötunnuksia ja JWT:itä, mikä mahdollistaa helpon integraation useiden MCP-palvelimien kanssa. Voit jopa rakentaa oman MCP-palvelimesi ja yhdistää sen Logtoon sen avoimesti standardoidun perustan ansiosta.
- Identiteettitarjoajan (IdP) kyvyt – Kun tuotteellasi on vakiintuneita käyttäjiä, Logto voi toimia IdP:nä, muuttaen palvelusi MCP-palvelimeksi ja integroimalla sen AI- ekosysteemiin.
- Edistynyt valtuutus
- Roolipohjainen pääsynhallinta (RBAC) käyttäjäroolien hallintaan
- Mukautettu JWT-pohjainen ABAC hienorakeista, dynaamista pääsynhallintaa varten
- Parannettu tietoturva - ominaisuudet kuten monivaiheinen todennus (MFA) ja vahvistettu todennus auttavat turvaamaan kriittiset toimenpiteet ja parantavat agentin turvallisuutta.
Onko sinulla kysymyksiä? Ota yhteyttä tiimiimme oppiaksesi, kuinka Logto voi parantaa AI-agenttikokemustasi ja vastata tietoturvatarpeisiisi.