GateRook проверяет запросы ИИ-агентов в 3 шага до доступа к инфраструктуре

Дать ИИ-агенту терминал и пароль от базы — быстрый способ убрать ручное копирование логов. Заодно это быстрый способ потерять контроль над тем, что именно агент прочитал или изменил. Фраза в промпте «никогда не трогай production» здесь слабая защита: модель может ошибиться в окружении, неправильно понять найденную инструкцию или отправить корректный SQL не в ту базу.

GateRook предлагает вынести контроль в отдельный исполняющий слой между ИИ-клиентом и инфраструктурой. Это локальное desktop-приложение с MCP-шлюзом, коннекторами к базам, логам, API и серверам, политиками доступа и единым журналом вызовов. Проект открыт под Apache 2.0, однако материал написан его автором, поэтому заявления о возможностях стоит воспринимать как демонстрацию устройства продукта, а не независимый аудит безопасности.

Не терминал, а узкий инструмент

Вместо произвольного SSH агент получает, например, инструмент поиска по логам. В запросе явно задаются подключение, файл, строка поиска, период, максимальный объём сканирования и число возвращаемых строк. Агент может проверить гипотезу, но не получает универсальную командную строку.

Такой контракт полезнее общего разрешения «посмотреть сервер». Владелец видит фактические аргументы вызова, секрет SSH не попадает в чат, а объём чтения заранее ограничен. Для повторяемых операций предусмотрены runbook-команды с типизированными параметрами. Но сама обёртка ничего не гарантирует: опасная команда внутри runbook останется опасной.

Ресурсы разделены на три сущности. Connector описывает способ работы с MySQL, MongoDB, Redis, SSH или другим типом системы. Connection хранит настройки конкретного ресурса и его окружение. Endpoint определяет, какие подключения и инструменты увидит данный ИИ-клиент. Поэтому dev и production можно развести по разным точкам входа, не полагаясь на внимательность модели.

Почему одного одобрения мало

Показательный пример — SELECT без явно выбранной базы. Сам запрос безопасен с точки зрения типа операции, но подключение допускает две базы. GateRook отклоняет вызов до обращения к СУБД и сообщает причину: база не выбрана. Пользовательское «одобряю» не отменяет это обязательное условие.

С записью процесс строже. Агент предлагает UPDATE, шлюз классифицирует его как изменение и создаёт временный запрос на подтверждение. Человек видит точный SQL, подключение, окружение и оценку воздействия. После одобрения ядро повторно проверяет конфигурацию и выполняет сохранённый запрос. Агент не может подменить уже одобренный SQL другим выражением.

Это важная деталь архитектуры: разрешение привязано не к названию инструмента, а к конкретному содержимому операции. Если пользователь не ответил вовремя, запрос истекает. Если результат записи неизвестен из-за тайм-аута, автоматически повторять мутацию нельзя — отсутствие ответа ещё не означает, что база ничего не изменила.

Что брать в собственную систему

Практическая ценность GateRook не только в готовом приложении. Это неплохой шаблон для любой инфраструктуры, куда допускают агентов: выдавать специализированные инструменты вместо shell, разделять окружения, запрещать неоднозначные запросы, подтверждать неизменяемый payload и журналировать решение вместе с результатом.

При этом шлюз не заменяет права самой инфраструктуры. Production следует читать отдельной учётной записью с минимальными grants, а запись ограничивать на уровне СУБД, API и сервера. Локальное хранение секретов тоже не означает, что данные никогда не покидают компьютер: результаты разрешённых запросов отправляются ИИ-клиенту и, возможно, дальше поставщику модели. Нужны маскирование, лимиты выдачи и понятная политика хранения журнала.

Для разработчика главный вывод простой: контроль доступа к агентам нельзя оставлять внутри текста промпта. Для продукта — интерфейс подтверждения должен показывать действие и последствия, а не безликую кнопку Allow. GateRook демонстрирует этот подход убедительно, хотя независимая проверка реализации, модели угроз и заявленных гарантий всё равно необходима.