Teadmised

Kontrollitud MCP-tööriistad tehisintellekti agentidele

Autor: Piotr AdamskiAvaldatud: Uuendatud:

Allikas → Kontroll → Otsus → Tõend

Model Context Protocol (MCP) teeb mudeli või agendi ühendamise tööriistadega lihtsamaks. Protokoll ise ei otsusta kas agendil on lubatud teostada konkreetne toiming, millisel ressursil ja millise tagajärjega. Rakenduskiht peab need piirid siiski jõustama.

Kui agent saab MCP‑i kaudu lugeda aruannet, muuta konfiguratsiooni, alustada kulutamist või kustutada ressursi, käsitleme teda kui privileegitud API‑klienti. Prompt kirjeldab kavatsust. Lüüsi (gateway) rakendab piiranguid.

Praktikas kujundame selle piiri umbes seitsme põhimõtte ümber.

1. Operatsiooni identiteet eraldatakse sihtsüsteemi volitustest

Agent tegutseb kellegi teise nimel. Seetõttu peame vastama vähemalt kahele eraldi küsimusele:

  • kes taotles seda operatsiooni ja mida tal on Brillnetis lubatud teha?
  • kuidas Brillnet autentib end välise teenuse pakkuja juures?

Need ei ole samad asjad.

Meie sisemises Brillnet Ads MCP‑tööriistas läbib operaator Brillneti volituskihi, samas kui Google‑i kutsed kasutavad eraldi teenuseidentiteeti. Pakkuja token on lühiajaline ja seda ei edastata mudelile MCP‑andmetena.

Mudelil ei ole vaja teada volitust, et täita lubatud ülesannet. Samuti ei saa mudel kogemata sisestada volitust vastusesse, kui ta seda kunagi ei saanud.

Reegel

Salasõna peaks olema kättesaadav vaid komponendile, kes seda kasutama peab, mitte kogu täitmisahelale.

2. Luba väljendatakse operatsiooni järgi, mitte ainult agendi nime järgi

Roll nagu marketing-agent on loetav, kuid iseenesest ütleb väga vähe sellest, mida süsteem tegelikult lubab.

Kasulikum on eristada õigused tagajärje alusel:

read
→ aruandlus ja andmete toomine

write
→ ressursi loomine või muutmine

operate
→ operatiivse tagajärje aktiveerimine, näiteks kulutamine või avaldamine

destructive
→ kustutamine, lahtiühendamine, tühistamine või muu keeruline tagasipööramine

Agent võib omada read õigust ilma write‑ita. Tal võib olla write õigused kampaania ettevalmistamiseks, kuid mitte operate, seega ta ei saa kampaaniat käivitada. Kustutamine võib nõuda nii write kui ka destructive õigusi.

Nimed ei pea olema täpselt need. Oluline on eristada muudatuse ettevalmistamist ja selle tagajärje aktiveerimist.

Loetu: Väikseim õiguste tase AI‑agendidele

3. Turvalised vaikeväärtused peavad toimima ilma mudeli abita

Kui ühe parameetri jätmine võib tegevuse käivitada, on vaikeväärtus ebaturvaline.

Meie sisemises Brillnet Ads MCP‑s jääb uus kampaania PAUSED olekusse, kui staatus ei ole selgesõnaliselt antud. Detail võib tunduda väike, kuid reegel on oluline: puuduv teave ei tähenda nõusolekut kulutuste alustamiseks.

Sama muster kehtib mujal:

  • dokument ilma staatuseta → mustand, mitte avaldatud;
  • uus kasutaja ilma rollita → puudub juurdepääs, mitte vaikimisi roll;
  • integratsioon ilma kinnitatud sihtkohta → sünkroniseerimine puudub;
  • ebamäärane ressurss → viga, mitte “tõenäolisem” kirje;
  • kõrge riskiga tegevuse puuduv heakskiit → peata, mitte proovi uuesti.

Turvaline vaikeväärtus peab jääma turvaliseks ka siis, kui mudel hallutsineerib, jätab välja välja või mõistab kavatsust valesti.

4. Kõrge mõjuga operatsioonid vajavad eraldi väravat

Agent võib ette valmistada tehniliselt korrektse muudatuse, mis on siiski vale äriline otsus.

Eelarve kulutamine, sisu avaldamine, kliendile sõnumi saatmine, juurdepääsu muutmine või andmete kustutamine tekitab tagajärgi, mis ulatuvad agendi seansi piiridest väljapoole. Seetõttu peaks heakskiit olema sõltumatu sündmus.

Vähemalt heakskiidu eelvaade peaks näitama:

  • sihtsüsteemi ja ressursi;
  • operatsiooni tüüpi;
  • muudatuse olulisi parameetreid;
  • oodatavat tagajärge;
  • kas operatsioon on pööratav;
  • kes heaks kiitja on.

Lihtne “Jätkata?” ei piisa. Inimene peab teadma täpselt, mida ta heaks kiidab.

Loetu: Millal peaks AI‑agent nõudma inimese heakskiitu?

5. Korduskatse ei tohi vaikimisi dubleerida kirjutamist

Agentlikud süsteemid teevad palju API‑kõnesid. Võrgutõrked, ajapiirangud ja korduskatsetused on tavalised. Probleem tekib siis, kui sama operatsiooni kordamine loob teise ressursi või käivitab teise makse, avaldamise või sõnumi.

Kui operatsioon seda toetab, kasutame idempotentsusvõtit. Lüüsi tuvastab sama katse ja takistab juhuslikku duplikaatkirjutust.

Sellele tuleks lisada read-after-write:

agent küsib muudatust
↓
lüüs valideerib ja teeb kirjutuse
↓
sihtsüsteem vastab
↓
lüüs loeb saadud ressursi oleku
↓
operaator näeb saadud olekut

Kui pakkuja tagastab HTTP 200, ei ole see ainsaks tõendiks, et süsteem on oodatud olekus.

6. Toores lüüs ei tohi muutuda tagasilükkepordiks

Suured API‑d tekitavad praktilise kiusamise: selle asemel, et luua iga lõpp-punkti jaoks eraldi tööriist, avada üldine REST‑võimekus.

See võib olla mõistlik, kuid ainult siis, kui üldine tee pärib samad kontrollid.

Brillnetis klassifitseeritakse meetod, lõpp‑punkt ja päringu omadused enne täitmist. Madala taseme päring ei mööda käi nõutud funktsionaalseid ulatusi ega täiendavat kontrolli destruktiivsete operatsioonide puhul.

Anti‑mustri näide:

turvalised MCP‑tööriistad
→ piiratud ja valideeritud

raw_http_request
→ võib kutsuda mis tahes lõpp‑punkti täiskoormusega tokeniga

Selles kujunduses on varasemad kontrollid peamiselt kosmeetilised. Kõige laiem tee määrab tegeliku turvalisuse piiri.

7. Auditi jälg ei salvesta otsust ja tulemust, vaid mitte saladusi

Meie sisemine tööriist salvestab päringu metaandmed ja tulemused lisandmatu, terviklikkuse kontrollitud auditijärjekorda. Volituste, autoriseerimispealkirjade ja toor isikuandmete identifikaatoreid ei sisaldata.

See eristamine on oluline. Auditi jälg peab võimaldama toimingu taastamist, mitte kopeerima turvakonteksti teise andmehoidlasse.

Agentoperatsiooni puhul tahame tavaliselt teada:

  • päringu/ülesande ID;
  • operaatori ja agendi identiteet;
  • tööriista ja operatsiooni klass;
  • sihtressurss;
  • autoriseerimisotsus;
  • heakskiidu ID, kui heakskiit oli nõutav;
  • pakkuja/tagasiside tulemus;
  • kirjutamise järel täheldatud olek;
  • rakendatud poliitika või konfiguratsiooni versioon.

Loetu: AI‑agendi auditijäljed

Näite arhitektuur: agent Google Ads‑i jaoks

Meie sisemine näide on tahtlikult kitsas. Tööriist on mõeldud ainult Brillneti omandatud Google Ads‑kontodele. See ei ole agentuuriteenus ega anna juurdepääsu kliendi reklaamikontodele.

Voo lihtsustatud skeem:

Brillneti operaator
↓
identiteet + profiil + ulatused
↓
agent / mudel
↓
MCP‑tööriista kõne
↓
lüüs: valideerimine + klassifikatsioon + heakskiitpoliitika
↓
lühiajaline pakkuja token
↓
Google Ads API
↓
normaliseerimine + redigeerimine
↓
read-after-write / tulemus
↓
auditijälg

Olulisem kontroll ei asu mudelis. See asub kihi vahel, mis ühendab kavatsuse ja täitmise.

Hea välimusega anti‑mustrid

Üks administraatori token iga agendi jaoks

See teeb prototüübi lihtsamaks. Hiljem muutub raske piirata vea mõju või tõestada, et agent peaks üldse ressursile ligi pääsema.

“Mudeli küsib kasutajalt, kas tegevus on riskantne”

See loovutab turbeotsuse samale komponendile, mille vigu kontroll peaks piirama.

Täieliku prompti ja vastuse logimine auditijäljena

Vestlus ei ole operatiivne auditirekord. See võib sisaldada ka teavet, mida ei tohiks logisüsteemi kopeerida.

Iga vea automaatne korduskatse

Mitte iga viga on mööduv. Mitte iga kirjutus ei ole idempotentne. Klassifitseerimata korduskatse võib kahju suurendada.

Universaalne lõpp‑punkt täieliku juurdepääsuga “tulevaste funktsioonide” jaoks

Kui üks lai tööriist suudab mööda minna kitsastest tööriistadest, on lai tööriist tegelik õiguste mudel.

MCP serveri ülevaatuse kontrollnimekiri

Enne tootmiskasutust kontrolliksin vähemalt järgmisi punkte:

  • Kas operaatori identiteet on teada iga kõne puhul?
  • Kas sihtsüsteemi volitused on mudelist varjatud?
  • Kas loetamise, kirjutamise, käivitamise ja destruktiivsete õiguste eraldamine on võimalik?
  • Kas autoriseerimine piirab ressursi/tenant’i/konto kõrval ka funktsiooni?
  • Kas puuduva parameetri korral jõutakse turvalisse olekusse?
  • Kas finants-, väline‑ ja destruktiivsed operatsioonid nõuavad eraldi heakskiitu?
  • Kas kirjutamise korduskatseid kontrollitakse?
  • Kas sihtressurss loetakse tagasi pärast kirjutamist?
  • Kas mis tahes madala taseme lüüs kasutab samu autoriseerimisreegleid?
  • Kas auditijälg välistab tokenid, saladused ja toor isikuandmed?
  • Kas suvalised failisüsteemi teed ja piiramata koormused lükatakse tagasi?
  • Kas agendi või operaatori juurdepääs saab keskelt tühistada?

MCP 2026-07-28 muudab protokolli, mitte rakenduskontrollide vajadust

MCP versioon 2026-07-28 tõi, muu hulgas, seisunditugeva protokollituuma ja täiendava autoriseerimise karmistamise. Need muudatused muudavad suhtluskihti skaleerimise ja mõistmise poolest lihtsamaks. Need ei määra äripoliitikat konkreetse juurutuse jaoks: kas agent võib kulutada 5 000 PLN, kustutada konto või saata sõnumit 10 000 inimesele.

Rakendus peab siiski seda otsust jõustama.

Kes vajab seda disainimustrit

Protsessi omanikud, arendajad ja turbeülevaatajad vajavad seda piiri. Tootmisagendid võivad koostada muudatusettepanekuid; kinnisvara‑haldusagendid võivad korraldada dokumente; B2B‑agendid võivad analüüsida pileteid. Elanike teavituste saatmine või kliendi õiguste muutmine nõuab tagajärgede kontrolli.

Ads MCP näide pärineb sisemisest tööriista disainidokumentatsioonist. See ei kirjeldanud kliendi reklaamikonto teenust ega sõltumatut auditit praeguse tootmiskeskkonna kohta.

Identiteet ja eraldatus vajavad rohkem kui kehtiv token

MCP autoriseerimine nõuab tokeneid, mis on mõeldud serveri enda ressursi jaoks. Kehtiv allkiri teise teenuse tokenil ei ole piisav. Kontrolli audience‑i, issuer‑i ja kehtivust. Lükka sobimatud tokenid täitmisele tagasi.

Samuti kontrolli ressursi juurdepääsu. Võrdle sisestatud tenant_id serveri määratud identiteediga, selle asemel et usaldada agendi identifikaatorit. Iga lugemis‑ ja kirjutamistoiming vajab ressursi autoriseerimist, kaasa arvatud manused, ekspordid ja taustatööd.

MCP 2026-07-28 ei sisalda protokollitaseme seansse. Rakendused võivad siiski säilitada olekut, näiteks muudatuse eelvaate käepidet. Omamine ei tohi asendada autentimist. Siduge käepidemed volitatud operaatoritega, kontrollige iga kasutust ja määrake aegumine. Varastatud käepide ei tohiks paljastada teise isiku töövoogu.

Sisu ja kommunikatsioonisihtkohtade valideerimine

Otsingutulemused, PDF‑id, e‑kirjad ja API‑vastused on analüüsimaterjal. Sisaldatud juhised saladuste hankimiseks või dokumentide saatmiseks mujale ei ole operaatori heakskiit. Prompt‑injektsiooni kaitsmiseks peab server lükkama tagasi volitamata ressursid, adressaadid ja operatsioonid isegi siis, kui tööriista argumendid on tehniliselt korrektsed.

Tööriistade puhul, mis aktsepteerivad URL‑e, määra lubatud sihtkohad ja ümbersuunamise käitumine. MCP juhised käsitlevad SSRF‑i OAuth‑metaandmete avastamisel. Hinnake sama probleemi kohandatud tõmbetööriistades. Avaliku lehe tõmbamise luba ei tohiks avada kohalikku haldusteenust ega pilve metaandmete lõpp‑punkti. Kaitse sõltub võrguarhitektuurist; üksik hostinimekiri ei pruugi kontrollida lõplikku ühenduse sihtkohta.

Failitööriistade puhul piirake katalooge ja koormuse suurust. Lükka tagasi teed, mis jäävad lubatud alast välja, tundmatud väljad ja liialt suured ekspordid. Selge viga on eelistatud vaikimisi laienemise ees.

Väike juurutusskenaario: teenuse‑piletite mustandid

Oletame, et ettevõte soovib vähendada varustuse rikkepiletite ettevalmistamise aega. Agent loeb heaks kiidetud käsiraamatut ja rikkete ajalugu, seejärel koostab mustandi. Selle saatmine tarnijale jääb eraldi toiminguks. See on disainstsenaarium, mitte väide, et Brillnet pakub praegu sellist funktsiooni.

Teenuse omanik valib ühe varustuse grupi ja määratleb oodatava väljundi: mustand, mis tuvastab varustuse, sümptomi, sündmuse aja ja puuduvad andmed. Arendaja avaldab kaks kitsast tööriista: heaks kiidetud dokumendi tõmbamine ja mustandi loomine määratud projektis. Esialgne versioon ei paku sõnumite saatmist ega varustuse konfiguratsiooni muutmist. Turbeülevaataja kontrollib andmeskoopi ja keskse juurdepääsu tühistamise võimalust.

Kontrolli ühte lubatud lugemist, katsetatud ristprojekti lugemist, dokumenti, mis sisaldab pahatahtlikke juhiseid, ja kirjutamise korduskatset pärast ajapiirangu ületamist. Väike tööriistakataloog on piisav alustamiseks. See peab jõustama need piirangud, mida disain lubab.

Kui hiljem lisatakse saatmine, peab heakskiit hõlmama adressaadi ja sisu. Saaja muutmine tühistab varasema heakskiidu. Kui pakkujal puudub idempotentsuse tugi, lahenda ebamäärane ajapiirangu ületamine, kontrollides, kas sõnum on juba olemas. Ära lihtsalt uuesti saada, sest agent ei saanud vastust.

Mida teha homme, koos omanikuga

Protsessi omanik valib ühe tegevuse ja selle lubatud tagajärje. Arendaja kaardistab tööriista, operatsiooni ja ressursi, sealhulgas laiemalt kättesaadava juurdepääsutee. Turbeülevaataja kontrollib, kus operaatori identiteet lõpeb, kus teenuseidentiteet algab ja kas mudel pääseb volitustele. Esimese päeva väljundiks peaks olema lühike kaart ja üks täide, mille tulemuslik olek on sihtsüsteemis kontrollitav.

Mõõda heaks kiidetud mustandi kvaliteeti, tagasilükkamisi ulatuse rikkumiste puhul ja inimeste ülevaatamise aega. Rohkem tööriistakõnesid ei tähenda automaatselt rohkem väärtust. Kui parandamine võtab kauem aega kui ettevalmistus säästab, kitsenda ülesannet enne täiendavate võimekuste lisamist.

Tehniline juhend ja õiguslikud kohustused

OWASP ja NIST pakuvad tehnilisi juhiseid. MCP spetsifikatsioon määratleb protokollinõuded. Need allikad ei määra iseseisvalt konkreetse ettevõtte õiguslikke kohustusi ega andmete säilitamise perioode. Määrake protsessile kohaldatavad sektori‑, lepingulised ja õiguslikud nõuded. See juhend selgitab kontrollide kujundamist ja ei anna mingit vastavussertifikaati.

Piir

Need on mustrid, mida kasutame oma töös. See lehekülg ei väida, et kogu tööriist on sertifitseeritud või universaalselt kooskõlas OWASP‑i, NIST‑i või kogu MCP‑spetsifikatsiooniga. Iga integratsioon vajab oma ohuanalüüsi ja turbeteste.

Kui soovite hinnata, kuidas Brillnet käsitleb juurdepääsu, andmeid ja AI‑d, vaadake Security ja Compliance and AI oversight.

Allikad

Tehnilised allikad toetavad esitatud põhimõtteid. Juurutusskenaarid ja tegevuskava on autori disainisoovitused.

Teadmised

Valdkonnajuhendid ja tehisintellektiagentide praktilised kontrollid.

Aruta oma protsessi →