AgentCore saugumas su WAF: agentą saugoti reikia dar prieš pirmą klientą

AgentCore saugumas nėra dar viena graži DI etiketė. Po ja slepiasi paprastas klausimas: kur žmogui šiandien per daug rankinio darbo, per daug spėlionių arba per mažai laiko normaliai patikrai?

AWS paskelbė techninį vadovą, kaip saugoti Amazon Bedrock AgentCore Runtime su AWS WAF. Architektūroje naudojamas internet-facing Application Load Balancer, HTTPS, VPC Interface Endpoint per PrivateLink ir AgentCore Runtime.

Aš į tokias naujienas žiūriu per labai žemišką filtrą. Ne „kaip skamba pristatyme“, o „ką su tuo darytų komanda pirmadienį ryte“.

Kartais atsakymas mažas. Viena lentelė. Vienas procesas. Vienas patikrinimas prieš išsiunčiant klientui. Bet ten DI ir pradeda veikti ne kaip triukas, o kaip įrankis.

KAS NUTIKO

AWS aprašo du modelius. Pirmas naudoja ALB su Lambda proxy, kai reikia request transformacijų, autentifikacijos vertimo ar papildomo audito. Antras yra paprastesnis kelias su ALB į VPC Endpoint IP targetus, kai reikia mažesnio vėlavimo ir mažiau papildomų dalių. WAF prideda rate limiting, SQL injection, XSS filtravimą ir botų kontrolę.

Agentų tema dažnai prasideda nuo klausimo „ką jis moka?“ Man vis labiau norisi klausti kitaip: „kas jį saugo?“ Nes kuo agentas naudingesnis, tuo daugiau įrankių, duomenų ir veiksmų jis gali pasiekti.

KODĖL TAI SVARBU

Saugumas agentuose nėra priedas gale. Agentas gali kviesti API, skaityti dokumentus, veikti vartotojo vardu ir ilgiau išlaikyti kontekstą. Jei jo įėjimo durys plačios, problemos ateis greičiau nei ROI.

DI rinka dabar pilna pažadų. Agentai, modeliai, saugumas, atmintis, automatizavimas. Skamba rimtai. Bet viską galima nuleisti ant žemės: ar žmogus greičiau randa informaciją, priima geresnį sprendimą ir padaro mažiau klaidų?

Jei taip – verta tęsti. Jei ne – turime dar vieną demonstraciją, kuri graži iki pirmo realaus kliento, mokinio ar vadovo klausimo.

KĄ TAI REIŠKIA VERSLUI

Verslui ši naujiena aktuali net jei AWS nenaudojate. Principas universalus: agentas turi turėti vartus, ribojimus, autentifikaciją, stebėseną ir aiškų kelią, kaip tvarkomos atakos ar keistos užklausos.

• WAF prieš viešą endpointą
• privati jungtis iki agento runtime
• autentifikacijos modelis prieš diegimą
• atskiri logai saugumo peržiūrai

Prieš paleisdami agentą, padarykite paprastą lentelę: kas gali jį kviesti, kokiu kanalu, kokie limitai, kokie duomenys leidžiami, kas gauna alertą, jei prasideda keistas srautas.

KUR GALI PASLYSTI

Rizika – manyti, kad agentas yra tik chatbotas, todėl jam užtenka slaptažodžio. Jei agentas turi įrankius, jis jau yra sistemos dalis. O sistemos dalys turi būti saugomos kaip sistemos dalys.

DI klaida dažnai neatrodo kaip klaida. Ji ateina tvarkingu sakiniu, mandagiu tonu ir labai ramiu veidu. Todėl ribos, peržiūra ir logai nėra biurokratija. Tai darbo higiena.

KĄ PASIDARYTI ŠIĄ SAVAITĘ

Jei turite DI agento planą, pridėkite saugumo schemą prie produkto plano. Ne po paleidimo. Dabar.

Šaltinis: Amazon Web Services.

DUK

Ką aprašė AWS?

AWS aprašė, kaip AgentCore Runtime apsaugoti su AWS WAF, ALB ir PrivateLink.

Kam reikalingas WAF?

Jis padeda riboti srautą, filtruoti tipines web atakas ir pridėti papildomą apsaugos sluoksnį.

Kokia pagrindinė pamoka?

DI agentas turi būti saugomas kaip sistema, ne kaip paprastas pokalbių langas.

Jei norite DI naudoti praktiškai, pradėkite nuo vieno proceso. Ne nuo įrankių mugės. Paimkite konkretų darbą, išmatuokite dabartinį laiką, paleiskite mažą bandymą ir pažiūrėkite, ar žmogui tikrai palengvėjo. Daugiau praktinių DI taikymo pavyzdžių rasite MasterSprint.