Kuinka antaa AI-agentille pääsy liiketoimintatietoihin turvallisesti

Arkkitehtuuri: agentti on asiakas, järjestelmä on valtuus

Aloita muodosta, koska suurin osa virheistä on muotoon liittyviä virheitä. Henkilö pyytää agentiltaan jotakin. Agentti päättää, mitä työkaluja kutsua. Jokainen kutsu kulkee liiketoimintajärjestelmälle kuuluvan käyttöoikeuskerroksen läpi, ei agentille, ja vain sitten se saavuttaa moduulin, kuten talous tai CRM. Agentti ei koskaan kosketa tietokantaa, ei koskaan pidä tietokannan käyttöoikeustietoja, eikä koskaan näe työkalua, jota sen henkilö ei voisi käyttää.

Kuvan alla oleva periaate on yksi lause: agentti toimii sen henkilön valtuudella, jota se edustaa, eikä koskaan enempää. Kaikki muu tässä artikkelissa on tapa tehdä tuosta lauseesta totta paineen alla, kun malli on väärässä, kun asiakirja, jota se lukee, sisältää ohjeita tai kun token vuotaa.

OWASP Top 10 LLM-sovelluksille nimeää epäonnistumisen, jonka tämä arkkitehtuuri estää: liiallinen valtuutus, joka jakautuu liialliseen toiminnallisuuteen (työkalut, joita työ ei tarvitse), liiallisiin käyttöoikeuksiin (enemmän pääsyä alavirtaan kuin tarpeen) ja liialliseen autonomiaan (ei itsenäistä tarkistusta ennen suurivaikutteista toimintoa). Sen lieventämiset luetaan käyttöoikeuskerroksen spesifikaatioksi: suorita käyttäjän kontekstissa, minimoi työkalut ja niiden käyttöoikeudet, valvo valtuutusta alavirran järjestelmässä sen sijaan, että luotettaisiin malliin, ja vaadi henkilön hyväksyntä suurivaikutteisille toiminnoille.

Viisi kontrollia ja missä kukin sijaitsee

Kontrollit eivät ole uusia; ne ovat kontrollit, joita jo sovellat henkilöön, jolla on järjestelmäpääsy, sovellettuna asiakkaaseen, joka toimii kyseisen henkilön puolesta. Taulukko kertoo, mitä kukin vastaa, missä se on voimassa ja miltä epäonnistuminen näyttää, kun se puuttuu. Sijaintisarakkeessa on tärkeä osa. Kehotteessa voimassa oleva kontrolli on ehdotus.

Henkilöllisyys: yhdistä henkilönä, OAuthin kautta, ei koskaan jaetulla avaimella

Mallin kontekstiprotokollan valtuutusmäärittely on tarkka tämän suhteen. Etäpalvelin toimii OAuth 2.1 -resurssipalvelimena; asiakas saa tokenin standardin valtuutusprosessin kautta PKCE:llä; asiakkaan on ilmoitettava, mihin palvelimeen token on tarkoitettu resurssiparametrin avulla; ja palvelimen on vahvistettava, että jokainen token on myönnetty nimenomaan sille, hyläten kaikki muut. Määrittely kieltää nimenomaisesti tokenin siirtämisen, jossa palvelin hyväksyy tokenin, jota se ei ole myöntänyt, ja välittää sen eteenpäin, koska se tuhoaa sekä tarkastuspolun että luottamuksen rajan.

Käytännössä tämä tarkoittaa, että "kirjaudu sisään kerran, ei liitettävää tokenia". Henkilö lisää työtilan osoitteen agenttiinsa, siirtyy normaalille kirjautumissivulle, hyväksyy yhteyden ja agentti saa tokenin, joka nimeää heidät ja toimii vain kyseisessä työtilassa. Anthropicin ohjeet mukautetuille liittimille Claude:ssa ovat tarkistaa palvelimen pyytämät laajuudet, rajoittaa niitä mahdollisuuksien mukaan ja yhdistää vain luotettaviin palvelimiin. Myyjä, joka sen sijaan pyytää sinua liittämään yrityksen laajuisen API-avaimen agentin kokoonpanoon, on ohittanut ensimmäisen valvonnan ja tehnyt muut neljä paljon vaikeammiksi.

Laajuus: suodata ennen tarjoamista, tarkista uudelleen käytön aikana

Agentti selvittää, mitä se voi tehdä kysymällä palvelimelta työkalulistaa. Oikea suunnittelu vastaa tähän kysymykseen henkilön mukaan: kirjanpitäjän agentti saa erilaisen listan kuin johtajan agentti, eikä kumpikaan sisällä työkaluja moduuleille, joita heidän roolinsa ei voi nähdä. Tämä on OWASP:n neuvo toiminnallisuuden minimoinnista käytännössä, ja sillä on toinen etu: mallia, jolle ei koskaan näytetä työkalua, ei voida väittää kutsuvan sitä.

Listan suodattaminen ei riitä yksinään, koska roolit muuttuvat, istunnot jatkuvat ja asiakkaat välimuistittavat. Sama tarkistus on suoritettava uudelleen, kun jokainen kutsu saapuu, henkilön oikeuksia vastaan tuona hetkenä. Alla on työkalulista protokollan määrittelemässä muodossa, roolille, joka voi lukea laskuja mutta ei kirjata maksuja. Poissa oleva työkalu on se, mikä on tärkeää.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      { "name": "searchInvoices",
        "description": "Search invoices by number, reference, contact, amount, status, date range.",
        "inputSchema": { "type": "object", "properties": { "query": { "type": "string" }, "outstanding_only": { "type": "boolean" } } },
        "annotations": { "readOnlyHint": true } },
      { "name": "getInvoice",
        "description": "Read one invoice in full: status, totals, dates, contact and lines.",
        "inputSchema": { "type": "object", "properties": { "invoice_id": { "type": "string" } }, "required": ["invoice_id"] },
        "annotations": { "readOnlyHint": true } }
    ]
  }
}

// recordPayment, sendInvoiceReminders and deleteInvoice exist in the system.
// They are not in this list because this person's role cannot use them.
// If the agent calls one anyway, the server answers with a permission error.

Työkalujen/listan vastaus MCP-määrittelyn mukaisessa muodossa, Sois-tilinpidon moduulin työkalujen nimillä. Määrittelyssä sanotaan myös, että asiakkaiden on käsiteltävä merkintöjä, kuten readOnlyHint, epäluotettavina, ellei palvelin ole luotettava, mikä on yksi syy lisää siihen, että palvelimen, ei merkinnän, on oltava se, joka valvoo sääntöä.

Prompt-injektio: tiedot voivat vastata

Agentteihin liittyvä uhka on se, että lukemansa tiedot voivat sisältää ohjeita. Sähköposti asiakkaalta, joka päättyy lauseeseen, joka käskee agenttia välittämään toimittajalistan ulkoiseen osoitteeseen; asiakirja, joka käskee merkitsemään jokaisen laskun maksetuksi. Malli voi noudattaa tai olla noudattamatta, eikä mikään kehotus voi taata, että se ei niin tee, minkä vuoksi kehotusinjektio on ensimmäisenä OWASP-listalla ja miksi sekä Anthropic että OpenAI varoittavat siitä liitinohjeissaan.

Puolustus on arkkitehtuuri, ei malli. Agentille, jolle tarjotaan vain työkaluja, joita hänen henkilönsä voi käyttää, ei voi välittää sellaista, mitä hänen henkilönsä ei voi nähdä. Kutsu merkitä laskut maksetuiksi tarkistetaan järjestelmässä henkilön oikeuksia vastaan, ei mallin uskomusta, että sitä pyydettiin. Seuraamustyökalut merkitään siten, että asiakas kysyy ensin henkilöltä: ChatGPT vaatii tällä hetkellä manuaalista vahvistusta keskustelussa ennen kirjoitustoimia, ja OpenAI:n ohje on pitää hyväksyntä päällä työkaluissa, jotka muokkaavat tietoja; Claude pyytää hyväksyntää työkalukohtaisesti ja neuvoo varaamaan "salli aina" luotettaville palvelimille. Ja loki tallentaa yrityksen, joten estetty injektio on näkyvissä jälkeenpäin eikä hiljaa.

Budjetti ja lokit: tee agentin työ tarkastettavaksi kuin henkilön

Budjetilla on merkitystä kahdesta syystä. Ilmeinen syy on kustannus: epämääräisen tuloksen saanut agentti jatkaa työkalujen kutsumista, kunnes jokin pysäyttää sen, ja OWASP listaa rajattoman kulutuksen omaksi riskikseen. Hienovaraisempi syy on räjähdysalue: integraatiokohtainen yläraja rajoittaa, kuinka paljon vaarantunut tai hämmentynyt agentti voi tehdä ennen kuin henkilö huomaa. Kun henkilön oma agentti tekee päättelyä, AI-kustannus on heidän kanssaan; kun järjestelmän oma agentti tekee sen, yläraja tulisi asettaa integraatiokohtaisesti ja näkyä toimenpiteittäin.

Lokit muuttavat kaiken tämän lupauksen auditoitavaksi asiaksi. Jokaisen kutsun tulisi tallentaa, kenen puolesta agentti toimi, mikä työkalu, syötteet, tulos ja aika, samassa paikassa, jossa järjestelmä tallentaa, mitä ihmiset tekivät. Testi on, voiko talousjohtaja selvittää, mitä agentti teki asiakkaan tilille viime kuussa yhtä helposti kuin kollegalle. MCP-määrittely pyytää asiakkaita kirjaamaan työkalujen käytön auditointia varten; liiketoimintajärjestelmän ei tulisi luottaa asiakkaaseen tässä asiassa, koska asiakas ei ole rekisterijärjestelmä.

Tarkistuslista, jota voit käyttää minkä tahansa järjestelmän kanssa.

Vie nämä mihin tahansa myyjään, mukaan lukien meihin. Jokainen on kyllä tai ei, ja jokaisella on testi kysymyksen sijaan.

1. Agentti yhdistää nimettynä henkilönä OAuth:n kautta.ei yrityskohtaisia avaimia liitettäväksi. Testi: yhdistä ulkoisesta MCP-asiakkaasta ja katso, mitä kirjautumissivulla kysytään.
2. Työkalulista vaihtelee roolin mukaan. Testi: yhdistä rajoitetun käyttäjänä ja järjestelmänvalvojana ja vertaa, mitä agentille tarjotaan.
3. Tarkistus toistuu, kun työkalu käynnistetään. Testi: poista lupa yhdistetystä käyttäjästä kesken istunnon ja yritä toimintoa uudelleen.
4. Pääsy epäonnistuu suljettuna. Testi: kutsu työkalua, jota roolilla ei pitäisi olla, ja varmista, että saat kieltävän vastauksen, ei tulosta.
5. Kulut voidaan rajoittaa per integraatio ja nähtävissä per toiminto. Testi: aseta pieni raja ja katso, kuinka se sitoutuu.
6. Jokainen toiminto kirjataan henkilön mukaan, syötteiden ja tuloksen kanssa, jossa järjestelmä kirjaa kaiken muun. Testi: lue loki juuri suorittamastasi ajosta.
7. Seuraamustyökalut merkitään vahvistusta varten asiakas kysyy henkilöltä. Testi: pyydä agenttia lähettämään rahaa tai poistamaan tietue ja varmista, että sinulta kysytään ensin.

Sois on yksi järjestelmä, joka on rakennettu tämän luettelon läpiviemiseksi, ja artikkelin yläosassa oleva muoto on sen muoto. Työtila on MCP-palvelin; mikä tahansa MCP-asiakas yhdistää lisäämällä työtilan osoitteen ja kirjautumalla sisään kerran OAuthin kautta; työkalut suodatetaan roolin mukaan ennen kuin ne tarjotaan ja tarkistetaan uudelleen, kun ne toimivat; pääsy epäonnistuu suljetusti; kulut voidaan rajoittaa integraatiokohtaisesti; jokainen toiminto kirjataan; ja alustalle rakennetut verkot omaavat oman tietokannan, tallennustilan, verkkotunnukset ja avaimet. Suorita tarkistuslista sen mukaan kuitenkin. Tarkistuslistan arvo on, että se ei perustu kenenkään sanaan.

Kysymyksiä, joita ihmiset kysyvät

Tätä artikkelia tarkastellaan, kun sen kuvaamat tuotteet muuttuvat. Seuraava tarkastusaika: 4. joulukuuta 2026.