AI-агент в платёжном контуре: кто на самом деле авторизует действие? AI-агент в финансовом контуре — это уже не просто интерфейс к данным. Если он может вызвать API, изменить объект, сформировать платёжное распоряжение или обратиться к MCP/tool, он становится отдельным участником цепочки доверия. Поэтому главный вопрос безопасности здесь не в том, насколько «умна» модель, а в том, какие полномочия ей делегированы, кем они выданы и кто в итоге принимает security decision. Критическая ошибка — переносить полномочия пользователя на агента «как есть». Валидный JWT подтверждает identity и набор claims, но сам по себе не отвечает на вопрос, имеет ли именно этот principal право выполнить именно это действие над конкретным объектом сейчас. Для платёжного контура это особенно важно: authentication ≠ authorization, а capability ≠ permission. Решение о доступе должно приниматься вне LLM — на policy/server-side уровне, с проверкой subject, action, resource, tenant, scope и контекста операции. Практически это означает, что агенту нельзя просто «передать» пользовательский access token и считать задачу решённой. Безопаснее выдавать отдельный ограниченный delegated credential: с конкретным audience, минимальным scope, коротким TTL и привязкой к целевой операции. Для high-impact действий этого всё равно недостаточно: policy layer должен независимо проверить контекст транзакции, object-level authorization, лимиты и необходимость step-up или maker-checker подтверждения. Иначе компрометация agent runtime превращается в компрометацию всего пользовательского контекста.