Kehitä MCP-palvelimia.
Yhdistä järjestelmät kohdennetusti.
Tekoälyn on tarkoitus vastaamisen lisäksi työskennellä kohdennetusti nykyisten järjestelmien kanssa. DAXS kehittää sopivat MCP-palvelimet ja sovittimet selkein työkaluin, rajatuin oikeuksin ja todennettavin tuloksin.
MCP-palvelin tuo määritellyt toiminnot tekoälysovellusten käyttöön.
Avustajan halutaan hakevan tukipyynnön tilan, etsivän hyväksyttyä dokumentaatiota tai luovan valmistellun merkinnän. Tämä edellyttää selkeästi kuvattua, rajattua pääsyä. DAXS kehittää sopivat MCP-palvelimet ja niiden taustalla olevat API-yhteydet nykyisiin yritysjärjestelmiin.
MCP eli Model Context Protocol kuvaa, miten tekoälysovellukset voivat hyödyntää muun muassa työkaluja, tietoresursseja ja valmisteltuja kehotteita. MCP-palvelin on tekninen sovitin. Hyvä työkalun nimi ei yksin tee siitä turvallista eikä itsenäisesti toimivaa agenttia.
Perinteinen API
Sovellus kutsuu toisen järjestelmän ennalta määriteltyä toimintoa. Tietomalli, käyttöoikeudet, validointi ja virheenkäsittely suunnitellaan tätä pääsyä varten.
MCP-integraatio
Yhteensopiva tekoälyasiakassovellus voi käyttää kuvattuja toimintoja ja resursseja yhteisellä protokollalla. Konkreettinen hyväksyntä ja toteutus kohdejärjestelmässä ovat edelleen erillisiä tehtäviä.
Tekoälyagentti
Sovellus yhdistää mallin, tilan ja työkalut useita vaiheita varten. Se tarvitsee rajatun toimeksiannon, keskeytysehdot ja toimiensa jäljitettävän valvonnan. Agentti voi käyttää MCP:tä tai muita rajapintoja.
Asiakassovellus, rajapinta ja kohdejärjestelmä tarkastavat oman alueensa.
Tekoälysovellus ehdottaa työkalukutsua. MCP-palvelin tarkastaa identiteetin, sallitun toiminnon ja syötteet. Kohdejärjestelmä toteuttaa lisäksi omat pääsysääntönsä. Kriittistä toimea varten tarkastetaan konkreettinen hyväksyntä ennen suoritusta.
Kaavio esittää yksilöllisen integraation esimerkkiarkkitehtuurin. Yhteensopivat asiakassovellus-, SDK- ja protokollaversiot määritellään ja testataan ennen toteutusta.
Toimeksianto määrittää tiedot ja toimet.
Tukijärjestelmän rajapinnan ei tarvitse avata koko tietokantaa. Työkalu voi esimerkiksi palauttaa vain sallitun tilatiedustelun tarvitsemat kentät. Toinen työkalu luo pelkän luonnoksen. Yleiset komentotulkki-, SQL- tai ylläpitotoiminnot olisivat tähän tarpeettoman laaja kokonaisuus.
| Tyyppi | Mahdollinen työkalu | Tärkeä tarkastus |
|---|---|---|
| Lukeva | Tukipyynnön tilan hakeminen, hyväksytyn dokumentaation etsiminen tai teknisen tilan kysely. | Käyttäjä saa nähdä kyseisen kohteen. Palautetaan vain tarvittavat kentät, rajattu tulosmäärä eikä muiden organisaatioiden tietoja. |
| Kirjoittava, rajattu | Vastausluonnoksen tai jäsennellyn sisäisen muistiinpanon valmistelu. | Tarkasta kentät ja sallitut sisällöt, merkitse luonnos selkeästi, hallitse uusintoja ja palauta tulos jäljitettävästi. |
| Kriittinen | Sovitun muutoksen käynnistäminen tuotantojärjestelmässä. | Toimeen ja kohteeseen sidottu lisähyväksyntä. Oikeus tarkastetaan uudelleen juuri ennen suoritusta, ja rajat sekä paluureitti määritellään. |
Myös lukeva työkalu voi paljastaa luottamuksellista tietoa. Pelkkä luku ei siis korvaa valtuutusta. Kirjoittaville kutsuille suunnitellaan lisäksi idempotenssi, virhetilat ja epäselvien tulosten käsittely. Aikakatkaisu ei todista, ettei toimea suoritettu.
Onnistunut kirjautuminen ei vielä oikeuta jokaiseen kohteeseen.
Erotamme kirjautumisen tekoälyasiakassovellukseen, valtuutuksen MCP-palvelimella ja kohdesovelluksen käyttöoikeudet. Käyttäjä-, ryhmä- ja organisaatiokonteksti perustuvat luotettavaan identiteettiin. Malli ei saa määrittää rooliaan tai sallittua tietojen laajuutta itse tekstisyötteellä.
Etäkäyttöinen HTTP-integraatio tarvitsee sopivan valtuutusmallin. Pääsytunnisteiden on oltava tarkoitettuja kyseiselle palvelulle, ja niiden voimassaolo sekä laajuus on tarkastettava. Taustajärjestelmien tunnukset suojataan ja rajataan kohteen mukaan. Mielivaltaisesti edelleen välitetty asiakassovelluksen pääsytunniste ei ole yleinen järjestelmäavain.
Paikallisen prosessin yhteydellä on erilaiset rajat kuin yrityksen etäpalvelulla: esimerkiksi käynnistettävä ohjelma, sen alkuperä ja käyttöjärjestelmäoikeudet. Helppo paikallinen suoritus ei korvaa ohjelman tai sen tietojen käytön tarkastusta. Molemmille malleille sovitaan sallitut yhteydet ja tekniset vastuut.
MCP on protokolla, ei täydellinen turvallisuusarkkitehtuuri.
Varsinaiset rajat toteutetaan palvelinlogiikalla, kohdejärjestelmän oikeuksilla, suojatuilla tunnuksilla, verkkosäännöillä ja todennettavilla hyväksynnöillä. Sopiva toteutus riippuu asiakassovelluksesta, tiedoista, toimista ja käyttömallista.
Rajat koskevat myös sopimattomia malliehdotuksia.
Asiakirja, tukipyynnön teksti tai työkalutulos voi sisältää manipuloituja ohjeita. Tällaisia sisältöjä käsitellään tietona. Ne eivät saa myöntää uusia oikeuksia eivätkä oikeuttaa muuten estettyä toimea. Kehotteen ohjeet voivat tukea sovellusta; sitova valvonta on mallin ulkopuolella.
Syötteet ja kohteet
Validoi tyypit, sallitut arvot, kohdeyhteys, polut ja tulosmäärät palvelimella. Rajaa sallitut rajapinnat ja verkkokohteet. Ei vapaasti koottuja komentoja eikä hallitsemattomia osoitekutsuja.
Toimet ja hyväksynnät
Näytä kutsun laajuus ja sivuvaikutukset ymmärrettävästi. Sido kriittiset hyväksynnät konkreettiseen operaatioon, rajaa niiden voimassaolo ja tarkasta ne ennen suoritusta. Määrittele keskeytys- ja uusintasäännöt.
Ylläpito ja jäljitettävyys
Varaa kutsu- ja aikarajat, virheenkäsittely ja tarkoitussidonnaiset lokit. Tunnuksia ei sisällytetä mallikontekstiin eikä diagnostiikkatulosteisiin. Poikkeavia pääsypyyntöjä on voitava tutkia ja käyttöoikeuksia poistaa.
Testaamme normaalit työnkulut sekä kielletyt kohdepääsyt, manipuloidut sisällöt, vanhentuneet valtuudet, päällekkäiset kutsut ja hylätyn hyväksynnän. Tämä vähentää riskejä. Yleinen lupaus jokaisen kehotteeseen kohdistuvan hyökkäyksen estämisestä ei olisi luotettava.
Aloita rajattavissa olevasta toiminnosta.
Kartoitamme kohdesovelluksen, nykyiset rajapinnat, käyttäjäroolit ja tarvittavat kentät. Näistä muodostuu rajattu työkaluluettelo selkein syöttein ja tuloksin. Lukeva pilotti voi osoittaa integraation hyödyn arjessa. Kirjoittavat vaiheet lisätään ja testataan tarvittaessa erikseen.
- Rajaa toimeksianto: mikä ongelma, mitkä kohteet ja ketkä käyttäjät?
- Kehitä rajapinta: liitä kohde-API, kuvaa työkalu ja toteuta oikeudet sekä virhetilanteet.
- Hyväksy käytännössä: testaa sallitut ja kielletyt tapaukset, hyväksynnät ja uusinnat.
- Luovuta ylläpidettävästi: kirjaa dokumentointi, pääsynhallinta, versioiden ylläpito ja vastuut.
DAXS voi toteuttaa tämän yksilöllisenä kehitys- ja integraatiotyönä. Pelkkä tietokysely voi ratketa tarkoituksenmukaisesti myös perinteisellä rajapinnalla tai skriptillä. Sopivasta laajuudesta keskustellaan nykyisten järjestelmienne pohjalta.
Konkreettinen toivottu toiminto, kyseinen sovellus, nykyinen API-dokumentaatio ja anonymisoitu esimerkki. Tunnukset tai luottamukselliset asiakastiedot eivät kuulu julkiseen yhteydenottoon.
Selvitämme nämä keskustelussa.
Miten API ja MCP eroavat toisistaan?
API tarjoaa järjestelmän toimintoja käyttöön. MCP kuvaa yhteisen tavan tarjota työkaluja ja kontekstia sitä tukeville tekoälysovelluksille. MCP-palvelin voi käyttää tähän nykyisiä rajapintoja. Niiden oikeudet ja toiminnalliset säännöt ovat edelleen tarpeen.
Tarvitseeko jokainen automaatio tekoälyagentin?
Ei. Ennalta määritelty tuonti tai yksiselitteinen laskenta voidaan usein toteuttaa helpommin skriptillä tai suoralla API-yhteydellä. Agentti tulee kyseeseen, jos vaihtelevat tehtävät todella tarvitsevat joustavaa vaiheiden valintaa.
Saako MCP-työkalu tehdä muutoksia itse?
Jos sitä halutaan toiminnallisesti ja se on suojattu teknisesti. Lukevat toiminnot, rajatut muutokset ja kriittiset toimet käsitellään erikseen. Hyväksynnät, kohdeoikeudet, syötteiden tarkastus ja jäljitettävät tulokset kuuluvat kuhunkin toimintoon.
Riittääkö kirjautuminen tekoälypalveluun käyttöoikeudeksi?
Ei. Palvelimen on tarkastettava kutsuja ja tämän valtuudet. Kohdejärjestelmän on sallittava pääsy kyseiseen toimintoon ja kohteeseen. Työkalukutsu ei saa luoda oikeuksia, joita käyttäjällä ei muuten ole.
Miten tarkoituksenmukainen pilotti alkaa?
Selkeästä hyödystä ja muutamasta rajatusta työkalusta, mahdollisuuksien mukaan ensin lukevina. Määrittelemme onnistumiskriteerit ja testaamme luvattomat pääsyt, ongelmalliset sisällöt, aikakatkaisut sekä toistuvat kutsut ennen kirjoittavien toimintojen laajentamista.
Työkalun käyttöoikeus ei vielä anna käyttöönottolupaa.
Linux-järjestelmän agentti voi käyttää rajapintoja, paikallisia työkaluja tai ulkoisia palveluja. Oma palveluidentiteetti, rajatut tiedosto-oikeudet, prosessieristys, sallitut verkkokohteet ja turvallisesti hallitut tunnukset suunnitellaan erikseen. Paikallinen agentti ei siis automaattisesti ole verkoton. Jokainen ulkoinen kutsu kuuluu tietovirtaan. Mallinvaihdot, työkaluvirheet, suoritusajan ja kustannusten rajat sekä jäljitettävä keskeytysmenettely testataan samalla.
Tutustu agenttien oikeuksiin ja hyväksyntöihin
Skripti, työnkulku vai tekoälyagentti: konkreettiset päätöskysymykset
Keskustellaan käyttötapauksestanne.
Minkä pitäisi helpottua, mitä tietoja siihen liittyy ja mitä järjestelmiä on jo käytössä? Näiden perusteella kehitämme tarkoituksenmukaisen aloituksen ja rajattavissa olevan seuraavan vaiheen.