PWN AI

Недавно я решил протестировать Open Policy Agent. Если кратко, OPA представляет собой цифрового бюрократа. Это не гардрейл, который пытается понять ваш замысел, и не эвристический фильтр, ищущий скрытые смыслы. Это детерминированный движок, берущий на вход JSON-контекст и прогоняющий его через набор жестких правил на декларативном языке Rego. Его единственная задача - сказать «да» или «нет», опираясь исключительно на букву правила. В мире AI-агентов, постоянно норовящих выйти за рамки дозволенного, OPA играет роль безжалостного швейцара, проверяющего документы на входе. Я поднял OPA-сервер в Docker и прогнал через него тридцать тестов (это мало, как мне кажется), часть из которых были сделаны с нуля, а часть взял из готовых примеров. Агента собрал на базе CrewAI и слегка допиленного DeepSeek. Больше всего меня зацепило, что движок умеет мыслить последовательностями, а не просто реагировать на отдельные слова. Обычно политики безопасности представляют как плоский список запретов: нельзя удалять файлы, нельзя трогать базу. Но агент штука хитрая. Он может легально прочитать приватный ключ, а затем так же легально отправить его по почте. Каждый шаг по отдельности кристально чист, и классический фильтр его пропустит. Поэтому я скормил OPA политику на композиционный анализ, заставив Rego смотреть не на текущий вызов, а на историю действий. Когда агент после чтения файла потянул отправку письма, сервер просто положил запрос на стол с вердиктом об эксфильтрации. А так же он поймал цепочку, где агент сначала выполнил код, а потом пошел гуглить, как замести следы. Разогнавшись на цепочках, я прогнал его на тестах где агент должен был сделать запросы к базам данных, через SQL. OPA перестал просто искать ключевые слова вроде DROP. Он начал разбирать грамматику, ловить составные запросы и блокировать запросы, если хоть одна команда в списке была грязной. Тут меня ждал первый облом. В документации гордо расписана встроенная проверка схем, но на практике она напрочь игнорирует обязательные поля. Rego вообще язык специфический. 🤨 Если напишешь не то имя поля, движок не кинет исключение. Он просто молча вернет пустоту, политика не сработает, и ты будешь часами чесать затылок, глядя в логи. Зато с ловлей зацикливаний он справился отлично, безжалостно кикая агента, который пять раз подряд вызывал один и тот же инструмент, и строго следя за тем, чтобы в параметры не просочились лишние поля. За всё это я платил скоростью. OPA отрабатывал от пяти до ста двадцати миллисекунд. Для прототипа нормально, но понятно, что в продакшене такой сервер придется сажать в отдельный контейнер рядом с агентом и настраивать постоянные соединения. Иначе агент будет думать дольше, чем генерировать текст. 💰💰 И всё же, даже с этими продвинутыми трюками OPA остается тем, чем является. Детерминированным фильтром. Он не понимает смысла. Если вы заблокировали слово "SSN", агент просто назовет поле "social_security_number", и OPA радостно пропустит запрос. Он не умеет отслеживать, откуда именно пришли данные в параметры. Закодированные промпт-атаки пройдут сквозь него как нож сквозь масло, если только вы не наколдуете поверх кучу дополнительных правил. Итог простой. OPA в связке с AI-агентом это идеальная, быстрая и иногда непрошибаемая стена. Почему иногда ? Потому что всё-равно есть вероятность взлома. Он отлично справляется с ролью жесткого контроля: режет опасные инструменты, следит за схемой параметров и даже анализирует цепочки действий. Но строить на нем всю безопасность кажется чересчур наивным делом. Это база, на которую нужно класть языковую модель для понимания семантики входящих запросов, песочницу для изоляции и трекер потоков данных. Мы не можем заставить нейросеть быть хорошей, но можем построить вокруг нее харнесс, из которого плохие действия просто не выйдут. И OPA для стен этого лабиринта подходит лучше всего. Главное - не забыть закрыть в нем все люки.😒😒😒