Защита на извикванията на инструменти в AI чатбот: Права, потвърждение и план за възстановяване

Уебсайт чатботът се променя фундаментално, когато не само отговаря, но му е позволено да задейства действия. Запитването за свободен час за среща все още е лесно управляемо. Отмяната на час, промяната на адрес или възстановяването на сума обаче променят реалното бизнес състояние. Езиковият модел може да предложи подходящо извикване на инструмент. Дали обаче действието е допустимо, трябва да се реши от отделен, детерминиран слой на приложението. Затова сигурните извиквания на инструменти (tool calls) в AI чатбот не се постигат чрез изключително строг системни промпт (system prompt), а чрез ограничени функции, проверка на правата от страна на сървъра, ясно потвърждение и контролиран път за изпълнение.

Защо добрият езиков модел не замества авторизацията

Всеки модел работи с вероятности. Той може да разбере погрешно намерението, да добави параметър или да реагира на манипулирано съдържание. Описанието на риска от OWASP относно Excessive Agency посочва три типични причини: прекалено много функционалност, прекалено широки права и прекалено голяма автономия. Затова проблемът не е само злонамерен вход (input). Дори двусмислено запитване или правдоподобно изглеждаща грешка в модела може да подготви нежелано действие.

Най-важното архитектурно правило гласи: Моделът формулира предложение, но приложението го авторизира и изпълнява. Извикването на инструмент като cancelAppointment първоначално е само структурирано намерение. Едва проверката на политиките (policy check) проверява потребителя, тенанта (tenant), обекта, позволеното действие, текущото състояние и необходимото потвърждение. Това разделение допълва защитата срещу Prompt Injection при уебсайт чатботове; то остава необходимо дори когато не е засечена атака.

Класифицирайте всеки инструмент според въздействието, а не според името

Екипите не трябва да класифицират общо целия чатбот като „сигурен“ или „критичен“. От решаващо значение е въздействието на всеки отделен инструмент. Проста матрица на риска осигурява яснота:

• За четене и слабо чувствителни: Извличане на работно време или публично достъпна информация за продукти.
• За четене и съдържащи лични данни: Показване на статус на поръчка или клиентски данни; за това трябва да се проверят самоличността, тенантът и връзката с обекта.
• За писане, но лесно обратими: Създаване на вътрешна заявка за обратно обаждане или добавяне на необвързваща бележка.
• С сериозни последствия или трудно обратими: Отмяна на резервация, промяна на данни за контакт, публикуване на съдържание, изпращане на съобщения или иницииране на плащания.

От този клас произтичат правата, нивото на потвърждение, лимитите и логването. Общото одобрение „Чатботът може да използва CRM системата“ е твърде грубо. По-добре е да се използва списък с конкретни възможности с дефинирани параметри и позволени преходи между състоянията.

Минималните привилегии (Least Privilege) започват с определянето на функциите

Наръчникът OWASP Authorization Cheat Sheet препоръчва най-малко привилегии (Least Privilege) и отказ по подразбиране (Deny by Default). За извикването на инструменти това означава: Чатботът получава само функцията и частта от данните, които са необходими за съответната стъпка.

Малки инструменти вместо универсални интерфейси

Инструментът getOrderStatus(orderId) се защитава по-лесно от отворен достъп до базата данни. Инструментът requestCallback(topic, timeWindow) е по-контролируем от обща функция за изпращане на произволни съобщения. Свободните SQL, Shell, URL или имейл функции ненужно увеличават потенциалното въздействие. Тестовите инструменти, които вече не са необходими, също трябва да премахнат от продуктивния каталог.

Изпълнение в контекста на влезлия потребител

Бекендът не трябва да се доверява сляпо на това, че моделът подава правилния клиентски ID. Той трябва да извлече текущия потребител и тенант от надеждната сесия и отново да провери за всеки обект дали съществува достъп. Практическата разлика между публичен чат и защитена зона е обяснена подробно в статията за идентичност и достъп до данни в клиентския портал. Общият сервизен акаунт с пълен достъп обикновено е погрешен пряк път за действия, свързани с потребителя.

Детерминирана валидация на параметрите

Параметрите на инструмента се нуждаят от строга схема: позволени полета, типове, дължини, диапазони от стойности и правила за състоянието. ID на срещата трябва да принадлежи на потребителя, датата трябва да е в допустим диапазон, а действието трябва да съответства на текущия статус. Неизвестните полета се отхвърлят. Приложението трябва също така да гарантира, че самото име на инструмента идва от фиксиран списък с позволени стойности (allowlist), а не се изпълнява от свободно генериран текст.

Потвърждението трябва да показва реалното действие

При промени със сериозни последствия въпросът „Сигурни ли сте?“ не е достатъчен. Наръчникът OWASP Transaction Authorization Cheat Sheet описва принципа „What You See Is What You Sign“ (Виждаш това, което подписваш): Потребителите трябва да могат да видят и потвърдят съществените данни за конкретното действие. За уебсайт чатбот това означава например:

• „Отмяна на срещата на 18 август в 14:30 ч.“ вместо „Потвърдете промяната“
• „Промяна на адреса за доставка за поръчка ...84 на Виена“ вместо „Запазване на данните“
• „Създаване на заявка за обратно обаждане с тема Фактура“ вместо „Изпращане на заявка“

Потвърждението се обвързва от страна на сървъра точно с този проект на действие. Ако целта, сумата, датата, получателят или други съществени параметри се променят, то става невалидно. То получава кратък срок на валидност и не може да се използва повторно за второ действие. За особено критични процеси може допълнително да се изисква повторно влизане или одобрение от човек. Моделът не трябва нито да прескочи тази стъпка, нито да я замени с успокояващо формулиран отговор.

Планиране на идемпотентност, лимити и възможност за възстановяване

Дори правилно авторизирано извикване на инструмент може технически да пристигне дублирано: Браузърът повтори заявка, изтичането на времето (timeout) задейства нов опит (retry) или потребителят изпрати същото съобщение отново. Затова инструментите за писане трябва да използват ID за идемпотентност от страна на сървъра. За едно и също ID същото действие се изпълнява най-много веднъж; повторният опит получава вече известния резултат.

Освен това всеки инструмент се нуждае от подходящи ограничения: максимален брой извиквания на сесия, кратки таймаути, ограничени повторни опити и прекъсване при необичайни вериги. Преди изпълнение бекендът проверява състоянието още веднъж. Така например вече отменена резервация няма да бъде обработена втори път. Където е възможно, действието първо трябва да се създаде като чернова или планирана поръчка. За неизбежните директни промени трябва да е ясно как те се компенсират, отменят или предават на екипа за поддръжка. Подготвеният Degraded Mode и план за възстановяване предотвратява необходимостта от импровизация в случай на инцидент.

Логване без събиране на тайни

Протоколът за сигурност трябва да може да отговори на въпроса кой, кое действие, на какво основание е одобрил и с какъв резултат го е изпълнил. Полезните данни включват псевдонимизиран ID на субекта, инструмент и версия, референция към обекта, версия на политиката, решение за авторизация, ID на потвърждението, ID на идемпотентността, време и резултат. Пароли, токени, пълни чат истории и ненужни лични данни нямат място в този лог.

Наръчникът OWASP AI Agent Security Cheat Sheet препоръчва структурирани данни за решения за високорискови действия и разделение между решение и изпълнение. Това е различно от пълното техническо проследяване (tracing): За проверката на сигурността е важно краткото, надеждно доказателство за веригата от одобрения. Съхранението и достъпът трябва да са съобразени с действителните нужди от проверка.

Здрава архитектура в пет слоя

1. Диалог и предложение: Моделът разпознава намерението и генерира структуриран проект за действие, но не изпълнява нищо директно.
2. Решение за политика (Policy Decision): Детерминиран компонент проверява списъка с позволени инструменти (allowlist), потребителя, тенанта, обекта, параметрите, класа на риска и лимитите.
3. Потвърждение: Интерфейсът показва съществените данни за действието. Одобрението е краткотрайно и обвързано с непроменения проект.
4. Изпълнение: Строго ограничен изпълнител (executor) проверява отново авторизацията непосредствено преди извикването и използва ID за идемпотентност.
5. Доказателство и реакция: Резултатът, грешките и веригата от одобрения се логват пестеливо; алармирането, компенсацията и прехвърлянето към човек са дефинирани.

Рамката NIST AI RMF Core категоризира тези задачи в Управление (Govern), Картографиране (Map), Измерване (Measure) и Управление на риска (Manage). На практика това означава: определяне на отговорностите и границите на риска, разбиране на контекста на използване, тестване на контролите и реакция на наблюдаваните отклонения.

Матрица за тестване преди пускане в реална среда

Само позитивните тестове не са достатъчни. Един инструмент трябва да спира безопасно дори при неблагоприятни условия. Най-малко следните случаи трябва да бъдат включени в повторяема матрица за тестване:

• Невлязъл или неоторизиран потребител изисква действието.
• Валидна сесия се отнася до обект на друг тенант.
• Съществени параметри се променят след потвърждението.
• Идентичната заявка се повтаря поради таймаут или двоен клик.
• Инструментът връща манипулирани инструкции или неочаквани допълнителни полета.
• Извикването надвишава лимитите за време, количество или разходи.
• Целевата система отпада между проверката и изпълнението.
• Правата се отнемат малко преди изпълнението.

Очакват се не само успешни действия, но и ясни откази, непроменени данни и използваеми събития за сигурност. Преди да разрешите достъп за писане на реални потребители, процесът може да бъде тестван в Shadow Mode с реалистични заявки, без да се изпълняват предложените действия.

Чеклист за уебсайт екипи

• Всеки инструмент ли е малък, със специфична цел и от фиксиран allowlist?
• Проверяват ли се потребителят, тенантът, обектът и действието от страна на сървъра?
• Прилагат ли се Deny by Default и минимални технически права?
• Виждат ли потребителите всички съществени данни преди критични действия?
• Губи ли валидност потвърждението при промени и след кратко време?
• Предотвратява ли ID за идемпотентност двойното изпълнение?
• Съществуват ли лимити, таймаут, прекъсване, компенсация и прехвърляне към човек (Human Handoff)?
• Остават ли токените, тайните и излишните лични данни извън логовете?
• Покрива ли матрицата за тестване грешки в правата, манипулации, повторни опити и отпадания?

Заключение: Моделът предлага, приложението решава

Уебсайт чатботът, способен да действа, не трябва да започва с пълен достъп. Започнете с строго ограничено, обратимо действие и изградете видима верига от одобрения около него. Когато структурирането на инструмента, авторизацията от страна на сървъра, конкретното потвърждение, идемпотентността и планът за възстановяване са проектирани заедно, чатът остава полезен, без да се дава на модела ролята на система за сигурност. За следващата стъпка си струва да организирате уъркшоп с екипите по продукт, разработка, поддръжка и защита на данните: Изберете реално действие, класифицирайте неговия риск и дефинирайте безопасния случай на отказ преди първото одобрение в реална среда.