Obsidian Security julkaisee ajonaikaisen käytäntömoottorin tekoälyagenttien toiminnan hallintaan

Obsidian Security on julkaissut ajonaikaisen käytäntöpäätösmoottorin, jonka avulla yritykset voivat hallita, mitä tekoälyagentit tekevät yrityssovelluksissa ennen toiminnon suorittamista. Julkistus laajentaa yhtiön agenttien tietoturva-alustaa MCP-tietoturvavälityspalvelimella, käytäntöpäätösrajapinnalla sekä koodaustyökalujen ja kolmannen osapuolen ohjelmistoihin upotettujen agenttien laajemmalla kattavuudella.

Julkaisu vastaa ongelmaan, jota tavalliset käyttöoikeuksien hallintakeinot eivät ratkaise täysin: agentilla voi olla kelvolliset tunnistetiedot ja hyväksytty sovellus käytössään, mutta se voi silti yrittää sopimatonta toimintoa. Esimerkiksi lupa lukea asiakastietoja ei välttämättä tarkoita lupaa viedä niitä ulkoiseen kohteeseen.

Obsidianin lähestymistavassa ehdotettua toimintoa arvioidaan keskitetysti hallittujen käytäntöjen perusteella. Arvioinnissa huomioidaan agentin taustalla oleva henkilö, hänen työsuhteensa ja käyttöoikeutensa, käytössä oleva sovellus sekä asiakkaan toimittamat tietojen luokittelut. Yhdistetyt valvontapisteet sallivat tai estävät toiminnon tai vaativat hyväksynnän, jos tämä ominaisuus on käytettävissä.

Agenttien löytämisestä niiden toiminnan hallintaan

Agenttien kartoituksessa selvitetään, mitä työkaluja on käytössä ja mihin niillä pääsee. Hallintakeinoilla voidaan vähentää tarpeettomia käyttöoikeuksia tai tunnistaa riskialttiita määrityksiä. Ajonaikaisessa käytäntöjen valvonnassa ratkaistaan jäljelle jäävä kysymys: mitä muutoin valtuutetun agentin pitäisi juuri nyt saada tehdä?

Obsidianin julkistus kattaa sekä työntekijöiden käyttämät agentit että yrityksen jo käyttämien ohjelmistojen mukana tulevat agentit. Laajennetut kartoitus- ja hallintaominaisuudet kattavat Salesforce Agentforcen, Databricksin, GitHubin, Microsoft 365:n, Snowflaken, ServiceNow’n ja Workdayn.

Kyseessä ovat erilaiset valvontakohteet. Agentin löytäminen SaaS-sovelluksesta ei yksin tarkoita, että kaikki sovelluksessa tehtävät toiminnot kulkisivat valvonnan kautta. Ajonaikainen valvonta riippuu tuetusta integraatiosta ja siitä pisteestä, jonka kautta toiminto kulkee.

Yhtiö lisäsi myös ajonaikaisen käytäntöjen tuen OpenAI Codexille nykyisten koodausagenttien hallintakeinojensa rinnalle. Julkistuksessa mainitaan riskeinä esimerkiksi tuhoisat komennot, tunnistetietojen paljastuminen ja projektin tarkoitetun laajuuden ulkopuoliset lukuoperaatiot – toimintoja, joita voi esiintyä muuten asianmukaisen kehitystyön aikana.

Knowledge Graph tuo päätöksentekoon puuttuvan kontekstin

Yhdyskäytävä voi tarkastella pyyntöä, mutta pelkkä pyyntö ei välttämättä kerro, millä valtuuksilla se tehdään. Tietoturvan kannalta hyödyllinen päätös voi edellyttää tietoa siitä, kuuluuko pyynnön esittävä tili työntekijälle vai alihankkijalle, onko työsuhde päättynyt ja mitä käyttöoikeuksia tilillä todellisuudessa on kohdesovelluksessa.

Obsidianin Knowledge Graph -arkkitehtuuri yhdistää ihmiset, tilit, sovellukset, tunnisteet, käyttöoikeudet ja niiden väliset suhteet. Yhtiön mukaan hallinnollisista rajapinnoista, toimintavirroista ja integraatioista saatu tieto normalisoidaan yhteiseen malliin, jossa versioidut entiteetit ja suhteet tallentavat muutokset ajan mittaan.

Tämän rakenteen avulla pääsyä voidaan jäljittää useissa järjestelmissä sen sijaan, että kutakin tiliä tarkasteltaisiin erikseen. Agentin näennäinen rooli voi olla rajattu, vaikka tunniste tai peritty käyttöoikeus antaisikin sille laajemmat oikeudet muualla. Näiden suhteiden yhdistäminen antaa käytäntömoottorille vankemman perustan arvioida, ovatko yksittäiset toiminnot organisaation sääntöjen mukaisia.

Asiakkaat voivat lisätä omaa kontekstiaan, esimerkiksi luokittelumerkintöjä. Käytännössä voidaan siten erottaa tavallinen tiedosto sellaisesta, jonka yritys määrittelee erittäin arkaluonteiseksi, sen sijaan että luotettaisiin yksinomaan tietoturvatoimittajan yleiseen määritelmään luottamuksellisista tiedoista.

Päätöksenteosta toiminnan valvontaan

Arkkitehtuurissa päätöksenteko ja toiminta on erotettu toisistaan. Obsidianin ajonaikaisen käytäntömoottorin kuvauksen mukaan valvontapiste keskeyttää ehdotetun toiminnon, lähettää sen tiedot arvioitavaksi ja soveltaa saatua päätöstä perusteluineen.

Uusi Policy Decision API laajentaa mallia asiakkaiden ylläpitämiin yhdyskäytäviin, agenttien suoritusympäristöihin ja työnkulkuihin. Yritys voi säilyttää nykyisen infrastruktuurinsa ja pyytää samalla Obsidianilta kontekstin huomioivaa arviota. Asiakkaan valvontakomponentin on tämän jälkeen sovellettava arviota ennen toiminnon jatkamista.

Obsidian kuvaa myös lipputilan, jolla käytäntöjen osumia voidaan testata todellista liikennettä vasten ennen toimintojen estämistä. Päätöstietueisiin tallennetaan agentti, pyynnön tehnyt henkilö, työkalu, argumentit, lopputulos ja sovellettu käytäntö. Näin tietoturvatiimit voivat selvittää, miksi toiminto sallittiin tai estettiin.

Hyväksynnän tuki on rajatumpi kuin yleinen sallimiseen tai estämiseen perustuva arkkitehtuuri: yhtiön nykyisen dokumentaation mukaan hyväksynnän vaatiminen on käytettävissä Claude Code -käytännöissä, jotka suoritetaan ennen toimintoa. Siksi integraatiokohtaiset ominaisuudet ovat tärkeitä, kun hallintakeinoja suunnitellaan sekalaiselle agenttijoukolle.

MCP-välityspalvelin pitää sovellusten tunnisteet poissa tekoälyasiakasohjelmista

MCP-tietoturvavälityspalvelu hallinnoi tekoälyasiakkaiden ja tuettujen yrityssovellusten välisiä yhteyksiä. Model Context Protocol eli MCP tarjoaa agenteille vakiomuotoisen tavan kutsua ulkoisten palvelinten tarjoamia työkaluja. Obsidian sijoittaa käytäntöjen tarkistuksen asiakkaan ja sovelluksen MCP-palvelimen väliin.

Tuotedokumentaation mukaan toimittajan suora MCP-URL-osoite korvataan Obsidianin hallinnoimalla päätepisteellä. Käyttäjät valtuuttavat käyttöoikeudet sovellustoimittajan suostumusprosessissa; tekoälyasiakas saa välityspalvelimen myöntämän tunnisteen sen sijaan, että se tallentaisi sovelluksen käyttöoikeustunnisteen itse.

Välityspalvelin yhdistää istunnon käyttäjään, hänen sovellustiliinsä ja asiaankuuluvaan asiakasympäristöön, kuten tiettyyn Salesforce-organisaatioon tai työtilaan. Se tarkistaa työkalukutsut ennen niiden välittämistä ja kirjaa, sallittiinko vai estettiinkö ne. Obsidianin mukaan ratkaisu toimii käyttäjän sovelluksessa jo olemassa olevien käyttöoikeuksien puitteissa eikä lisää oikeuksia jaetun palvelutilin kautta.

Ilmoituksessa mainitaan myös yhteistyö Cloudflaren ja sen MCP Server Portal -palvelun kanssa. Tavoitteena on yhdistää yhdyskäytävän sijainti liikenteen reitillä Obsidianin tarjoamaan identiteettiä, sovellusta ja dataa koskevaan kontekstiin.

Miksi toimintokohtaiset hallintakeinot ovat tärkeitä

Agentteja käyttöön ottavien yritysten käytännön haasteena on sallia hyödyllinen työ ja samalla ehkäistä vakavia seurauksia aiheuttavia virheitä. Kaikkien toimintojen kategorinen kieltäminen voi pysäyttää työnkulun kokonaan; tarkasti rajattu päätös voi sallia tavanomaiset tietojen lukutoiminnot mutta estää luvattoman viennin tai edellyttää tuhoisan muutoksen tarkistamista.

Obsidian kokoaa nämä päätökset yhteiseen käytäntökerrokseen, joka kattaa tuetut työkalut ja valvontapisteet. Ratkaisun hyöty riippuu taustalla olevan käyttöoikeuskontekstin laadusta ja siitä, kuinka kattavasti hallittavat toimintapolut kuuluvat sen piiriin. Kun agenttien operatiivinen vastuu kasvaa, kyvystä selittää ja panna päätös täytäntöön ennen toiminnan suorittamista tulee yhä tärkeämpi osa yritysten tietoturvaa.