Недавно я решил протестировать 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 для стен этого лабиринта подходит лучше всего. Главное - не забыть закрыть в нем все люки.