Обзор reverify: MCP-сервер и CLI для верификации фактов в AI-агентах — что это меняет для операторов

Что произошло

На GitHub набирает популярность репозиторий 2akouwu/reverify (922 звезды, 199 форков, Python, создан 2026-08-31). Проект позиционируется как MCP-сервер + CLI, который заставляет AI-агента не просто генерировать утверждения, а прогонять их через детерминированные инструменты проверки против ground truth. Идея: LLM предлагает — детерминированный слой решает, каждое утверждение проверяется с приложением evidence, а верифицированный контекст переживает сбросы сессии.

Значимость для операторов: это не очередная обёртка над LLM, а попытка встроить верификационный контур в сам workflow агента, используя reverse engineering как полигон для тестирования (то есть проверка гипотез о поведении бинарей/кода — область, где голословные утверждения модели особенно опасны).

Почему это важно

• MCP (Model Context Protocol) становится де-факто стандартом интеграции инструментов с LLM-агентами — рост экосистемы MCP-серверов означает рост поверхности атаки и зависимостей в CI/CD и dev-тулинге.
• Заявленная функция «facts survive resets» подразумевает персистентное хранилище verified claims — нужно понимать модель доверия и целостности этого хранилища.
• Проект молодой (репозиторий создан в конце августа), высокая скорость роста звёзд (score=2965) при отсутствии данных о security-аудите — типичный профиль для supply-chain риска.

Что проверить перед внедрением

1. Модель доверия verifier'а:

• Кто/что является источником ground truth? Локальные детерминированные инструменты или внешние API?
• Есть ли риск, что сам verifier можно обмануть (prompt injection через evidence)?

2. Изоляция исполнения:

• MCP-серверы обычно получают доступ к файловой системе/shell через агента. Проверьте scope permissions.

# Клонировать в изолированную среду, не в рабочий репозиторий
git clone --depth 1 https://github.com/2akouwu/reverify.git /tmp/reverify-audit
cd /tmp/reverify-audit

# Просмотреть зависимости до установки
cat requirements.txt 2>/dev/null || cat pyproject.toml

# Запуск в контейнере без сетевого доступа наружу, если возможно
docker run --rm -it --network none -v $(pwd):/app python:3.12-slim bash

3. Пины версий и воспроизводимость:

pip install --no-deps -r requirements.txt
pip freeze > reverify-lock.txt
# зафиксировать hash-и через pip-compile или poetry.lock

4. Логирование и аудит evidence-цепочки — убедитесь, что каждый verified claim содержит ссылку на источник, доступную для последующего ручного аудита (не просто "trust me").

Чек-лист для пилотного внедрения

• Развернуть в sandbox/CI, не в продакшн-агентах сразу
• Проверить, какие MCP-permissions запрашивает сервер (filesystem, network, shell)
• Зафиксировать версию через lock-файл, не тянуть main в проде
• Настроить мониторинг вызовов verifier'а (сколько claims отклонено/принято)
• Убедиться, что персистентное хранилище fact-базы шифруется/бэкапится отдельно
• Провести ревью кода детерминированных tool-плагинов (именно они принимают решение — это критичный путь доверия)

Итог

reverify — показатель тренда: индустрия движется от «просто спросить LLM» к встроенным верификационным контурам. Для операторов это означает новый класс инфраструктурных компонентов (MCP-серверы) в цепочке поставки AI-инструментов, которые требуют тех же практик — pin, sandbox, audit — что и любой другой сторонний код с доступом к shell и файловой системе. Пока нет данных о независимом security-аудите проекта, относитесь к нему как к experimental dependency.