Kā droši piešķirt AI aģentam piekļuvi biznesa datiem

Arhitektūra: aģents ir klients, sistēma ir autoritāte

Sāciet ar formu, jo lielākā daļa kļūdu ir formas kļūdas. Cilvēks lūdz savu aģentu kaut ko. Aģents izlemj, kuri rīki jāizmanto. Katrs izsaukums iziet cauri atļauju slānim, kas pieder uzņēmuma sistēmai, nevis aģentam, un tikai tad sasniedz tādu moduli kā finanses vai CRM. Aģents nekad nesaskaras ar datu bāzi, nekad neiztur datu bāzes akreditācijas datus un nekad neredz rīku, ko tā persona nevarētu izmantot.

Principa pamatā ir viena teikuma: aģents rīkojas ar tās personas pilnvarām, kuru tas pārstāv, un nekad vairāk. Viss pārējais šajā rakstā ir veids, kā padarīt šo teikumu patiesu spiediena apstākļos, kad modelis ir nepareizs, kad dokumentā, ko tas lasa, ir norādījumi, vai kad tokens noplūst.

OWASP Top 10 LLM lietojumprogrammām nosauc neveiksmi, ko šī arhitektūra novērš: pārmērīga aģentūra, ko tā sadala pārmērīgā funkcionalitātē (rīki, kas pārsniedz darba vajadzības), pārmērīgās atļaujās (vairāk piekļuves uz leju, nekā nepieciešams) un pārmērīgā autonomijā (nav neatkarīgas pārbaudes pirms augsta ietekmes darbības). Tās mazināšanas pasākumi izskatās kā specifikācija atļauju slānim: izpildīt lietotāja kontekstā, minimizēt rīkus un to atļaujas, īstenot autorizāciju lejupvērstajā sistēmā, nevis paļauties uz modeli, un prasīt personas apstiprinājumu augsta ietekmes darbībām.

Pieci kontroles punkti un kur katrs atrodas

Kontroles nav jaunas; tās ir kontroles, kuras jūs jau piemērojat personai ar sistēmas piekļuvi, piemērojot klientam, kas rīkojas šīs personas vārdā. Tabula norāda, ko katra atbild, kur tā tiek īstenota un kāda izskatās neveiksme, kad tās nav. Atrašanās vietas kolonna ir svarīgā. Kontrole, kas tiek īstenota uzdevumā, ir ieteikums.

Identitāte: pieslēdzieties kā persona, izmantojot OAuth, nekad ar kopīgu atslēgu

Modeļa konteksta protokola autorizācijas specifikācija ir precīza šajā jautājumā. Attālināts serveris darbojas kā OAuth 2.1 resursu serveris; klients iegūst tokenu, izmantojot standarta autorizācijas plūsmu ar PKCE; klientam jānorāda, kuram serverim tokena ir paredzēts, izmantojot resursa parametru; un serverim jāvalidē, ka katrs tokens tika izsniegts tieši tam, noraidot jebko citu. Specifikācija skaidri aizliedz tokenu pārsūtīšanu, kur serveris pieņem tokenu, ko tas nav izsniedzis, un nosūta to tālāk, jo tas iznīcina gan audita pēdas, gan uzticības robežu.

Praksē tas nozīmē to, ko nozīmē "pierakstieties vienreiz, nav nepieciešams ievadīt tokenu". Persona pievieno darba telpas adresi savam aģentam, tiek nosūtīta uz parasto pierakstīšanās lapu, apstiprina savienojumu, un aģents saņem tokenu, kas viņus identificē un darbojas tikai pret šo darba telpu. Anthropic vadlīnijas pielāgotajiem savienotājiem Claude ir pārskatīt servera pieprasītās jomas, ierobežot tās, kur iespējams, un savienoties tikai ar serveriem, kuriem uzticaties. Piegādātājs, kurš vietā tam lūdz ievadīt uzņēmuma API atslēgu aģenta konfigurācijā, ir izlaidis pirmo kontroli un padarījis pārējās četras daudz grūtākas.

Apjoms: filtrējiet pirms piedāvāšanas, pārbaudiet vēlreiz, kad izpildāt

Aģents atklāj, ko tas var darīt, jautājot serverim par tā rīku sarakstu. Pareizais dizains atbild uz šo jautājumu katrai personai: grāmatveža aģenta saņemtais saraksts atšķiras no direktora aģenta saņemtā saraksta, un neviens no tiem neietver rīkus moduļiem, kurus viņu loma nevar redzēt. Tas ir OWASP padoms, lai minimizētu funkcionalitāti, un tam ir otra priekšrocība: modelis, kuram nekad nav rādīts rīks, nevar tikt pārliecināts, ka tas to sauc.

Rīku saraksta filtrēšana pati par sevi nav pietiekama, jo lomas mainās, sesijas pastāv un klienti kešē. Tajā brīdī, kad katrs izsaukums ierodas, jāveic tāda pati pārbaude, ņemot vērā personas atļaujas. Zemāk ir rīku saraksts tādā formā, kādu definē protokols, loma, kas var lasīt rēķinus, bet nevar reģistrēt maksājumus. Trūkstošais rīks ir būtisks.

{
  "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.

Rīku/saraksta atbilde tādā formā, kādu definē MCP specifikācija, ar rīku nosaukumiem no Sois grāmatvedības moduļa. Specifikācija arī nosaka, ka klientiem jāuztver anotācijas, piemēram, readOnlyHint, kā neuzticamas, ja vien serveris nav uzticams, kas ir vēl viens iemesls, kāpēc serverim, nevis anotācijai, jābūt tam, kas izpilda noteikumu.

Promptu injekcija: dati var atbildēt

Drauds, kas ir specifiski aģentiem, ir tas, ka dati, ko tie lasa, var saturēt instrukcijas. E-pasts no klienta, kas beidzas ar rindu, kas norāda aģentam nosūtīt piegādātāju sarakstu uz ārēju adresi; dokuments, kas norāda, ka tam jāatzīmē katrs rēķins kā apmaksāts. Modelis var vai nevar ievērot, un neviena komanda nevar garantēt, ka tas tā nebūs, tāpēc komandu injekcija ir pirmā OWASP sarakstā un kāpēc gan Anthropic, gan OpenAI brīdina par to savās savienotāju vadlīnijās.

Aizsardzība ir arhitektūra, nevis modelis. Aģentam, kuram tiek piedāvāti tikai rīki, ko tā persona var izmantot, nav iespējas pārsūtīt to, ko viņa persona nevar redzēt. Izsaukums, lai atzīmētu rēķinus kā apmaksātus, tiek pārbaudīts sistēmā pret personas atļaujām, nevis pret modeļa uzskatu, ka tas tika lūgts. Sekundārie rīki tiek marķēti, lai klients vispirms jautātu personai: ChatGPT pašlaik prasa manuālu apstiprinājumu sarunā pirms rakstīšanas darbībām, un OpenAI vadlīnijas ir saglabāt apstiprinājumu rīkiem, kas modificē datus; Claude prasa apstiprinājumu katram rīkam un iesaka rezervēt "atļaut vienmēr" uzticamiem serveriem. Un žurnāls reģistrē mēģinājumu, tāpēc injekcija, kas tika bloķēta, ir redzama pēc tam, nevis klusējoša.

Budžets un žurnāli: padariet aģenta darbu pārskatāmu kā cilvēka darbu

Budžets ir svarīgs divu iemeslu dēļ. Acīmredzamais iemesls ir izmaksas: aģents, kuram ir piešķirts neskaidrs rezultāts, turpinās izsaukt rīkus, līdz kaut kas to aptur, un OWASP uzskaita neierobežotu patēriņu kā risku pats par sevi. Smalkākais iemesls ir sprādziena rādiuss: ierobežojums katrai integrācijai ierobežo to, cik daudz apdraudēts vai apjucis aģents var izdarīt, pirms persona to pamanīs. Ja personas aģents veic loģiku, AI izmaksas ir ar viņiem; ja sistēmas aģents to dara, ierobežojumam jābūt noteiktam katrai integrācijai un redzamam katrā darbībā.

Žurnāli pārvērš visu šo no solījuma par kaut ko, ko varat auditēt. Katram izsaukumam jāreģistrē, par kuru personu aģents rīkojās, kurš rīks, ievadi, rezultāts un laiks, tajā pašā vietā, kur sistēma reģistrē, ko cilvēki darīja. Tests ir, vai finanšu vadītājs var noskaidrot, ko aģents darīja ar klienta kontu pagājušajā mēnesī tikpat viegli, cik viņš var to izdarīt kolēģim. MCP specifikācija prasa klientiem reģistrēt rīku izmantošanu audita vajadzībām; biznesa sistēmai nevajadzētu paļauties uz klientu, jo klients nav ierakstu sistēma.

Kontrolsaraksts, ko varat izmantot pret jebkuru sistēmu

Nesiet šos jautājumus jebkuram piegādātājam, tostarp mums. Katram ir jā vai nē, un katram ir tests, nevis jautājums, ko uzdot.

1. Aģents pieslēdzas kā nosaukta persona, izmantojot OAuth, bez uzņēmuma līmeņa atslēgas, ko varētu ielīmēt. Tests: pieslēdzieties no ārēja MCP klienta un paskatieties, ko prasa pieteikšanās lapa.
2. Rīku saraksts atšķiras atkarībā no lomas. Tests: pieslēdzieties kā ierobežots lietotājs un kā administrators un salīdziniet, ko aģents piedāvā.
3. Pārbaude tiek atkārtota, kad rīks tiek palaists. Tests: noņemiet atļauju no pieslēgtā lietotāja sesijas vidū un mēģiniet rīcību vēlreiz.
4. Piekļuve tiek atteikta. Tests: izsauciet rīku, kas lomai nevajadzētu būt, un apstipriniet, ka saņemat atteikumu, nevis rezultātu.
5. Izdevumus var ierobežot katrai integrācijai un redzēt katrai rīcībai. Tests: iestatiet mazu ierobežojumu un skatieties, kā tas tiek piesaistīts.
6. Katra rīcība tiek reģistrēta pret personu, ar ievadiem un rezultātu, kur sistēma reģistrē visu pārējo. Tests: izlasiet žurnālu par skrējienu, ko tikko veicāt.
7. Sekas rīki ir atzīmēti apstiprināšanai tāpēc klients jautā personai. Tests: lūdziet aģentam nosūtīt naudu vai izdzēst ierakstu un apstipriniet, ka vispirms jums jautā.

Sois ir viens sistēma, kas izveidota, lai izpildītu šo sarakstu, un forma raksta augšdaļā ir tās forma. Darba vieta ir MCP serveris; jebkurš MCP klients pieslēdzas, pievienojot darba vietas adresi un reģistrējoties vienu reizi, izmantojot OAuth; rīki tiek filtrēti pēc lomas pirms to piedāvāšanas un vēlreiz pārbaudīti, kad tie darbojas; piekļuve tiek slēgta; izdevumi var tikt ierobežoti katrai integrācijai; katra darbība tiek reģistrēta; un tīkli, kas izveidoti uz platformas, ir ar savu datu bāzi, krātuvi, domēniem un atslēgām. Tomēr izpildiet kontrolsarakstu. Kontrolsaraksta vērtība ir tā, ka tā nepieņem neviena vārdu.

Cilvēki uzdod jautājumus

Šis raksts tiek pārskatīts, kad mainās tajā aprakstītie produkti. Nākamais plānotais pārskats: 2026. gada 4. decembris.