Как да осигуря AI сигурност?

За да осигуриш AI сигурност, третирай AI системата като продукт в production, а не като „модел“. Това значи: threat modeling, защита на данните, защита на версиите/артефактите, контрол на достъпа до inference, и специални мерки за LLM рискове (prompt injection, изтичане през tools, злоупотреба с контекст). AI сигурността не е единична защита, а слоеве: данни, модел, приложение и операции. Следващите стъпки дават практичен план.

Въведение

Класическата киберсигурност не е достатъчна за AI. Освен обичайните рискове (credential leaks, RCE, supply chain), AI добавя:

  • data poisoning и „лоши“ training данни
  • model inversion/extraction (извличане на знание/параметри)
  • prompt injection и jailbreaking при LLM
  • злоупотреба с инструменти (tools) и агентни системи
  • drift: качеството пада и никой не забелязва

Затова най-добрият подход е: сигурност по дизайн + тестове + мониторинг.

Ако AI има достъп до вътрешни системи, всяка prompt injection атака може да стане бизнес инцидент.

Стъпка 1: Направи threat model (какво пазиш и от кого)

Започни с инвентар:

  • Какви данни влиза/излиза (PII, търговски тайни)?
  • Къде се пазят артефактите (model weights, prompts, ключове)?
  • Какви интеграции има (CRM, файлове, платежни системи)?

Определи актьори и сценарии:

  • външен атакуващ (ботове, scraping)
  • вътрешен потребител (неволна грешка)
  • доставчик/подизпълнител

Резултатът трябва да е списък от рискове с приоритет: вероятност × въздействие.

Стъпка 2: Заключи data pipeline-а (training и inference данни)

AI е толкова сигурен, колкото и данните му.

Мерки:

  • Контрол на достъпа до raw данни (least privilege).
  • Валидация на входа (schema, размери, лимити).
  • Сканиране за PII/секрети преди логване.
  • За RAG: sanitize на документи и източници; не индексирай „каквото дойде“.

За poisoning защита:

  • подписани/версионирани datasets
  • отделна карантина за нови данни
  • автоматични проверки за аномалии в разпределенията

Стъпка 3: Защити supply chain-а (модели, зависимости, контейнери)

Съвременните AI системи са зависими от много пакети и модели.

Практики:

  • pin-вай версии (poetry.lock/requirements.txt).
  • сканирай контейнери за CVE.
  • използвай private registry за образи.
  • проверявай произход на модели (официален repo, hash).

Supply chain компромис в AI често изглежда като „странно поведение“, не като класически пробив.

Стъпка 4: Сигурен inference endpoint (auth, rate limits, изолация)

Минимални мерки за endpoint:

  • TLS навсякъде
  • authentication (API key/JWT/OAuth)
  • authorization (кой може какви модели/функции)
  • rate limiting и квоти
  • входна валидация (size limits, типове)

Изолация:

  • отдели inference от други услуги
  • минимални права към storage/secret-и
  • network egress политики (особено при tools)

Стъпка 5: LLM специфики: prompt injection и безопасни tools

OWASP публикува топ рискове за LLM приложения, като prompt injection е сред най-важните. Ако LLM има tools (например „изпрати имейл“, „чети CRM“, „плати“), ти трябва строг контрол.

Практичен модел:

  • Allowlist на инструменти: LLM може да извиква само предварително дефинирани функции.
  • Валидация на параметрите: типове, диапазони, позволени домейни.
  • Sandbox за изпълнение: инструменти не трябва да имат директен достъп до production без допълнителни проверки.
  • Output constraints: не изпълнявай „свободен текст“ като команда.

За prompt injection:

  • разделяй „инструкции“ и „данни“ (например с ясни блокове)
  • не се доверявай на съдържание от външни документи/URL като инструкции
  • при RAG: маркирай източника като „не-доверен“ и филтрирай

Стъпка 6: Наблюдение и откриване на злоупотреба

Това, което не измерваш, не можеш да защитиш.

Следи:

  • аномалии в трафика (spikes, scraping)
  • повтарящи се провали/грешки
  • подозрителни промптове (индикатори за jailbreak/injection)
  • разходи (LLM често се DoS-ва през токени)
  • качество (drift)

Полезно: отделен „security audit log“ с минимална чувствителност (метаданни, хешове), за да не логваш PII.

Стъпка 7: Тестове, red teaming и план за инциденти

Сигурността идва от упражнения.

  • Направи тестове за OWASP LLM Top 10 рискове.
  • Пусни „злоупотребни“ тестови промптове (jailbreak, injection).
  • Тествай tools безопасността (валидирай, че не приемат опасни параметри).
  • Направи план за инцидент: кой реагира, как се изключват интеграции, как се прави rollback.

Съвети за по-добри резултати

  • Започни с минимални права и добавяй достъп постепенно.
  • Използвай отделни ключове/проекти за dev/staging/prod.
  • Въвеждай „human approval“ за опасни действия (плащания, изтриване, изпращане).
  • Дръж лимити за токени, файлове и трафик.
  • Преглеждай периодично prompts, tools и политики.

Чести грешки, които да избягваш

  • LLM има директен достъп до вътрешни системи без allowlist/валидиране.
  • Логваш целия промпт/контекст с лични данни.
  • Няма rate limit и някой изяжда бюджета за час.
  • Няма начин за бързо изключване на tools.
  • Няма тестове за prompt injection.

Източници и полезни линкове (проверени 2023–2026)

Контроли по слоеве (практична матрица)

Данни

  • Класификация и маркиране (PII, секрети, вътрешни).
  • Минимизация и редакт преди логване и преди изпращане към LLM.
  • Валидация на входа: размери, типове, allowlist формати.
  • Отделни хранилища и ключове за dev/staging/prod.

Модел и артефакти

  • Версиониране на модели/промптове и проследимост (кой промени какво).
  • Контрол на достъпа до weights и checkpoint-и.
  • Проверка на целостта (hash) при сваляне на модели.
  • Тестове за регресии при смяна на версия.

Приложение

  • AuthN/AuthZ за endpoint-и и админ панели.
  • Rate limiting и квоти на потребител/ключ.
  • Ограничения на контекст и изход (tokens, размери).
  • „Safe defaults“: ако нещо липсва, приложението отказва действие.

Операции

  • Наблюдение на разход и злоупотреба (LLM DoS често е през токени).
  • Аларми при аномалии и план за бързо изключване на интеграции.
  • Ротация на ключове и периодични ревюта на права.

Сигурността на LLM приложенията се печели в интерфейса към данни и инструменти, не в „по-строг промпт“.

Мини-плейбук по OWASP рискове (LLM приложения)

Това не е изчерпателно, но е добра практична рамка за QA/пен тест:

  • Prompt injection: отделяй инструкции от данни; не изпълнявай инструкции от външни документи; при tools ползвай allowlist.
  • Data leakage: не логвай пълни промптове с PII; маскирай чувствителни полета; ограничи контекста.
  • Insecure output handling: не изпълнявай свободен текст като SQL/код/команда; винаги валидирай и ескейпвай.
  • Excessive agency: LLM не трябва да има „админ права“; опасните действия минават през потвърждение.
  • Supply chain: pin-вай версии и проверявай произхода на модели/пакети.
  • Overreliance: за важни решения винаги има човешка проверка или независима валидация.

Сигурност при RAG (когато LLM чете документи)

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

  • Индексирай само проверени източници (или отдели „непроверени“ в карантина).
  • Използвай метаданни и allowlist на домейни/папки.
  • В отговора изисквай цитати към конкретни chunk-ове; ако няма цитат, не приемай твърдението за факт.
  • Нормализирай документи при ingestion (премахни скрити инструкции, странни Unicode символи, макроси).

Практичен чеклист преди production

  • Има ли threat model и собственик на риска?
  • Има ли DLP/редакт преди логване?
  • Има ли rate limiting и лимит на токени/контекст?
  • Има ли allowlist на tools и валидиране на параметрите?
  • Има ли отделни ключове за dev/staging/prod и ротация?
  • Има ли мониторинг на разход и аларми при скок?
  • Има ли runbook за инцидент и „kill switch“ за интеграции?

Атаки към модели: extraction, inversion и „изтичане“ на знание

Освен prompt injection има и атаки, насочени към самия модел и неговото поведение:

  • Model extraction: атакуващият прави много заявки и се опитва да възпроизведе модела (или да извлече знанието му) чрез наблюдение на изходите.
  • Model inversion / membership inference: опити да се „отгатне“ дали конкретни данни са били част от обучението или да се възстановят чувствителни характеристики.
  • Jailbreaking: систематични техники да се заобиколят политиките и да се генерира забранено съдържание.

Контроли, които реално помагат:

  • строги квоти и rate limits (намаляваш възможността за масово сондиране)
  • наблюдение за автоматизирани модели на заявки (scraping)
  • разделяне на модели/възможности по роли (потребителят не вижда „всичко“)
  • минимизиране на детайлността на изхода, когато не е нужна (не връщай вътрешни логове, стекове, контекст)

Когато изходът става „API за атака“, правилният отговор е лимитиране и наблюдение, не само филтри.

Защита на системни инструкции и конфигурация

Системният промпт, инструментите и правилата са част от attack surface-а. Практики:

  • дръж системните инструкции като код (version control + ревю)
  • не ги „изплювай“ в отговора; филтрирай опити за prompt leaking
  • отдели конфигурацията (ключове, домейни, allowlist) от текста, който LLM вижда
  • при нужда от debugging, ползвай отделен debug режим за админи

Guardrails и оценка на риска (преди да дадеш достъп на потребители)

Не разчитай само на „правилен промпт“. Добави проверими guardrails:

  • политика за съдържание (какво е забранено)
  • класификация на вход/изход (напр. PII, токсичност, секрети)
  • тестове с фиксирани сценарии (regression suite)
  • отделни правила за различни групи потребители (ролева политика)

Практичен подход: събери 50–200 реални/синтетични примера, включително злоупотребни промптове, и мери колко често системата отказва опасни заявки и колко често „изпуска“ чувствителни данни.

Бележка: При AI системи „сигурност“ включва и бизнес злоупотреби: спам, измами, социално инженерство и злоупотреба с достъп. Дръж ясни правила кой може да прави какво, логвай критичните действия и отделяй време за регулярни прегледи на инциденти и near-miss случаи. Това е скучно, но реално намалява риска.

Добави редовни tabletop упражнения поне веднъж на тримесечие.