Tietopankki

Hallittavat MCP-työkalut tekoälyagenteille

Kirjoittaja: Piotr AdamskiJulkaistu: Päivitetty:

Lähde → Tarkistus → Päätös → Näyttö

Model Context Protocol (MCP) helpottaa mallin tai agentin liittämistä työkaluihin. Itse protokolla ei päätä saako agentin suorittaa tietty operaatio, millä resurssilla ja millä seurauksilla. Sovelluskerroksen on edelleen pakko toteuttaa nämä rajat.

Jos agentti voi käyttää MCP:tä lukeakseen raportin, muuttaakseen asetuksia, aloittaakseen rahankäytön tai poistaakseen resurssin, käsittelemme sitä etuoikeutettuna API‑asiakkaana. Prompti kuvaa aikomuksen. Yhdyskäytävä (gateway) toteuttaa rajoitukset.

Käytännössä suunnittelemme tämän rajan seitsemän periaatteen ympärille.

1. Erota operaattorin identiteetti kohdejärjestelmän tunnuksista

Agentti toimii jonkun puolesta. Meidän täytyy siis vastata vähintään kahteen erilliseen kysymykseen:

  • kuka pyysi tätä operaatioita ja mitä hän saa tehdä Brillnetissä?
  • kuinka Brillnet tunnistautuu ulkoiselle tarjoajalle?

Ne eivät ole sama asia.

Sisäisessä Brillnet Ads MCP -työkalussamme operaattori kulkee Brillnetin valtuutuskerroksen läpi, kun taas kutsut Googleen käyttävät erillistä palvelutunnusta. Tarjoajan token on lyhytikäinen eikä sitä palauteta MCP:n kautta mallille datana.

Mallin ei tarvitse tietää tunnusta suorittaakseen sallitun tehtävän. Se ei myöskään voi vahingossa liittää tunnusta vastaukseensa, jos sitä ei koskaan vastaanotettu.

Sääntö

Salaisuus tulisi olla saatavilla vain komponentille, jonka on käytettävä sitä, eikä koko suoritusketjulle.

2. Ilmaise oikeudet operaatioittain, ei pelkästään agentin nimellä

Rooli kuten marketing-agent on helppo lukea, mutta se itsessään kertoo hyvin vähän siitä, mitä järjestelmä oikeasti sallii.

On hyödyllisempää erottaa oikeudet seurauksittain:

read
→ raportointi ja haku

write
→ resurssin luominen tai muokkaaminen

operate
→ operatiivisen seurauksen aktivointi, kuten kulutus tai julkaisu

destructive
→ poisto, irrottaminen, peruutus tai muu vaikeasti käännettävä muutos

Agentilla voi olla read ilman write‑oikeutta. Sillä voi olla write kampanjan valmisteluun, mutta ei operate, jolloin se ei voi käynnistää kampanjaa. Poisto voi vaatia sekä write‑ että destructive‑oikeudet.

Nimet eivät tarvitse olla täsmälleen nämä. Tärkeä ero on muutoksen valmistelun ja sen seurauksen aktivoinnin välillä.

Read: Least privilege for AI agents

3. Turvalliset oletusarvot toimivat ilman mallin apua

Jos yhden parametrin puuttuminen aktivoi toiminnon, oletus on turvaton.

Sisäisessä Brillnet Ads MCP:ssä uusi kampanja pysyy PAUSED‑tilassa, jos tilaa ei erikseen anneta. Tämä vaikuttaa pieneltä, mutta sääntö on tärkeä: puuttuva tieto ei ole suostumus kulutuksen aloittamiseen.

Sama malli pätee muissakin tilanteissa:

  • asiakirja ilman tilaa → luonnos, ei julkaisu;
  • uusi käyttäjä ilman roolia → ei pääsyä, ei oletusroolia;
  • integraatio ilman vahvistettua kohdetta → ei synkronointia;
  • epäselvä resurssi → virhe, ei “todennäköisin” tietue;
  • puuttuva hyväksyntä korkean riskin toiminnolle → pysäytä, älä yritä uudelleen.

Turvallisen oletusarvon on pysyttävä turvallisena, vaikka malli harhautuisi, jättäisi kentän pois tai ymmärtäisi aikomuksen väärin.

4. Korkean vaikutuksen operaatioilla on oltava erillinen portti

Agentti voi valmistella teknisesti oikean muutoksen, joka on silti väärä liiketoimintapäätös.

Budjetin kulutus, sisällön julkaisu, asiakkaan viestintä, pääsyn muuttaminen tai datan poisto aiheuttavat seurauksia agentin istunnon ulkopuolella. Hyväksynnän tulisi siksi olla itsenäinen tapahtuma.

Vähintään hyväksyntäesikatselun tulisi näyttää:

  • kohdejärjestelmä ja resurssi;
  • operaatio‑tyyppi;
  • muutoksen olennaiset parametrit;
  • odotettu seurauks;
  • onko operaatio käännettävissä;
  • kuka hyväksyy.

“Jatketaanko?” ei riitä. Henkilön täytyy tietää mitä tarkalleen ollaan hyväksymässä.

Read: When should an AI agent require human approval?

5. Uudelleenyrittäminen ei saa hiljaisesti monistaa kirjoitusta

Agenttipohjaiset järjestelmät tekevät monia API‑kutsuja. Verkkovirheet, aikakatkaisut ja uudelleenyrittäminen ovat normaaleja. Ongelma alkaa, kun saman toiminnon toistaminen luo toisen resurssin tai suorittaa toisen maksun, julkaisun tai viestin.

Missä operaatio tukee sitä, käytämme idempotenssi‑avainta. Yhdyskäytävä tunnistaa saman yrityksen ja estää hallitsemattoman duplikaattikirjoituksen.

Tämä tulisi yhdistää read‑after‑write‑malliin:

agentti pyytää muutosta
↓
yhdyskäytävä validoi ja suorittaa kirjoituksen
↓
kohdejärjestelmä vastaa
↓
yhdyskäytävä lukee syntyneen resurssin tilan
↓
operaattori näkee tuloksena syntyneen tilan

Palvelimen palauttama HTTP 200 ei siis ole ainoa todiste siitä, että järjestelmä on odotetussa tilassa.

6. Raaka‑yhdyskäytävä ei saa muuttua takaportiksi

Suuret API:t luovat käytännön houkutuksen: sen sijaan että rakennettaisiin oma työkalu jokaiselle päätepisteelle, tarjotaan yleisempi REST‑kyky.

Se voi olla perusteltua, mutta vain jos yleinen polku perii samat kontrollit.

Brillnetissä menetelmä, päätepiste ja pyynnön ominaisuudet luokitellaan ennen suoritusta. Alhaisen tason pyyntö ei ohita vaadittuja toiminnallisia laajuuksia tai lisäkontrollia tuhoisille operaatioille.

Anti‑pattern näyttää tältä:

turvalliset MCP‑työkalut
→ rajoitetut ja validoidut

raw_http_request
→ voi kutsua mitä tahansa päätepistettä täyden käyttöoikeustokenin kanssa

Tässä suunnittelussa aiemmat kontrollit ovat lähinnä kosmeettisia. Laajin polku määrittelee todellisen turvallisuusrajan.

7. Audit‑loki tallentaa päätöksen ja tuloksen, ei salaisuuksia

Sisäinen työkalumme kirjaa pyyntö‑metatiedot ja tulokset append‑only‑integraalisesti hallitussa audit‑ketjussa. Tunnistetiedot, valtuutus‑otsikot ja raakat henkilötiedot jätetään pois.

Tämä ero on merkittävä. Audit‑loki on tarkoitettu rekonstruoimaan toiminto, ei monistaa turvallisuuskontekstia toiseen tietovarastoon.

Agentin operaatiossa haluamme yleensä tietää:

  • pyyntö‑/tehtävä‑ID;
  • operaattorin ja agentin identiteetti;
  • työkalu ja operaatio‑luokka;
  • kohderesurssi;
  • valtuutus‑päätös;
  • hyväksyntä‑ID, jos hyväksyntä vaadittiin;
  • tarjoajan/backend‑tulos;
  • kirjoituksen jälkeen havaittu tila;
  • sovellettavan politiikan tai konfiguraation versio.

Read: AI agent audit trails

Esimerkkirakenne: agentti Google Adsille

Sisäinen tapaus on tarkoituksellisesti kapea. Työkalu on tarkoitettu vain Brillnetin omistamille Google Ads -tileille. Se ei ole toimisto‑palvelu eikä saa pääsyä asiakkaiden mainostileihin.

Virtaus voidaan yksinkertaistaa näin:

Brillnet‑operaattori
↓
identiteetti + profiili + laajuudet
↓
agentti / malli
↓
MCP‑työkalukutsu
↓
yhdyskäytävä: validointi + luokittelu + hyväksyntäpolitiikka
↓
lyhytikäinen tarjoajatoken
↓
Google Ads API
↓
normalisointi + redaktio
↓
read‑after‑write / tulos
↓
audit‑loki

Tärkein kontrolli ei ole mallin sisällä. Se on kerros aikomuksen ja suorituksen välillä.

Näyttäviä anti‑pattern‑esimerkkejä

Yksi ylläpitäjä‑token kaikille agenteille

Se tekee prototyypistä helpomman. Myöhemmin on vaikea rajoittaa virheen vaikutusta tai todistaa, että agentilla olisi oikeus käyttää resurssia lainkaan.

“Malli kysyy käyttäjältä, onko toiminto riskialtis”

Tämä delegoi turvallisuuspäätöksen samalle komponentille, jonka virheitä kontrolli on tarkoitus rajoittaa.

Koko promptin ja vastauksen lokittaminen audit‑lokia varten

Keskustelu ei ole operatiivinen audit‑tietue. Siinä voi myös olla tietoa, jota ei tule kopioida lokijärjestelmään.

Kaikkien virheiden automaattinen uudelleenyrittäminen

Kaikki virheet eivät ole ohimeneviä. Kaikki kirjoitukset eivät ole idempotentteja. Luokittelematon uudelleenyrittäminen voi lisätä vahinkoa.

Yleinen päätepiste täysillä oikeuksilla “tulevia ominaisuuksia varten”

Jos yksi laaja työkalu voi ohittaa rajoitetut työkalut, laaja työkalu on itse asiassa käyttöoikeusmalli.

MCP‑palvelimen tarkistuslista

Ennen tuotantokäyttöä tarkistaisin ainakin:

  • Onko operaattorin identiteetti tiedossa jokaiselle kutsulle?
  • Onko kohdejärjestelmän tunnukset piilotettu mallilta?
  • Voidaanko luku‑, kirjoitus‑, operointi‑ ja tuho‑oikeudet erottaa?
  • Rajoittaako valtuutus resurssin/tenantin/tilin lisäksi myös toiminnon?
  • Johtaako puuttuva parametri turvalliseen tilaan?
  • Onko taloudellisilla, ulkoisilla ja tuhoisilla operaatioilla itsenäinen hyväksyntä?
  • Onko kirjoituksen uudelleenyrittäminen hallittua?
  • Luetaanko kohderesurssi takaisin kirjoituksen jälkeen?
  • Käyttääkö jokin alhaisen tason yhdyskäytävä samoja valtuutussääntöjä?
  • Jättääkö audit‑loki pois tokenit, salaisuudet ja raakat henkilötiedot?
  • Hylkääkö se mielivaltaiset tiedostopolut ja rajoittamattomat payloadit?
  • Voiko agentin tai operaattorin pääsyn peruuttaa keskitetysti?

MCP 2026‑07‑28 muuttaa protokollaa, ei sovelluksen kontrollien tarvetta

MCP‑versio 2026‑07‑28 toi muun muassa tilattoman protokollaytimen ja lisävaltuutuksen kovennuksen. Nämä muutokset helpottavat viestintäkerroksen skaalaamista ja ymmärtämistä. Ne eivät kuitenkaan määrittele liiketoimintapolitiikkaa: esimerkiksi onko agentilla oikeus käyttää 5 000 PLN, poistaa tili tai lähettää viesti 10 000:lle ihmiselle.

Sovelluksen on edelleen pakko toteuttaa nämä päätökset.

Kenelle tämä suunnittelumalli on tarkoitettu

Prosessinomistajat, kehittäjät ja turvallisuusarvioijat tarvitsevat tämän rajan. Valmistusagentit voivat laatia muutospyyntöjä; kiinteistö‑hallinta‑agentit voivat järjestää asiakirjoja; B2B‑agentit voivat analysoida tukipyyntöjä. Asukasilmoitusten lähettäminen tai asiakasoikeuksien muuttaminen vaatii seurauksen kontrollia.

Ads‑MCP‑esimerkki perustuu sisäiseen työkaludokumentaatioon. Se ei kuvaa asiakas‑mainostili‑palvelua eikä itsenäistä audit‑tarkastusta nykyisestä tuotantoympäristöstä.

Identiteetti ja eristäminen vaativat enemmän kuin kelvollinen token

MCP‑valtuutus vaatii tokenin, joka on tarkoitettu palvelimen omalle resurssille. Kelvollinen allekirjoitus toisen palvelun tokenissa ei riitä. Tarkista audience, issuer ja voimassaolo. Hylkää sopimattomat tokenit ennen suoritusta.

Tarkista myös resurssin pääsy. Vertaa annettua tenant_id‑arvoa palvelimen määrittelemään identiteettiin sen sijaan, että luottaisit agentin tunnisteeseen. Jokainen luku‑ ja kirjoitusoperaatio tarvitsee resurssivaltuutuksen, mukaan lukien liitteet, viennit ja taustatyöt.

MCP 2026‑07‑28 ei sisällä protokollatasoisia istuntoja. Sovellukset voivat silti ylläpitää tilaa, kuten muutoksen‑esikatselukahvaa. Omistus ei saa korvata tunnistautumista. Kytke kahvat valtuutetuille operaattoreille, tarkista jokainen käyttö ja aseta vanhentumisaika. Varastettu kahva ei saa paljastaa toisen henkilön työnkulkua.

Vahvista sisältö ja viestintäkohteet

Hakutulokset, PDF‑tiedostot, sähköpostit ja API‑vastaukset ovat analyysimateriaalia. Upotetut ohjeet salaisuuksien hakemiseen tai asiakirjojen lähettämiseen muualle eivät ole operaattorin hyväksyntää. Prompt‑injektion suojauksessa palvelimen on hylättävä valtuuttamattomat resurssit, vastaanottajat ja toiminnot, vaikka työkalun argumentit olisivatkin teknisesti kelvollisia.

Työkalulle, joka hyväksyy URL‑osoitteita, määrittele sallitut kohteet ja uudelleenohjausten käsittely. MCP‑ohjeistus käsittelee SSRF‑ongelmaa OAuth‑metatietojen haussa. Arvioi sama ongelma omissa hakutyökaluissa. Julkisen sivun hakeminen ei saa paljastaa paikallista hallintapalvelua tai pilven metatietopistettä. Suojaukset riippuvat verkkoarkkitehtuurista; pelkkä isäntänimilista ei välttämättä hallitse lopullista yhteyspistettä.

Tiedostotyökaluissa rajoita hakemistoja ja payload‑kokoa. Hylkää polut sallitun alueen ulkopuolelta, tuntemattomat kentät ja liialliset viennit. Selkeä virheilmoitus on parempi kuin hiljainen laajentuminen.

Pieni käyttöönottoesimerkki: palvelupyyntöluonnokset

Oletetaan, että yritys haluaa lyhentää laitteiston vikapyyntöjen valmistelua. Agentti lukee hyväksytyn käsikirjan ja tapahtumahistorian, sitten laatii luonnoksen. Lähetys toimittajalle on erillinen toiminto. Tämä on suunnitteluskenaario, ei väite siitä, että Brillnet tarjoaisi tällä hetkellä tätä ominaisuutta.

Palvelun omistaja valitsee yhden laitteistoryhmän ja määrittelee odotetun tuloksen: luonnos, jossa on laite, oire, tapahtuma‑aika ja puuttuvat tiedot. Kehittäjä tarjoaa kaksi kapeaa työkalua: hyväksytty asiakirjahaku ja luonnoksen luonti määritellyssä projektissa. Alkuversio ei sisällä viestintää eikä laitteiston konfiguraatiota. Turvallisuusarvioija tarkistaa datan laajuuden ja keskitetyn pääsyn peruutuksen.

Testaa yksi sallittu luku, yritys‑projektin ylittävä lukuyritys, asiakirja, jossa on haitallisia ohjeita, ja kirjoituksen uudelleenyrittäminen aikakatkaisun jälkeen. Pieni työkalukatalogi riittää aloittamiseen. Sen on pakko toteuttaa suunnitellut rajoitukset.

Jos lähetys lisätään myöhemmin, hyväksynnän on katettava vastaanottaja ja sisältö. Vastaanottajan muuttaminen peruuttaa aikaisemman hyväksynnän. Jos tarjoaja ei tue idempotenssia, ratkaise epäselvä aikakatkaisu tarkistamalla, onko viesti jo olemassa. Älä lähetä uudelleen pelkästään koska agentti ei saanut vastausta.

Mitä tehdä huomenna, omistajan kanssa

Prosessinomistaja valitsee yhden toiminnon ja sen sallitun seurauksen. Kehittäjä kartoittaa työkalun, operaatio‑luokan ja resurssin, mukaan lukien laajin mahdollinen pääsypolku. Turvallisuusarvioija tarkistaa, missä operaattorin identiteetti päättyy, missä palvelutunnus alkaa ja pääseekö malli käsiksi tunnuksiin. Ensimmäisen päivän tuloksena pitäisi olla lyhyt kartta ja yksi suoritus, jonka tila voidaan vahvistaa kohdejärjestelmässä.

Mittaa hyväksytyn luonnoksen laatu, hylätyt laajuusvirheet ja ihmisen tarkistusajat. Useammat työkalukutsut eivät automaattisesti tuo lisäarvoa. Jos korjaus vie enemmän aikaa kuin valmistelu säästää, kavennetaan tehtävää ennen lisäominaisuuksien lisäämistä.

Tekninen ohjeistus ja oikeudelliset velvoitteet

OWASP ja NIST tarjoavat teknistä ohjeistusta. MCP‑spesifikaatio määrittelee protokollavaatimukset. Nämä lähteet eivät itsenäisesti määrittele yrityksen oikeudellisia velvoitteita tai tietojen säilytysaikoja. Määritä sovellettavat toimialakohtaiset, sopimus‑ ja lainsäädännölliset vaatimukset prosessille. Tämä opas selittää kontrollisuunnittelun eikä myönnä vaatimustenmukaisuustodistusta.

Raja

Nämä ovat malleja, joita käytämme omassa työssä. Tämä sivu ei väitä, että koko työkalu olisi sertifioitu tai yleisesti yhteensopiva OWASP:n, NIST:n tai MCP‑spesifikaation kanssa. Jokainen integraatio tarvitsee oman uhkamallinsa ja turvallisuustestinsä.

Jos haluat tarkastella, miten Brillnet käsittelee pääsyä, dataa ja tekoälyä, katso Security ja Compliance and AI oversight.

Lähteet

Tietopankki

Toimialaoppaat ja tekoälyagenttien käytännön hallintakeinot.

Keskustele prosessistasi →