Prompt injection при уебсайт чатботове: Защита за RAG, инструменти и данни

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

Всеки, който иска да ограничи prompt injection при уебсайт чатботове, не трябва да разчита единствено на изключително строго формулиран системен промпт. Необходима е многослойна архитектура: въведените данни и източниците се третират като ненадеждни, разрешенията са технически ограничени, изходните данни се проверяват преди последваща обработка, а рисковите действия се потвърждават от детерминистичен код или от човек.

Какво означава prompt injection при чатбот за уебсайт

OWASP описва prompt injection като въвеждане на данни, което неволно променя поведението или изхода на езиковия модел. Директното prompt injection идва непосредствено от потребителя, например като подкана за пренебрегване на предишни правила. Индиректното prompt injection от своя страна се крие във външно съдържание, което системата извлича впоследствие: уеб страници, документи с знания, имейли, данни за продукти или файлове.

Това разграничение е важно за собствениците на уебсайтове. Чатбот, който обслужва само ЧЗВ (FAQ), има по-малка повърхност за атака от система, която постоянно обхожда уеб страници, търси във вътрешни документи, чете данни от CRM или може да изпълнява функции. Retrieval-Augmented Generation (накратко RAG) подобрява експертната основа на отговорите, но не премахва риска от инжекции. Дори добре поддържан набор от източници може да съдържа манипулирани или грешно разтълкувани инструкции.

Оценка на риска според функциите, а не според името на модела

Решаващият въпрос е не само „Кой модел използваме?“, а „Какво въздействие може да има един манипулиран отговор?“. Създайте проста карта на функциите и данните за чатбота:

• Кои обществени и вътрешни източници има право да чете?
• Кои лични, поверителни или критично важни за бизнеса данни са достъпни?
• Може ли той само да генерира текст или също така да създава тикети, потенциални клиенти (leads), имейли, срещи или поръчки?
• Кои действия променят външни системи?
• Кои решения се вземат автоматично, без човек да ги проверява?

Колкото по-големи стават правата за четене, правата за писане и степента на автоматизация, толкова по-важни са техническите ограничения извън самия модел. Наличният преглед на чести грешки при AI чатботове помага при общата инвентаризация. За prompt injection трябва допълнително да документирате потоците от данни, границите на доверие и правата за действия.

Ясно разделяне на четири зони на доверие

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

Зона 1: Системни правила и политики

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

Зона 2: Входни данни от посетители

Всяко чат съобщение трябва да се счита за ненадеждно. Ограничете дължината, типовете файлове и позволените функции; нормализирайте входните данни за техническата обработка и ги маркирайте ясно в промпта като потребителски данни. Филтърът може да открива познати модели на атака, но не трябва повсеместно да блокира легитимни въпроси. Посетител, който пита за „ignore previous instructions“ в документация за сигурност, може да има напълно основателно запитване.

Зона 3: Извлечени източници и RAG контекст

Дори обходеното съдържание, PDF файловете и резултатите от външни услуги си остават данни, а не инструкции. Разделяйте тяхното съдържание видимо от управляващия контекст, запазвайте произхода и часа на извличане и разрешавайте само одобрени източници. Статията за актуалност на базата от знания за AI чатботове показва как инвентарът от източници, честотата на обхождане и контролът на качеството (QA) взаимодействат помежду си.

Зона 4: Инструменти, действия и изходни данни

Извикванията на функции не трябва да се изпълняват само защото моделът генерира съответен текст. Детерминистичен контролер проверява името на функцията, параметрите, разрешенията, контекста на сесията и позволените целеви системи. Изходните данни от модела, които по-късно се използват като HTML, Markdown, SQL, пътища до файлове или API параметри, се нуждаят от валидация и кодиране, подходящи за съответния контекст.

Принципът на минималните привилегии (Least Privilege) ограничава въздействието

Към днешна дата prompt injection не може да бъде надеждно изключено с една-единствена мярка. Ето защо приложението трябва да бъде изградено така, че успешен опит за манипулация да нанесе възможно най-малко щети. OWASP и Microsoft препоръчват за тази цел принципа на минималните привилегии (Least Privilege).

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

Чатбот за поддръжка може например да подготви чернова на тикет, но не трябва автоматично да определя произволни получатели, приоритети или вътрешни права за достъп. Чатбот за събиране на запитвания (leads) може да приема структурирани данни за контакт, без с това да получава права за четене на цялата CRM система.

Проверка и изолиране на RAG източници

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

Затова въведете входен контрол на източниците с правила за одобрение: позволени домейни и секции от документи, проследими собственици, версиониране, проверка за зловреден софтуер и файлове, както и преглед за ново или необичайно променено съдържание. Маркирайте ясно извлечените пасажи в контекста на модела като ненадеждно съдържание (untrusted content). Намерен резултат от търсенето може да предоставя информация, но не и да променя системни правила или разрешения за инструменти.

Проверете също дали отговорът наистина е подкрепен от източниците. Ръководството за качество на отговорите при AI чатботове с Golden Set и RAG тестове описва обосноваността (Groundedness) и съпоставката с източниците. Тази проверка на качеството допълва контролите за сигурност, но не ги замества.

Входните и изходните филтри са слой, а не цялото решение

Специализираните услуги за защита могат да откриват опити за директни и индиректни атаки. Microsoft Prompt Shields например разграничава атаки в потребителските въведени данни от скрити инструкции в документи. В своите насоки за сигурност Google също препоръчва мерки за защита срещу prompt injection, по-тясно дефинирани задачи, потребителски идентификатори, ограничения на обема и човешки надзор при по-висок риск.

Такива филтри предоставят вероятностни сигнали. Затова планирайте градирано поведение: блокиране, сигурен отговор, преминаване към строго ограничен режим или прехвърляне към човек. Записвайте класа на решението и техническата версия в дневниците (logs), но избягвайте ненужното съхранение на пълен текст. При лични данни се прилагат и областите за проверка, описани в статията за AI чатботове и GDPR. Настоящата статия не представлява правна консултация.

Валидиране на изходните данни от модела преди последваща обработка

Безопасните входни данни не гарантират безопасен изход. OWASP посочва недостатъчната обработка на изходните данни като отделен риск: текстът от модела може по-късно да попадне в HTML, скриптове, заявки към бази данни или пътища до файлове. Ето защо третирайте всеки изход от модела първоначално като ненадежден.

За автоматизирани процеси изискайте строго структуриран формат и го валидирайте спрямо схема. Използвайте разрешителни списъци (whitelists) за имена на функции и целеви системи. Кодирайте видимия текст спрямо съответния контекст на показване. Отхвърляйте неочаквани полета, външни URL адреси и параметри извън позволените стойности. Чувствителните данни трябва да преминават през допълнителна проверка на политиките преди показване или предаване.

Тестване за prompt injection със набор от тестове за сигурност

Допълнете експертния Golden Set с софтуерни тестове срещу злонамерени атаки (adversarial test cases). Тестовете трябва да проверяват действителната производствена система, включително извличането (retrieval), инструментите и логиката за разрешения, а не само базовия модел. Полезният набор съдържа:

• директни опити за замяна на правила или запитване за вътрешни инструкции;
• многоезични, кодирани и разпределени в няколко съобщения варианти;
• безобидни експертни въпроси, съдържащи подобни ключови думи, които не трябва погрешно да се блокират;
• манипулирани пасажи в тестовия източник на знания;
• неразрешени имена на функции, допълнителни параметри и непознати целеви адреси;
• опити за извеждане на поверителни данни или съдържание от предишни сесии;
• тестове за генериране на HTML, Markdown и връзки;
• пътища за прекратяване, прехвърляне (handoff) и потвърждение при рискови действия.

Не измервайте само дали филтърът се задейства. Проверете крайния резултат: Беше ли предотвратено непозволено действие? Останаха ли защитени поверителните данни? Продължи ли да работи легитимното запитване? Беше ли проследимо записан в дневника един съмнителен случай?

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

1. Дефиниране на обхвата: Документиране на източниците на данни, инструментите, правата за писане и външните цели.
2. Разделяне на зоните на доверие: Техническо маркиране на системните правила, потребителските данни, RAG съдържанието и изходите от действия.
3. Намаляване на правата: Премахване на неизползвания достъп и разделяне на действията за писане на малки функции.
4. Добавяне на валидация: Въвеждане на ограничения на входа, структурирани изходи, разрешителни списъци и специфично за контекста кодиране.
5. Определяне на потвърждения: Защитаване на рисковите действия и чувствителните потоци от данни чрез Human-in-the-Loop (човешки контрол).
6. Изпълнение на тестовия набор: Проверка на директни, индиректни и легитимни контролни случаи преди всяко съществено пускане (release).
7. Наблюдение на работата: Редовен преглед на събитията от филтрите, отказаните действия, необичайните промени в източниците и фалшивите аларми.

Чеклист: Защита от prompt injection

• Системният промпт не съдържа тайни (secrets) и не замества оторизацията.
• Потребителските текстове и външните източници се считат за ненадеждни по подразбиране.
• RAG източниците имат одобрение, произход, версия и отговорни собственици.
• Инструментите следват принципа Least Privilege и приемат само валидирани параметри.
• Рисковите действия изискват проследимо потвърждение.
• Изходните данни от модела се проверяват преди HTML, API, CRM или други целеви системи.
• Филтрите за сигурност се оценяват за фалшиво положителни (false positives) и фалшиво отрицателни (false negatives) резултати.
• Тестовете за директни и индиректни атаки се изпълняват редовно и след всякакви промени.

Заключение

Prompt injection не е просто проблем на промпт инженерството. За уебсайт чатботове надеждната защита възниква едва тогава, когато приложението третира входните данни, източниците, изходите и действията като отделни зони на доверие. Филтрите могат да откриват атаки, но Least Privilege, детерминистичната валидация и потвърждението от човек са тези, които ограничават възможното им въздействие.

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

Източници

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Microsoft Learn: Defend against indirect prompt injection attacks
• Microsoft Learn: Prompt Shields in Azure AI Content Safety
• Google AI for Developers: Safety and factuality guidance