Клиент подтверждает платёж на 100 000 ₽ конкретному получателю. После подтверждения AI-агент, MCP/tool или downstream-сервис меняет сумму, счёт или получателя. Если система принимает прежнее approval, всё может выглядеть формально корректно: токен действителен, пользователь действительно подтверждал действие. Но он подтверждал не ту транзакцию, которая ушла в исполнение. Для руководителя риск прост: валидное подтверждение может стать ложным основанием для неверного платежа. Последствия — прямой финансовый ущерб, спор об ответственности, fraud-loss, нарушение внутренних контролей и неудобные вопросы на аудите. Проблема возникает после approval, но до execution. Ключевой принцип: разрешение должно быть привязано не только к тому, КТО подтвердил действие, но и к тому, ЧТО именно было подтверждено. Что должно происходить в корректной схеме Перед подтверждением пользователь или независимый checker должен увидеть точные критичные реквизиты: сумму и валюту, получателя и счёт, назначение и условия исполнения. Backend формирует каноническое состояние операции и считает его digest на доверенной стороне. Approval связывается с этим digest. Если критичное поле меняется, меняется и digest — старое approval автоматически становится недействительным и требуется новое подтверждение. Одноразовость approval и разделение ролей: Approval также должно иметь срок жизни и одноразовость: после успешного исполнения тот же approval_id нельзя использовать повторно. Execution защищается idempotency control, чтобы повторный запрос не превратился в двойное списание. Для high-impact операций важно явно развести роли: если агент или инструмент формирует или изменяет распоряжение, он выступает maker; checker — независимый человек или отдельный контрольный контур. Там, где политика требует разделения обязанностей, инициирующий субъект и approving principal должны различаться и быть видимы в audit trail. Что проверяет аудит. создать Transaction A, получить approval, затем изменить одно критичное поле и попытаться исполнить операцию. PASS: deterministic deny или новый approval flow. FAIL: Transaction B проходит под Approval A. Отдельно нужно повторить уже использованное или просроченное approval: оно также должно быть отклонено. Для инженеров и аудиторов Технический паттерн: canonical transaction → server-side digest → approval bound to digest → revalidation → execution Для JSON канонизацию можно реализовать, например, через JCS (RFC 8785). Принцип WYSIWYS здесь означает: «что показано, то и подтверждено»; экран approval не должен полностью формироваться тем же агентом, который способен менять транзакцию. OAuth 2.0 Token Exchange (RFC 8693) и DPoP (RFC 9449) решают задачи делегирования и защиты токена, но сами по себе не доказывают неизменность бизнес-реквизитов. Международный нормативный аналог того же принципа — dynamic linking в PSD2 RTS Article 5: подтверждение специфично для суммы и получателя и инвалидируется при их изменении. Итог В платёжном контуре недостаточно доказать, кто дал разрешение. Нужно доказать, какой именно transaction state был показан и подтверждён, что approval нельзя переиспользовать и что это состояние не изменилось до execution. Иначе у системы есть подтверждение — но нет авторизации именно этого платежа. Управленческий вопрос Если клиент подтвердил платёж, после этого агент изменил критические параметры операции, а система всё равно исполнила старое approval — кто в вашей организации считается владельцем этого риска и кто отвечает за возникший убыток? Опорные источники • RFC 8785 — JSON Canonicalization Scheme (JCS) • RFC 8693 — OAuth 2.0 Token Exchange • RFC 9449 — OAuth 2.0 DPoP • Commission Delegated Regulation (EU) 2018/389, Article 5 — Dynamic linking