Патерн «DMZ для LLM»: Чому ми фізично розділили адмінських та клієнтських ШІ-ботів

Головна помилка при створенні ШІ-сервісів — спроба запхати всі знання та функції в одного «надрозумного» бота. Сьогодні при проєктуванні архітектури ми зіткнулися з класичною дилемою безпеки.

Наш головний ШІ-агент має високий рівень доступу: він вміє керувати сервером, смикати бекенд на FastAPI та редагувати код сайту. Якщо ми пустимо запити від звичайних клієнтів з Google Chat у цього ж агента, виникне величезний ризик. Клієнт (випадково чи навмисно) може сформувати такий промпт, який змусить ШІ «знести» нам сайт. Плюс, контексти різних користувачів неминуче почнуть перемішуватися.

Наше рішення: Демілітаризована зона (DMZ) для ШІ.
Ми вирішили винести клієнтського ШІ-Оркестратора в абсолютно інший контур — створили для нього окремого користувача на рівні ОС Linux.

Тепер Оркестратор фізично ізольований. У нього немає жодних адміністративних інструментів. Його єдина задача — спілкуватися з клієнтом у Google Chat, вести його за сценарієм замовлення та делегувати вузькі завдання (наприклад, рендер або білінг) іншим ізольованим субагентам.

Це класичний патерн безпеки DMZ (демілітаризованої зони), адаптований спеціально для LLM-систем. Результат: 100% безпека сервера, масштабованість та завжди кристально чистий контекст діалогу з клієнтом.