Traefik STP: как отличить журнал ИИ-агента от доказательства

Sovereign Trust Plane в Traefik Hub заявлен как способ связать полномочия ИИ-агента, решение политики и проверяемую историю разрешений и отказов. Но целостная история решения ещё не доказывает правильность бизнес-операции. Для приёмки нужны два отдельных результата: можно проверить, что шлюз разрешил, и можно подтвердить, что приложение действительно сделало.

Сентябрьский план и текущая доступность различаются

Пресс-релиз Traefik Labs от 15 сентября 2026 года представлял STP в Traefik Hub и планировал GA к 30 сентября. Однако текущая страница Verifiable Agent Evidence описывает Delegate, Authorize и Prove как early access. Поэтому первоначальный план нельзя выдавать за подтверждённый всеобщий GA.

В разборе архитектуры от 14 сентября производитель разделяет выдачу полномочий identity provider, проверку внешней политикой и запись решения. Это описание предлагаемой архитектуры, а не проведённый нами независимый аудит. Возможности Traefik Hub нельзя автоматически приписывать бесплатному Traefik Proxy.

Какие вопросы должен выдержать разбор действия

Представим вымышленного агента, который согласует изменение срока выполнения заявки. Пользователь дал ему ограниченное поручение, политика разрешила действие, а система записала новый срок. Если позже обнаружится неправильная дата, фраза «агент был авторизован» не объяснит, на каком этапе возникла ошибка.

Это наша карта свидетельств для одной операции. Она не является списком готовых функций STP. Последние строки намеренно относятся к бизнес-приложению: шлюзовое разрешение не заменяет проверку результата и правил самой заявки.

Независимый witness отвечает за определённую границу доверия

В описании производителя witness получает криптографические checkpoints и proofs, а не содержимое запросов. Он помогает проверять ранее засвидетельствованную историю при отдельном управлении. Это более точное утверждение, чем обещание «лог невозможно изменить при любых условиях».

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

Отказ тоже должен иметь связь с задачей

Для учебной заявки заранее опишите отказ: агенту нельзя изменить срок этого объекта или требуется решение человека. Проверяющий должен увидеть применимое основание и отсутствие неподходящего изменения. При этом содержание ответа внешнему участнику определяйте по его правам, не раскрывая ему лишний внутренний контекст.

Не используйте текущую редакцию политики как единственное объяснение вчерашнего решения. В разборе нужны сведения, применявшиеся в момент действия. Их состав и правила хранения согласуют заранее, с учётом доступа к данным. Целостность записи не исправляет неполное исходное событие.

Как принять такую интеграцию

1. Выберите одну разрешённую бизнес-операцию и отдельный сценарий отказа.
2. Опишите цепочку пользователя, агента, инструмента и backend.
3. Укажите, кто выдаёт полномочия и кто принимает решение политики.
4. Согласуйте состав записи и независимый способ её проверки.
5. Свяжите решение с фактическим результатом приложения.
6. Проверьте текущий статус и доступность всех нужных компонентов выбранной поставки.

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