Доказательство после инцидента: как мы отвечаем на вопрос «кто это разрешил»

Гипотетическая ситуация, проблема, и что мы построили, чтобы она не повторялась

Ситуация

К нам приходит клиент — не стартап, а компания с процессом: заявки, согласования, платежи. Мы внедряем агента, который ведёт часть этого процесса. Через два месяца случается инцидент: агент отправил платёж, который человек не подтверждал.

Разбор начинается с простого вопроса: «покажите, на каком основании он это сделал». И выясняется, что показать нечего.

Есть логи. Есть переписка. Есть выгрузка из CRM. Но ни один из этих артефактов не отвечает на вопрос, было ли у агента право на это действие в ту секунду и кто это право выдал. Полномочие — в одном месте, решение — в другом, отправка — в третьем, а факт исполнения — у получателя, и никто не проверял их вместе.

Проблема

Мы сформулировали её для себя так: между властью, решением, отправкой и эффектом есть разрыв, и индустрия закрывает его обещаниями, а не доказательствами.

Аттестация и стандарты идентичности отвечают на вопрос «кто на другой стороне»: какой workload, какой ключ. Это нужно, но не даёт ответа «по какому праву действовали». Корректно аттестованный сервер может принять действие вне делегированного объёма — и ни одно свойство аттестации не нарушится.

Логи отвечают на вопрос «что произошло», но не «было ли это позволено». Запись может быть полной и при этом описывать действие, которое никто не разрешал.

В итоге клиент после инцидента остаётся с кучей данных и без ответа. А поставщик агента — с фразой «у нас всё логируется», которая на разборе не работает.

Что мы сделали

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

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

Последнее — ключевое. Именно оно запрещает главную манипуляцию в отчётах: выдать «мы не измеряли» за «не применимо».

Офлайн-верификатор с негативными контролями. Проверка обязана отвергнуть пакет, в котором удалён кейс, продублирован кейс, перевёрнут вердикт, удалена цитируемая запись или две строки обменялись квитанциями. И принять неизменённый пакет. Это звучит как формальность, пока не срабатывает: в одном из публичных пакетов запись утверждала «исполнитель отказал у себя», а запись задания показывала зависшую попытку и отказ позже, на повторе. Никакая проверка целостности такое не ловит — ловит только сверка заявленного с записанным.

Открытость. Контракт, кейсы и правила отказа опубликованы; работа идёт в открытой рабочей группе по идентичности и доверию к агентам, результаты — в публичном репозитории и в статье на рецензии. Мы не просим верить нам на слово: любой может взять пакет и прогнать проверку.

Что это даёт клиенту

После инцидента — не «лог», а разбор: какое полномочие действовало, какое решение принято, что ушло, что произошло на стороне получателя и где доказательств нет. До инцидента — возможность заранее договориться, что считается нормой, а что инцидентом.

И главное — возможность проверить нас третьей стороной. Именно этого обычно не хватает в разговоре «доверьтесь нам, у нас всё под контролем».

Чего мы не утверждаем

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

И мы фиксируем границы собственного метода: сравнение идёт офлайн, по сохранённым записям; живое принуждение и эффекты на стороне цели им не устанавливаются.

Как это выглядит на практике

Пилот: мы смотрим на записи вашего агента, прогоняем их по контракту и показываем, что они доказывают, а что нет. Дальше — либо доработка записи, либо изменение границ полномочия, либо честная запись в договор о том, что остаётся непокрытым.

Если у вас есть действующий агент и вопрос «что мы предъявим, если что-то пойдёт не так» — с этого и начнём.