AI-агент со root API-клуч: една погодена инструкција станува целосен пристап

|Автор: Уредувачки тим на QUASA|5 мин. читање
AI-агент со root API-клуч: една погодена инструкција станува целосен пристап

Кога AI-агент користи root API-клуч со широки овластувања, една злонамерна инструкција во датотека или одговор од алатка може да го наведе да дејствува во целиот опсег што го дозволува клучот. Тоа е причинско сценарио, а не неизбежен исход од секоја инструкција: агентот мора да ја прифати и да има алатка преку која може да постапи. Водичот на OWASP за AI-агенти ги опишува инјектирањето инструкции, злоупотребата на алатки, ескалацијата на привилегии и извлекувањето податоци како поврзани ризици.

За агент што користи API, датотеки и деловни системи, поставете посебен услужен идентитет, права само за задачата, краткотрајни акредитиви и листа на дозволени алатки. Агентот нека предлага дејства; посебна извршна компонента нека ги проверува идентитетот, ресурсот, параметрите и потребното човечко одобрување пред повикот да стигне до системот. Така границата на пристап не зависи од тоа дали моделот правилно препознал злонамерен текст.

Почнете со задача чиј опсег можете да го запишете

За пилот изберете повторлива задача со мал ризик, како читање несензитивни извештаи од однапред определена папка и подготовка на нацрт-резиме. Британскиот NCSC препорачува тесно ограничени пилоти, задачи со мал ризик и примена на постојните сајбер-контроли од почетокот. Пред поврзување со вистински податоци, определете ги дозволениот влез, очекуваниот излез, сопственикот на системот и условите за запирање.

Во овој пример агентот нема причина да испраќа пораки, да менува записи или да отвора други папки. Овие дејства треба да бидат недостапни во интеграцијата, а не само забранети во текстуалните инструкции. Ако задачата подоцна бара испраќање резултат или читање дополнителен ресурс, третирајте го тоа како ново барање за пристап и проверете го одделно.

Одвојте го идентитетот од широкиот клуч

Создајте посебен услужен идентитет за агентот или за јасно одвоен работен тек. Доделете му читање само на потребните ресурси, со можност пристапот да се повлече без да се нарушат сметките на вработените. Заедничкиот водич на националните сајбер-агенции препорачува посебен идентитет за секој агент, најтесен потребен опсег на привилегии, проверка на идентитетот при API-повици и акредитиви издадени непосредно пред привилегирано дејство.

Нека системот за идентитет издава токен за конкретната задача со ограничено времетраење. Токенот и трајните тајни чувајте ги надвор од инструкциите, контекстот што го чита моделот и одговорите на алатките. Ако деловниот API прифаќа само статичен клуч со широки права, посреднички сервис може да го чува клучот и да изложува само потребни операции; агентот тогаш нема директен пат до целосниот API. Посредникот мора повторно да ги проверува идентитетот, ресурсот и дозволеното дејство при секој повик.

Ограничете ги алатките и нивните параметри

За секоја задача направете листа на дозволени алатки. Во пилотот со резиме тоа би биле пребарување и читање во определена папка, без запишување, бришење, произволни веб-барања или извршување команди. Проверката треба да ги опфати и параметрите: дали патеката останува во дозволениот простор, дали идентификаторот припаѓа на дозволен ресурс и дали обемот на резултатот е соодветен на задачата.

Документ, е-пошта и надворешен API-одговор се податоци што агентот може да ги обработи, но не и извор на овластување. Условен пример е извештај што содржи наредба да се испрати друга датотека на надворешна адреса. Моделот може да предложи таков повик; извршната компонента треба да го одбие бидејќи испраќањето не е дозволена алатка за задачата. Проверката важи и кога предлогот звучи уверливо или се претставува како администраторска инструкција.

Врзете го одобрувањето за точното дејство

Однапред определете кои дејства може да се извршат автоматски и кои чекаат човек. Читање во дозволениот опсег може да биде автоматско. Испраќање податоци надвор од организацијата, промена на финансиски или кориснички записи, бришење, промена на права и објавување во продукција треба да бараат потврда од овластено лице. Правилото за одобрување го задава системот, а не агентот чиј предлог се оценува.

На лицето што одобрува прикажете му ја операцијата со точниот примател или ресурс и со параметрите што ќе се извршат. Потврдата нека важи само за таа верзија на дејството и нека истече по краток рок; сменета адреса, износ или датотека бара нова потврда. Ако проверката на правилата, потврдата или евидентирањето не работи, чувствителното дејство треба да запре. Така едно општо „одобри“ не станува дозвола за идни, изменети барања.

Логирајте ги одлуките и подгответе запирање

За секој повик бележете ги идентитетот на агентот, задачата, алатката, целниот ресурс, применетото правило, одлуката и исходот. За дејство со човечка потврда зачувајте кој одобрил, за што важела потврдата и кога истекла. Евиденцијата треба да овозможи реконструкција на дејството, без во неа да влегуваат тајни, цели токени или непотребни лични податоци.

Поставете известување за повторени одбиени повици, обиди за читање надвор од дозволениот опсег и неочекувана употреба на алатка. Определете кој го прима известувањето и кој може да го запре агентот, да го исклучи неговиот идентитет и да ги повлече активните токени. Следете ги и промените во правата на услужниот идентитет: ново наследено овластување го менува опсегот на пилотот дури и кога инструкциите на агентот останале исти.

Тестирајте ги забраните пред проширување

Подгответе пробни документи и одговори од алатки со јасно означени злонамерни инструкции. Еден нека бара читање друга папка, друг испраќање податок, а трет нека се претставува како администраторска наредба. За секој случај однапред запишете го очекуваниот исход: недозволениот повик е одбиен од извршната компонента, причината е забележана и на агентот не му се издава поширок токен.

Проверете и дали истечена потврда може повторно да се употреби, дали изменети параметри бараат ново одобрување и дали недостапната услуга за правила го запира чувствителното дејство. Повторете ги пробите по промена на моделот, инструкциите, алатките, правилата или изворите на податоци. Проширувањето има основа кога тимот може да покаже дека забраните навистина се спроведуваат, секоја извршена операција може да се проследи и пристапот може брзо да се повлече.

Сподели:

Претплатете се на нашиот билтен

Добивајте ги најновите вести за Web3, AI и крипто директно во вашето сандаче.

0