Как промпт инжекция може да доведе до изтичане на данни в три стъпки: Защо NetworkPolicy не е достатъчна

Публикувано от Svetni.me Editorial на 14 юли 2026 г.

Представете си следния сценарий: служител изисква от AI агент да обобщи клиентски тикет за поддръжка. Агентът изпълнява задачата успешно, но в същия момент чувствителни данни за клиентите напускат мрежата чрез обикновена HTTPS заявка към неизвестен външен домейн. Никакви аларми не се задействат, защото нищо не е изтрито или компрометирано на ниво процеси.

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

Детерминирано ограничаване на изтичането на данни
Изображение: Svetni.me / Авторско изображение

Веригата от три стъпки (The 3-hop chain)

Атаката се развива в три последователни стъпки, които заобикалят традиционните контроли за сигурност:

  1. Prompt Injection (Промпт инжектиране): Атакуващият вгражда злонамерен промпт в тикет за поддръжка или документ. Когато агентът прочете този входен източник, той го интерпретира като легитимна инструкция (индиректно инжектиране).
  2. Извикване на MCP инструмент: Агентът извиква легитимен инструмент през Model Context Protocol (MCP) за изпращане на заявка към външен URL адрес. От гле точка на платформата инструментът има нужните права.
  3. Егрес през порт 443: MCP сървърът в Kubernetes отваря TCP връзка към дестинацията на атакуващия по криптиран канал (HTTPS/443) и предава източените данни.

Ограниченията на NetworkPolicy

Защо стандартната мрежова политика в Kubernetes не може да спре този процес? Тя работи на нива L3/L4 и филтрира трафика по IP адреси и портове. Тя не може да разграничи легитимен домейн от злонамерен, когато и двата задкулисно използват една и съща CDN мрежа с ротиращи се IP адреси.

Ако разрешим изходящ трафик към интернет на порт 443, позволяваме достъп до целия свят. Пълната забрана пък би направила агента неизползваем, тъй като той няма да може да се свърже с LLM моделите.

Детерминирано ограничаване (Deterministic Containment)

За разлика от вероятностните защити като филтриращи LLM модели, детерминираното ограничаване на ниво инфраструктура предлага сигурност, независима от решенията на AI модела. Това изисква прилагане на контроли на ниво L7 с три ключови свойства:

  • Идентификация на ниво Pod: Политиката се базира на конкретната услуга, която прави заявката.
  • Информираност за домейните: Разпознаване на дестинациите по пълно име (FQDN) от TLS SNI заглавията.
  • Забрана по подразбиране (Default-Deny): Всичко извън списъка с разрешени домейни се блокира автоматично.

Технологии като eBPF (например чрез Cilium), сервизни мрежи (Service Meshes) или облачни защитни стени от ново поколение (като Aviatrix) позволяват реализирането на тези контроли на ниво ядро или шлюз.

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

Източници:
[1]: Prompt Injection to Data Exfil in 3 Hops - O'Reilly Radar