Назад в блог

Zero Trust для AI-агентов: никогда не доверяй агенту и его выводу

Как применить Zero Trust к AI-агентам: identity на каждый вызов, проверка audience и scope, микросегментация и DLP на каждом шаге. Периметр не работает — работает шлюз.

Иллюстрация к материалу: Zero Trust для AI-агентов: никогда не доверяй агенту и его выводу

Периметр не работает для AI-агентов. Агент получает широкие права «на всё», наследует доступ человека и ходит в инструменты автономно — классический castle-and-moat это не ловит. Zero Trust переносит проверку на каждый вызов: никогда не доверяй, всегда проверяй — даже агенту внутри контура.

Почему периметр ломается на агентах

Три причины:

  • Наследование прав. Агент действует от имени человека, но с автономией — его права шире, чем нужно на конкретную задачу.
  • Автономные tool-вызовы. Агент сам решает, куда идти дальше, и может комбинировать инструменты неожиданно.
  • Вывод как данные. Результат одного агента — вход для другого; без проверки это канал для tool poisoning и повышения привилегий.

Периметр проверяет вход в сеть, Zero Trust — каждый шаг агента.

Принципы Zero Trust для агентов

  • Identity на каждый вызов. Человек → агент → tool — вся цепочка с верифицируемой identity, а не «сервисный ключ на всё».
  • Проверка audience и scope на каждый запрос. Токен валидируется не «вообще», а что он выдан именно этому ресурсу (RFC 8707 aud) и с нужным scope.
  • Least privilege по умолчанию. Только нужные tool и поля, узкие представления вместо SELECT *.
  • Предполагай компрометацию. Даже внутри периметра каждый вызов может быть последним до отзыва.

Identity на каждый вызов + audience

MCP-спека 2026 делает это обязательным: OAuth 2.1 + PKCE, resource на обоих этапах, aud в токене, проверка aud == своему идентификатору на каждый HTTP-запрос. Без aud токен с одного сервиса становится ключом к другому — confused deputy.

Для агентов это значит: каждый tool-вызов несёт identity инициатора и агента, а шлюз проверяет её до выполнения.

Микросегментация и least privilege

Разбейте доступ на сегменты:

  • агент видит только свои представления, а не таблицы целиком;
  • tool-набор — минимальный: меньше шума в контексте и меньше поверхности;
  • scope выдаётся по WWW-Authenticate / scopes_supported, узко под задачу, с step-up при 403 insufficient_scope, а не «всё сразу».

Так взлом одного агента не тянет остальных — изоляция как в multi-agent, только на уровне прав.

DLP как часть Zero Trust

Zero Trust без DLP — половина. Инспекция промпта и ответа на HTTP-границе с identity даёт allow/redact/route/block до модели. Без этого least privilege останавливает «куда можно», но не «что можно унести».

Где Codenik: Zero Trust шлюз

Codenik — Zero Trust шлюз для агентов: терминирует вызов, проверяет identity и aud/scope, применяет секреты без попадания в контекст, инспектирует промпт через DLP и пишет identity-bound аудит. Каждый шаг агента проходит через одну точку проверки — периметр не нужен, работает шлюз. Подробнее про MCP-авторизацию — в статье «Авторизация MCP: OAuth 2.1, PKCE».

Короткий вывод

Zero Trust для агентов — это проверка каждого вызова: identity на всю цепочку, audience и scope на каждый запрос, микросегментация и DLP. Периметр не спасает автономного агента — спасает шлюз на каждом шаге.

Источники и дальнейшее чтение