Agent Trust Cards: что такое ATC/1.0 и зачем доверять ИИ-агентам

ИИ-агенты всё чаще сами читают файлы, ходят в сеть, запускают команды. Вопрос «можно ли этому агенту верить» становится не теоретическим. Нужен формат, который скажет: кто выпустил агента, что ему разрешено делать, насколько он рискованный и как это проверить. В середине 2026 года появилось сразу несколько похожих идей — одна из них оформилась в полноценную спецификацию ATC/1.0.

Суть: что такое Agent Trust Card

Agent Trust Card — это конверт с данными об агенте, подписанный доверенным центром (CA). Внутри — идентичность, список разрешений, оценка риска и доказательства аудита. Подпись гарантирует, что данные не подделаны.

В ATC/1.0 определены 10 контролов: 8 обязательных и 2 опциональных. Вот они:

Если вы собираете агентный рантайм, MCP-сервер или агентный маркетплейс — вам нужен такой формат. ATC/1.0 уже содержит JSON Schema, референсную реализацию на Node.js и 5 тестовых векторов.

Почему стандарт важнее спора об авторстве

Автор спецификации напоминает: неважно, кто придумал концепцию первым. Важно, кто выпустил формальную, версионированную и проверяемую спецификацию. Споры о приоритете в публичном поле не выигрываются — интернет не логирует намерения. А вот спецификацию можно запустить, проверить на тест-векторах и внедрить. Это факт.

Рынок уже сходится к одной проблеме с разных сторон. Вот что появилось за пару месяцев:

• A2A Agent Card (Google) — манифест возможностей, без криптографического доверия.
• AgentCards (академический проект) — идентичность и credentials.
• OpenA2A AIP (интернет-черновик) — Ed25519, поведенческое доверие, DID.
• OATI — более широкая схема: идентичность, делегирование, policy, подписанные чеки.
• ATC — первое публичное использование названия с полной связкой CA + Ed25519 + отзыв + capabilities + оплата.

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

Криптографическое ядро

В ATC/1.0 обязательны три вещи:

• Ed25519 (RFC 8032) — быстрые детерминированные подписи, поддержка есть в любой стандартной библиотеке.
• RFC 8785 JCS — единственный настоящий стандарт канонического JSON.
• SHA-256 — хэш полезной нагрузки.

Есть тонкость. Поле signed_payload_hash находится внутри конверта, но не может быть частью подписываемых данных — нельзя хэшировать сумму, которая включает собственный хэш. Спецификация решает это просто: перед канонизацией оба поля — signature и signed_payload_hash — устанавливаются в пустые строки. Потом вычисляется хэш, потом подпись, и оба значения сохраняются.

Что именно описывает манифест возможностей

Контрол ATC-003 перечисляет, что агенту позволено, по пяти категориям:

• Файловая система — чтение/запись: none, own_dir, temp_dir, home_dir, system, all.
• Сеть — egress: none, allowlist, all; ingress: none, bound_ports, all.
• Shell — exec и spawn: none, sandboxed, unrestricted.
• Credentials — чтение env и файлов: none, allowlist, all.
• Процессы — subprocess: none, sandboxed, unrestricted; signals: none, own, all.

Это прямое соответствие тому, что рекомендуют в чек-листе OWASP MCP. ATC/1.0 — конкретный формат для этой рекомендации.

Trust score: рекомендация, а не приговор

Оценка доверия в ATC-005 идёт от 0 до 10 и преобразуется в уровень риска: 8-10 — низкий, 5-7 — средний, 2-4 — высокий, 0-1 — критический.

При этом спецификация жёстко требует decision_authority: "consumer". Это значит: карточка — рекомендация, а финальное решение остаётся за рантаймом, который запускает агента. CA не может переопределить политику безопасности хоста.

Отзыв и оффлайн-проверка

Для отзыва сертификатов есть три способа: OCSP, CRL и simple_json (подписанный CA список на JSON). Последний подходит для небольших систем — именно он используется в проекте MarketNow.

Проверка ATC может работать оффлайн: если у верификатора есть публичный ключ CA, он проверяет подпись без обращения в сеть. Но если в карточке указано revocation_check_required: true, проверяющий обязан получить свежий список отзыва, иначе — отклонить.

Что делать, если вы планируете внедрение

1. Изучите спецификацию и тест-векторы. Они в репозитории, 5 векторов покрывают минимальный, подделанный, просроченный, неверный CA и capabilities.
2. Подключите проверку подписи. Реализация на Node.js занимает около 200 строк и использует только стандартную библиотеку плюс пакет canonicalize для JCS.
3. Решите, как обрабатывать отзыв. Для старта подойдёт simple_json, для высокозащищённых сценариев — OCSP.
4. Не путайте рекомендацию с решением. Рантайм всегда может отказать агенту, даже если у того высокий trust score.

Ошибка — думать, что достаточно одного «доверенного» агента. В реальности агенты делегируют задачи другим агентам, и нужна цепочка доверия. Для этого в ATC есть опциональный контрол делегирования — родительская карточка может сужать права дочерней.

Вывод

ATC/1.0 — не первая попытка описать доверие к агентам, но на данный момент это одна из наиболее формальных и проверяемых. Если вы строите инфраструктуру для ИИ-агентов, присмотритесь к спецификации до того, как изобретать свой формат. Споры о приоритете забудутся, а код, который можно запустить, останется.