Tietopankki
Tekoälyagenttien vähimmät käyttöoikeudet SaaS-palvelussa
Yleinen prototyyppipikavalinta on antaa agentille token, paljastaa kaikki työkalut ja rajoittaa käyttäytymistä promptilla. Tämä tekee demoista helpompia. Tuotannossa se aiheuttaa ongelman: promptissa kirjoitettu intentio on pääasiallinen este mallivirheen ja tilin täyden kyvykkyyden välillä.
Vähiten oikeudet -periaate agentille ei pääty “vain‑luku”‑rooliin. Vähintään meidän tulisi rajoittaa viisi asiaa: työkalut, toiminnan tyyppi, kohderessurssit, data ja käyttöoikeuden elinkaari/identiteetti.
1. Rajoita työkalukatalogia
Agentti, joka analysoi mainonnan suorituskykyä, ei tarvitse käyttäjähallintatoimintoja. Agentti, joka laatii vaatimustenmukaisuusraportin, ei tarvitse rajoittamatonta shell‑pääsyä. Agentti, joka järjestelee tiedostoja yhdessä hakemistossa, ei tarvitse koko tiedostojärjestelmää.
Mitä laajempi työkalukatalogi, sitä suurempi pinta‑ala:
- väärän työkalun valitsemiseen;
- prompt‑injektion aiheuttamaan ei‑toivottuun toimintaan;
- odottamattomiin työkaluyhdistelmiin;
- tahattomaan datavuotoon;
- konfiguraatiovirheisiin mallitasolla.
Ensimmäinen kysymys tulisi siis olla “mitä tämä API voi tehdä?” eikä:
mitkä kolme‑tai viisi toimintoa tämä agentti tarvitsee juuri tähän tehtävään?
Muut kaikki voidaan pitää piilossa.
2. Erota luku, kirjoitus, operatiivinen vaikutus ja tuhoaminen
“Pääsy kampanjoihin” on liian laaja.
Työkalujemme kannalta operaatiomalli on hyödyllisempi:
| Laajuus | Merkitys | Esimerkki |
|---|---|---|
read |
tilan ja raporttien haku | hae kulutus, tila tai resurssilista |
write |
konfiguraation valmistelu tai muokkaus | luo luonnos, nimeä uudelleen, muuta parametria |
operate |
aktivoi liiketoiminnallinen seuraus | ota kampanja käyttöön, julkaise, käynnistä synkronointi |
destructive |
poista, irrota tai peru | poista resurssi, poista pääsy, tee vaikeasti peruutettava muutos |
Agentti voi valmistella konfiguraation ilman oikeutta aktivoida sitä. Se voi lukea laskutusta ilman oikeutta muuttaa maksuasetuksia. Se voi laatia viestin ilman oikeutta lähettää sitä.
Tuo raja on usein se, missä hyödyllinen autonomia asuu.
3. Työkalun laajuus ei riitä – rajoita myös resurssi
Oikeus, kuten:
campaign.write
on edelleen laaja, jos operaattorilla on kymmenen tiliä, mutta agentin tulisi toimia vain yhdessä.
Missä mahdollista, valtuutus tulisi ottaa huomioon:
Valtuutuspäätös sisältää käyttäjän, agentin, funktion, toiminnan tyypin, tenantin/tilin/projektin, resurssin ja tehtäväkontekstin.
kuka
+ mikä agentti
+ mikä funktio
+ mikä toiminnan tyyppi
+ mikä tenant/tili/projekti
+ mikä resurssi
+ mikä tehtäväkonteksti
Sisäisessä Brillnet Ads MCP:ssä vaadimme eksplisiittisiä tili‑/asiakas‑tunnisteita sallitun rajan sisällä. Yleinen kysely ei saa arvata, mille tilille toimitaan.
Tämä on erityisen tärkeää monivuokraisissa SaaS‑ympäristöissä. Väärän tenantin valinta voi olla vakavampaa kuin malli‑päättelyn virhe itse.
4. Rajoita syötettävää ja tuotettua dataa
Vähiten oikeudet koskee myös dataa.
Agentti saattaa tarvita:
- aggregoitua kulutusta, ei koko käyttäjädatan listaa;
- tehtävän tilaa, ei kaikkia liitteitä;
- vahvistusta siitä, että tunniste on olemassa, ei sen arvoa;
- henkilötunnistetta, ei koko profiilia;
- valittuja asiakirjakenttiä, ei koko arkistoa.
Jos työkalu voi palauttaa minimikohteen, palauta minimikohde. Älä paljasta täydellistä tarjoajan payloadia mallille vain siksi, että API tekee sen mahdolliseksi.
Sama periaate pätee lokitukseen: audit‑trailin tulee sisältää riittävästi todistusaineistoa, ei kopioita kaikesta lähdedatasta.
Lisää: AI‑agenttien audit‑trailit
5. Tunniste ei saa elää pidempään tai laajemmin kuin tarpeen
Pitkäikäinen ylläpitäjän token, joka on sijoitettu jokaisen komponentin ympäristöön, on helppo asettaa. Se on myös vaikea rajoittaa turvallisesti.
Suosimme mallia, joka lähestyy näin:
- Agentti ei saa salaisuutta.
- Yhdyskäytävä tarkistaa identiteetin, laajuuden ja resurssin.
- Se saa lyhytikäisen tunnisteen.
- Se suorittaa yhden sallitun tarjoajakutsun.
- Salaisuus ei koskaan päädy mallin vastaukseen tai audit‑lokiin.
Dokumentaationsa mukaan sisäinen Ads MCP hakee lyhytikäisiä tarjoajatunnisteita kutsuaikaan. Tunnisteaineisto käsitellään mallikontekstin ulkopuolella eikä sitä kirjoiteta sovelluslokeihin.
Tarkista oikeus suorituksen aikana
Agentti voi olla aloittanut tehtävän, kun operaattorilla oli tietty rooli. Kymmenen minuuttia myöhemmin rooli on voitu peruuttaa. Pitkä työnkulku ei saa olettaa, että aloitushetken oikeus pätee koko istunnon ajan.
Materiaalisten operaatioiden osalta valtuutus tarkistetaan, kun työkalu suoritetaan.
Sama koskee hyväksyntää. Yhden toiminnon suostumus ei ole oikeus satunnaisiin myöhempiin toimintoihin.
Prompt ei ole ACL
Ohje, kuten:
voit vain lukea dataa etkä saa koskaan poistaa mitään
voi olla hyödyllinen käyttäytymissääntö. Se ei korvaa teknistä kontrollia, joka estää DELETE‑kutsun.
Jos malli pääsee käsiksi tuhoavaan työkaluun ja tunnisteeseen, joka sallii poistamisen, kyky on olemassa. Prompt vain pyytää mallia olemaan käyttämättä sitä.
Käytännöllinen erottelu on:
- prompt: mitä agentin tulisi tehdä;
- valtuutus/politiikka: mitä agentilla on lupa tehdä;
- tarjoaja/API‑rooli: mitä tekninen identiteetti voi tehdä tarjoajalla.
Turvallisin järjestely on, kun kaikki kolme kerrosta ovat linjassa, mutta mikään yksittäinen ei ole ainoa kontrolli.
Profiilit yhden super‑agentin sijaan
Sisäisessä mainostyökalussamme erottelemme luku‑/suunnittelukyvyt, kampanjanhallintakyvyt ja omistajatason pinnan harvinaisiin hallinnollisiin operaatioihin.
Nimet eivät ole tärkeitä. Tärkeintä on, että tavallinen analyysi ei pyöri jatkuvasti korkeimmalla oikeustasolla.
Vastaava malli muualla voisi olla:
| Profiili | Sallitut tehtävät | Lisäraja |
|---|---|---|
| research-agent | haku, luku, tiivistelmä | ei tilamuutoksia |
| operations-agent | luku, luo luonnos, päivitä hyväksyttyjä kenttiä | operatiivinen laajuus |
| admin workflow | hallinnollinen operaatio | erillinen kutsu, identiteetti/laajuus, pakollinen hyväksyntä, kapea aikaväli |
Yhden agentin kompromissi tai virhe ei automaattisesti anna pääsyä kaikkiin operaatioihin.
Rajoita tiedostojärjestelmää ja “universaaleja” työkaluja
Kaksi kategoriaa ansaitsee erityishuomiota.
Shell / komentojen suoritus
Rajoittamaton shell voi ohittaa suurimman osan huolellisesti suunnitellusta työkalumallista. Jos agentti voi suorittaa mitä tahansa komentoa laajasti oikeutettuna OS‑käyttäjänä, hienojakoiset laajuudet muualla tarjoavat vain vähän suojaa.
Tarkoitukseen rakennettuja työkaluja tai sallittuja komentoja rajoitetussa ympäristössä on yleensä helpompi perustella.
Tiedostojärjestelmä
Agentti, jonka täytyy kirjoittaa raportti hakemistoon /workspace/reports, ei tarvitse pääsyä /etc, operaattorin kotihakemistoon tai CI‑salaisuuksiin.
Sisäisessä Ads MCP:ssä tiedostotoiminnot on rajoitettu hyväksyttyihin palvelinpuolen sijainteihin tai rajattuihin payloadeihin. Satunnaisia järjestelmäpolkuja hylätään.
Alhaisen tason yhdyskäytäväkin tarvitsee laajuuksia
Joskus yleinen yhdyskäytävä on hyödyllinen uusille tarjoajapisteille ennen omistettuja työkaluja. Sen ei tule muuttua pakonikehittäjäksi.
Sen tulisi luokitella:
- HTTP‑menetelmä;
- päätepiste;
- resurssi;
- payload‑ominaisuudet;
- onko operaatio kirjoittava tai tuhoava.
Vasta sen jälkeen sen tulisi kartoittaa pyyntö vaadittuihin oikeuksiin.
Jos raw_request voi käyttää täyden pääsyn tokenia ilman politiikkatarkistuksia, se on käytännössä ylläpitäjän pääsy riippumatta siitä, kuinka tarkasti muut työkalut on rajoitettu.
Tilapäinen oikeuksien korotus korkean riskin toiminnoille
Sen sijaan, että laaja laajuus annettaisiin pysyvästi, järjestelmä voi käyttää hallittua korotusta:
- Agentti valmistaa operaatio;
- Yhdyskäytävä havaitsee, että korkeampaa oikeutta tarvitaan;
- Henkilö hyväksyy tarkat parametrit;
- Järjestelmä myöntää oikeuden vain kyseiseen operaatioon tai lyhyeksi ajaksi;
- Oikeus vanhenee suorituksen jälkeen;
- Audit‑trail tallentaa hyväksynnän ja tuloksen.
Tätä ei tarvita kaikissa tilanteissa. Kriittisissä operaatioissa se vähentää aikaa, jonka aikana laaja oikeus on voimassa.
Lue: Milloin AI‑agentti tarvitsee ihmisen hyväksynnän?
Kyvykkyyksien inventaariopohja
Ennen tuotantoa kirjaa raja‑alueet:
| Agentti / työnkulku | Työkalu | Operaatio | Resurssi | Data | Hyväksyntä | Tunniste | Audit |
|---|---|---|---|---|---|---|---|
| kampanjaraportointi | Ads report | read | tili A | mittarit ilman PII | ei | lyhytikäinen | kyllä |
| kampanjan valmistelu | campaign tool | write | tili A | konfiguraatio | ei/ehdollinen | lyhytikäinen | kyllä |
| kampanjan aktivointi | campaign operate | operate | kampanja X | budjetti + tila | kyllä | lyhytikäinen | kyllä |
| resurssin poisto | admin tool | destructive | tietty resurssi | minimi | kyllä | korotettu | kyllä |
Tämä on paljon hyödyllisempää kuin kirjoittaa “agentilla on pääsy Google Ads:iin”.
Anti‑patternit
Yksi API‑avain koko järjestelmälle
Roolien erottaminen on vaikeaa ja yhden työnkulun pääsyn peruutus hankalaa.
Sama työkalukatalogi kaikille agenteille
Laajin toiminto katalogissa tulee jokaisen agentin riskialueeksi.
“Vain‑luku” vain promptissa
Jos backend edelleen hyväksyy kirjoituksia, vain‑luku on pyyntö, ei kontrolli.
Automaattinen laajuuden laajentuminen 403‑virheen jälkeen
Puuttuva oikeus on syy pysähtyä ja tehdä päätös, ei “yritä uudelleen ylläpitäjänä”.
Tunnisteet mallikontekstissa
Mallilla ei tarvitse olla salaisuuden arvoa pyytääkseen luotettavaa yhdyskäytävää suorittamaan sallitun kutsun.
Vähiten oikeudet -tarkistuslista agentille
- Agentti näkee vain rooliinsa vaaditut työkalut.
- Luku ja kirjoitus on erotettu.
- Operatiivisen vaikutuksen aktivointi on eri laajuus kuin konfiguraation valmistelu.
- Tuhoavat toiminnot vaativat lisäesteen.
- Oikeus on rajoitettu tenanttiin/tiliin/projektiin/resurssiin.
- Epäselviä kohderessursseja ei arvata automaattisesti.
- Työkalut palauttavat vain välttämättömän datan.
- Tunnisteet pysyvät mallikontekstin ulkopuolella.
- Tokenit ovat lyhytikäisiä, missä mahdollista.
- Valtuutus tarkistetaan suorituksen aikana, ei vain istunnon alussa.
- Tiedostojärjestelmä‑ ja shell‑pääsy on rajoitettu tai korvattu tarkoitukseen rakennetuilla työkaluilla.
- Raaka‑yhdyskäytävä ei ohita politiikkaa.
- Oikeuksien korotus on eksplisiittinen ja auditoitavissa.
- Pääsy voidaan peruuttaa keskitetysti.
Työstetty esimerkki: laadunraportointi yhdelle tuotantolinjalle
Käsitellään ehdotettua työnkulkua, ei tässä raportoituja toteutuksia. Valmistaja haluaa aamunäytteen poikkeamien yhteenvetona linjalle L1. Agentti yhdistää määrät, tilat ja toimenpide‑aikataulut. Se ei päätä, julkaistaanko tuote. Laadunhallintapäällikkö omistaa prosessin; sovellus‑ylläpitäjä omistaa pääsyn konfiguraation.
Aloita oikeudella lukea L1‑tietueet, pois liitteet ja työntekijätiedot. Tallenna raportti sisäiseen hakemistoon. Älä anna toimintoja poikkeamien sulkemiseen, tarkastustulosten muuttamiseen tai asiakasviestien lähettämiseen pelkästään siksi, että sama API tukee niitä.
Jos tiimi myöhemmin tarvitsee korjaustoimenpiteitä, lisää oikeus luoda luonnos nimetylle tiimille. Luonnoksen luominen ei saa muuttaa tuotteen tilaa. Päivitä pääsytietovarasto ja tunnista, kuka käsittelee virheellisesti osoitetun tehtävän. Tässä esimerkissä käytetyt tunnisteet ovat suunnitteluperusteita, eivät Brillnet‑käyttöönoton tuloksia.
Mitä MCP‑valtuutus määrittelee
Tämä opas käyttää MCP‑spesifikaatiota versio 2026‑07‑28. Sen HTTP‑valtuutusmalli vaatii tarkistuksen, että käyttö‑token on myönnetty kohdepalvelimelle. Kelvollinen token toiselle palvelulle ei saa antaa MCP‑pääsyä. MCP‑turvallisuusohjeissa käsitellään myös asiakastokenien välittämistä alapuolisiin API:hin ilman asianmukaista validointia.
Tämä ei kuitenkaan määrittele, saako käyttäjä lukea asiakkaan B tietueen. Sovellus‑valtuutuksen on ratkaistava suhde identiteetin ja kohderessurssin välillä. OAuth‑scopeja ja tenant‑suodatusta koskevat eri osat rajasta. Molemmat ovat tärkeitä. Tarkista protokollat käytössä olevien asiakas‑ ja palvelinversioiden mukaan; “MCP‑yhteensopiva” itsessään kertoo vähän pääsyrajoituksista.
Vahvista sekä hylkäys että onnistuminen
Oikea raportti todistaa, että sallittu polku toimii. Se ei todista, että muut polut ovat suljettuja. Hyväksynnän aikana säilytä tulokset pienen joukon konkreettisille tarkistuksille:
- pyydä samaa objektityyppiä toisesta tenantista;
- kutsu kirjoitustoimintoa raportointiprofiilin kautta;
- suorita, kun operaattorin rooli on peruutettu;
- yritä käyttää tiedostoa raporttihakemiston ulkopuolelta;
- yritä samaa kiellettyä toimintoa yleisen yhdyskäytävän kautta.
Odota hylkäystä ilman tilamuutosta tai resurssidatan paljastamista. Kirjaa tarkistuksen tunniste, politiikkaversio ja tulos, pois lukien salaisuudet ja täyden asiakkaan tiedot. Nämä ovat ehdotettuja hyväksymistarkistuksia tälle työnkululle, eivät täydellistä turvallisuustestausohjelmaa.
Pidä omistaja oikeusmuutoksille
Pääsy kasvaa yleensä inkrementaalisesti: toinen liitin, yksi poikkeus, lisähakemisto. Kysy, suorittaako agentti edelleen samaa tehtävää. Liitin, joka mahdollistaa viestien lähettämisen, ei saa hiljaisesti laajentaa raportointiprofiilia.
Prosessin omistaja hyväksyy liiketoimintatarpeen. Ylläpitäjä provisionoi ja peruuttaa oikeudet. Turvallisuusomistaja tarkastelee poikkeuksia ja kiertoratoja. Pienessä yrityksessä yksi henkilö voi pitää useita rooleja, mutta päätökset tulee olla jäljitettävissä. Aseta tarkistusväli muutosten tiheyden ja mahdollisten seuraamusten perusteella. Poista asennusoikeudet, kun asennus on valmis.
Huomenna inventoi yksi agentti. Poista oikeus, jota sen tehtävä ei enää vaadi, ja vahvista hylkäys sallitun rajan ulkopuolella. Tämä tarjoaa hyödyllistä näyttöä ilman koko arkkitehtuurin korvaamista.
Todisteet ja rajoitukset
OWASP‑ohjeistus tukee rajoitettuja työkaluja ja valtuutustarkistuksia. NIST julkaisee turvallisuus‑kontrollikatalogin. Meidän luku/kirjoitus/operate/tuhoava‑malli ja työstetty esimerkki ovat insinööri‑suosituksia, eivät lainsäädäntöä tai vaatimustenmukaisuustodistusta. Määritä organisaatiosi velvoitteet erikseen. Sisäinen Ads MCP -dokumentaatio, versio 1.0, päivätty 28. heinäkuuta 2026, kuvaa viitatun kontrollisuunnitelman; se ei itsenäisesti todista tuotantokäyttöä asiakkaalle.
Rajaus
Vähiten oikeudet pienentävät virheen tai väärinkäytön maksimaalista vaikutusta. Ne eivät takaa, että sallittu operaatio on sisällöllisesti oikea. Siksi yhdistämme ne syötteen validointiin, korkean vaikutuksen toimien hyväksyntään ja audit‑trailiin.
Palaa turvallisten AI‑agenttien oppaaseen tai tutustu Brillnet Security.
Kaksi kuvitteellista organisaatiota, yksi rajattu tehtävä
Anna avustajalle erillisessä esittelyympäristössä lupa lukea yksi hyväksytty menettely kuvitteellisessa organisaatiossa A ja valmistella luonnos. Sulje pois hyväksyntä, julkaisu, lupamuutokset ja pääsy organisaatioon B. Täytäntöönpanopalvelu määrittää organisaation kontekstin todetun toimijan ja sallitun suhteen perusteella; pyynnön muuttunut tunniste ei ole valtuutus toisen organisaation tietojen käyttämiseen.
Testaa sallittu luku, poissuljettu hyväksyntä ja pyyntö organisaatiolle B. Kirjaa jokaisessa tapauksessa odotettu tulos ja tarkasta todellinen tulos. Kieltäytymistapauksissa on jätettävä kielletty tila ennalleen eikä palauteta toisen organisaation tietoja. Säilytä käytäntöversio ja vähimmäistapahtuman metatiedot, jotka tarvitaan tarkistuksen rekonstruoimiseen, mutta sulje pois kirjautumistiedot ja tarpeeton asiakirjasisältö.
Sisällytä synteettiseen lähteeseen vaaraton ohje, jossa pyydetään asiaankuulumatonta vientiä. Käsittele sitä asiakirjan sisältönä. Hyväksytyt tehtävät ja palvelimen käyttöoikeudet pysyvät sallitun toiminnan perustana. Tämä osoittaa, kuinka epäluotettavien ohjeiden käsittelyn ja käyttöoikeusvalvonnan on toimittava yhdessä ehdotetussa suunnittelussa.
Tallenna Pulsarissa vaatimus, riski, toiminta ja kuvitteelliset todisteet tarkastettavaksi. Tämä testaa, kuinka tiimisi dokumentoi ohjauksen. Se ei tarkoita, että julkinen Pulsar-kokeilu paljastaa MCP-yhdyskäytävän tai toteuttaa kaikki agentin käyttöoikeudet arkkitehtuurissasi. Tarkista 14 päivän kokeilujakso, vaadittu maksutapa ja peruutusehdot ja sovi tarvittaessa ulkoisesta integraatiosta erikseen.
Lähteet
- OWASP AI Agent Security Cheat Sheet. Accessed: 2026-10-02.
- OWASP Authorization Cheat Sheet. Accessed: 2026-10-02.
- Model Context Protocol — The 2026-07-28 Specification. Accessed: 2026-10-02. Lähteet tarkistettu: 2026-10-10.
- MCP — HTTP authorization specification, 2026-07-28 — Kuljetuslupa ja resursseihin sidotut tunnukset.
- MCP — security best practices — Integroinnin turvallisuus ja valtuutusrajat.
- NIST SP 800-53 Rev. 5 — Kulunvalvonta ja auditointi-valvontaperiaatteet.
- OWASP — LLM01 Prompt Injection — Epäluotettavat asiakirjaohjeet ja agenttiriskit.
- OWASP — Logging Cheat Sheet — Hyödyllisiä tapahtumatietoja ja poissuljettuja arkaluonteisia tietoja.
- Pulsar GRC — data-exchange scope — Julkisten integraatiovaatimusten raja.
- Julkaistu tuotevalikoima ja kokeiluehdot — Julkaistu tuotevalikoima ja kokeiluehdot.
Tarkista ehdot ja aloita 14 päivän kokeilu
Tarkastele tekoälytoimintoa: valtuutus, tulos ja vahvistettu tila
Elintarviketuotannon CAPA: poikkeamasta vaikuttavuuden arviointiin