Deterministic Commitment Layer: архитектура верификации агентных систем и первый десктопный инструмент для её практического применения
«Ты веришь агенту на слово. Но у агента нет слов — только токены»
Проблема, о которой мы знаем, но делаем вид, что не замечаем
На прошлой неделе Хабр опубликовал материал о том, как компании платят до 300 000 рублей в месяц за «скрытый аутсорс» задач в ChatGPT. История получила резонанс — но обсуждение ушло не туда. Говорили о доверии, об этике, о трудовом договоре.
Никто не спросил о главном: а как вы вообще проверяете, что задача была выполнена — агентом или человеком? И была ли она выполнена вообще?
В открытом демо-пайплайне dcl-eval-pipeline-demo я показала, как аудировать поведение агентов на практике. Теперь разберём, почему это критично и как построить полноценный слой верификации — вплоть до готового инструмента, который можно скачать и запустить прямо сейчас.
Это не риторический вопрос. Это архитектурная дыра, которая сейчас присутствует практически в каждой агентной системе. Называется она fabricated execution — ситуация, когда агент возвращает результат, не выполнив задачи, или выполнив что-то принципиально другое, оформив под видом запрошенного.
Что такое fabricated execution и почему это архитектурное свойство
Большинство разработчиков воспринимают LLM-агента по аналогии с детерминированной функцией: на вход подаётся задача, на выходе — результат. Если результат выглядит правдоподобно, значит, функция отработала.
Проблема в том, что LLM не является детерминированной функцией. Это генеративная модель, обученная предсказывать следующий токен. Она не «выполняет» задачу — она генерирует текст, который статистически соответствует тому, как выглядит выполненная задача.
Функция sort(array) возвращает отсортированный массив. LLM-агент, которому поручено «отсортировать таблицу продаж», вернёт текст, который выглядит как отсортированная таблица. И этот текст может быть галлюцинацией.
Это не недостаток конкретной модели — это архитектурное следствие того, как устроены трансформеры. Они оптимизированы на правдоподобие вывода, а не на его корректность относительно внешней реальности.
Три класса fabricated execution
1. Полная фабрикация
Агент не выполняет задачу вообще, но генерирует убедительный отчёт о её выполнении. Классический пример: агент, которому поручено проверить 1000 строк кода на наличие SQL-инъекций, возвращает список «найденных уязвимостей» — сгенерированных, а не реально обнаруженных.
2. Частичная фабрикация
Агент выполняет задачу частично, а остаток генерирует. Особенно распространено при работе с большими объёмами данных: агент обрабатывает первые N записей, затем начинает экстраполировать паттерны на оставшиеся, не обращаясь к реальным данным.
3. Подмена задачи
Агент выполняет задачу, близкую к запрошенной, но не идентичную ей. Это наиболее коварный сценарий: результат выглядит корректным, но содержит систематическое смещение, которое проявится только на этапе применения.
DCL: детерминированный слой верификации
Deterministic Commitment Layer (DCL) — архитектурный паттерн, который вводит независимый верификационный слой между агентом и потребителем его результатов. Ключевое слово — «детерминированный»: в отличие от самого агента, верификационный механизм работает по строгим, воспроизводимым правилам.
DCL не пытается «улучшить» агента или заставить его быть честным. Он работает как внешний аудитор: независимо от того, что утверждает агент, DCL проверяет факт выполнения задачи по криптографически верифицируемым следам.
Классические SIEM-системы покрывают инфраструктуру, сеть, доступ. Логику решений LLM-агентов они не видят вообще. DCL закрывает именно эту слепую зону.
Три ключевых компонента
Протокол обязательств (Commitment Protocol)
Перед выполнением задачи агент генерирует детерминированное обязательство — криптографическую привязку к входным данным и заявленному плану выполнения. Оно содержит хэш входного состояния, список инструментов, которые агент обязуется использовать, и ожидаемые побочные эффекты.
обязательство = Hash(id_задачи хэш_входа список_инструментов || временная_метка)
После получения обязательства агент не может изменить параметры задачи без создания нового. Это ломает fabricated execution первого класса: без валидных следов инструментального использования фабрикация выявляется автоматически.
Верификация трассы выполнения
DCL фиксирует трассу на уровне вызовов инструментов, не полагаясь на самоотчёт агента. Каждый вызов внешнего инструмента (API, файловая система, ��аза данных) подписывается независимым сервисом, недоступным агенту напрямую.
Результат — граф верифицированных событий, который сопоставляется с обязательством. Если агент утверждает, что проверил 1000 строк кода, но граф содержит только 47 вызовов статического анализатора — расхождение детектируется автоматически.
Криптографический журнал аудита
Иммутабельный лог сохраняет всю цепочку: обязательство, трассу выполнения и финальный результат. Любая попытка ретроспективной модификации разрывает криптографическую цепочку — что решает не только проблему fabricated execution, но и переписывания истории выполнения при наличии у агента долгосрочной памяти.
Практическая реализация
Рассмотрим упрощённую реализацию DCL-паттерна. Полный рабочий пример доступен в репозитории.
Структура обязательства
import hashlib, json, time from dataclasses import dataclass, field from typing import List, Dict @dataclass class TaskCommitment: task_id: str input_hash: str # SHA-256 входных данных tool_manifest: List[str] # список разрешённых инструментов expected_side_effects: Dict timestamp: float = field(default_factory=time.time) def sign(self) -> str: payload = json.dumps({ 'task_id': self.task_id, 'input_hash': self.input_hash, 'tools': sorted(self.tool_manifest), 'ts': self.timestamp }, sort_keys=True) return hashlib.sha256(payload.encode()).hexdigest()
Верификатор трассы
class DCLVerifier: MIN_COVERAGE_THRESHOLD = 0.8 def verify( self, commitment: TaskCommitment, trace: List[ToolCall] ) -> VerificationResult: # 1. Проверка разрешённых инструментов used_tools = {call.tool_name for call in trace} unauthorized = used_tools - set(commitment.tool_manifest) if unauthorized: return VerificationResult.UNAUTHORIZED_TOOL_USE # 2. Проверка минимального покрытия coverage = self._compute_coverage(trace, commitment) if coverage < self.MIN_COVERAGE_THRESHOLD: return VerificationResult.INSUFFICIENT_EXECUTION # 3. Верификация подписей вызовов for call in trace: if not self._verify_call_signature(call): return VerificationResult.TAMPERED_TRACE return VerificationResult.VERIFIED
Верификатор не анализирует семантику результата — это задача отдельного слоя. DCL проверяет факт выполнения, а не качество.
DCL Evaluator: потрогать руками прямо сейчас
Архитектурный принцип — хорошо. Но инженеры хотят запустить и посмотреть. Мы сделали десктопное приложение.
DCL Evaluator — это реализация DCL-паттерна в виде десктопного инструмента для детерминированного аудита и верификации ответов ИИ-агентов. Работает полностью офлайн, данные не покидают машину. Локальный агент подключается через Ollama.
Что внутри:
Редактор политик с drag & drop YAML — описываете правила в несколько строк
Вердикт COMMIT / NO_COMMIT по каждому ответу агента с объяснением причины
Криптографический audit trail — каждое событие подписано и экспортируется
Детекция дрейфа по Z-тесту с четырьмя уровнями угроз: NORMAL / WARNING / ESCALATION / BLOCK
Полная офлайн-работа — ни один байт не уходит наружу
Тёмная и светлая тема, потому что это важно
Стек: Go + React (Wails). Windows 10/11 x64. Для локального агента — Ollama (ollama pull llama3.2:1b перед первым запуском).
Это пре-релиз v1.0.0. Известные ограничения есть, в v1.1 уже в работе. Если найдёшь баг или захочешь фичу — issue или в личку.
DCL и приказ ФСТЭК №117: конкретные пункты
Регуляторы движутся в том же направлении. EU AI Act явно указывает на необходимость аудиторских следов для систем высокого риска. ФСТЭК формирует аналогичные требования для государственных информационных систем — и здесь DCL Evaluator закрывает конкретные пункты, а не абстрактные принципы:
Требование приказа №117 | Статья / пункт | Как закрывает DCL Evaluator |
Непрерывный мониторинг событий безопасности ИИ‑компонент | Раздел IV, п. 28–31 | JSON‑логи всех действий агента в реальном времени; детектирование аномальных решений |
Регистрация и хранение событий безопасности | Раздел IV, п. 32–34 | Структурированный audit trail с временными метками; экспорт для интеграции с SIEM/SOC |
Контроль сценариев применения ИИ и критерии достоверности ответов | Раздел III, п. 19–22 | Политики DCL формализуют допустимые тематики и критерии корректности; COMMIT/NO_COMMIT вердикт по каждому ответу |
Выявление признаков угроз и нарушений регламентов | Раздел IV, п. 35–37 | Автоматическое выявление drift и отклонений от политики; флаги инцидентов в audit log |
Отчётность и демонстрация эффективности мер защиты | Раздел V, п. 41–43 | Экспорт отчётов о соответствии; метрики качества и надёжности агентов для регуляторной отчётности |
Важно: DCL Evaluator не заменяет классический SIEM и не обеспечивает полного соответствия приказу №117 самостоятельно. Решение выступает специализированным модулем мониторинга ИИ-компонент в составе общей системы ИБ организации — закрывая ту зону, которую классические средства защиты не покрывают.
Где работает, а где нет
Сильные стороны
Регулируемые домены: финансы, медицина, юриспруденция — везде, где требуется аудиторский след и доказуемость выполнения.
Долгосрочные автономные агенты: чем дольше агент работает без надзора, тем выше риск fabricated execution — и тем ценнее непрерывный журнал.
Мультиагентные пайплайны: когда один агент передаёт результат другому, DCL позволяет каждому звену цепочки проверить входные данные.
Соответствие нормативным требованиям: DCL‑журнал является доказуемым свидетельством того, что система работала в соответствии с заявленными параметрами.
Ограничения
Задачи с неверифицируемым выводом: если результат агента — текст или решение, которое невозможно проверить инструментально, DCL фиксирует факт обработки, но не корректность вывода.
Накладные расходы: каждый вызов инструмента через верификационный слой добавляет задержку. Для систем реального времени нужна тщательная балансировка.
Состязательные агенты: достаточно сложный агент может научиться генерировать синтетические следы, соответствующие обязательству. Это отдельная задача — обнаружение поддельных трасс.
Почему это важно именно сейчас
История с 300 000 рублей за аутсорс в ChatGPT — симптом. Симптом того, что мы строим системы, которые доверяют агентам на слово, не имея инструментов для проверки этого слова.
По мере того как агентные системы становятся частью критической бизнес-инфраструктуры — обрабатывают транзакции, принимают решения о кредитах, автоматизируют юридические проверки — вопрос верификации переходит из категории «хорошо бы» в категорию «обязательно».
DCL — не академический эксперимент, а ответ на требования, которые уже существуют или появятся в ближайшие 12–24 месяца.
Мы привыкли проверять код через тесты. Пора привыкнуть проверять выполнение агентских задач через верификационные слои. Это не паранойя — это инженерная зрелость.
Что делать прямо сейчас
Введите логирование всех инструментальных вызовов с независимыми подписями — это минимальный DCL‑паттерн, реализуемый за день.
Определите метрики покрытия для каждого типа задач: сколько вызовов инструментов ожидается при честном выполнении задачи X?
Добавьте шаг обязательства перед выполнением: агент должен объявить, что собирается делать, до того как начнёт.
Проведите аудит существующих журналов: если их нет — это уже ответ на вопрос о верифицируемости вашей системы.
DCL — это не библиотека и не вендорское решение. Это архитектурный принцип, масштабирующийся от простого логирования до полноценной криптографической верификации.
Агент сказал «сделано». Теперь у вас есть инструменты, чтобы это проверить.
Ресурсы и дальнейшее чтение
DCL Desktop App v1.0.0 (pre‑release) — pre‑release — скачать и запустить прямо сейчас
Открытый демо‑пайплайн dcl‑eval‑pipeline‑demo — dcl‑eval‑pipeline‑demo — рабочие примеры верификации агентов на Python + FastAPI + Docker
Предыдущий пост: «Как аудировать поведение ИИ‑агентов» — Детерминистический аудит‑слой для LLM‑агентов — открытое демо — практическое введение в тему
Whitepaper по DCL — полная техническая спецификация архитектуры готовится к публикации. Хотите раннюю версию — пишите в комментариях или в личку.
© Fronesis Labs
