AI-агент постепенно превращается из функции в корпоративного сотрудника. Он может найти заказ, изменить запись в CRM, вызвать другой сервис, передать задачу следующему агенту или подготовить платёж. Но чем больше самостоятельности получает программа, тем менее убедительно звучит старый вопрос: «Под какой учётной записью она работает?»
В многоагентной системе важнее другое: кто именно выполняет действие, кто выдал ему право и где заканчивается зона его ответственности.
15 октября 2026 года ServiceNow представила AI Passport — криптографически подписанное удостоверение для AI-агентов. Компания описывает его как новый слой авторизации: агент предъявляет паспорт при выполнении операции, а система проверяет его личность, разрешённые инструменты, доступные данные и допустимый тип действия.
Это пока заявленная технология, а не универсальный отраслевой стандарт. ServiceNow указывает, что AI Passport и связанные функции планируется сделать доступными в четвёртом квартале 2026 года. Но сама идея показывает, куда движется корпоративная безопасность: от контроля доступа к системам — к контролю каждого исполняемого шага.

Почему общего API-ключа уже недостаточно
Традиционная схема проста: сервис получает API-ключ или работает под общей сервисной учётной записью. Журнал фиксирует, что операция выполнена этим ключом, но часто не отвечает на более важные вопросы:
- какой именно агент запустил действие;
- по какой причине он это сделал;
- имел ли он право на конкретную операцию;
- кто отвечает за выданные ему полномочия;
- передал ли он задачу другому агенту.
Проблема становится заметнее, когда один сценарий распределяется между несколькими цифровыми исполнителями. Например, агент поддержки находит заказ клиента, отдельный агент проверяет условия возврата, а финансовый агент оформляет выплату. Если все они используют один сервисный аккаунт, расследование инцидента превращается в восстановление цепочки по косвенным признакам.
Отдельное удостоверение должно сделать эту цепочку явной. У каждого агента появляется собственная проверяемая идентичность, владелец и набор ограничений. В идеальной модели журнал показывает не просто «CRM вызвала операцию», а «агент проверки возврата передал запрос финансовому агенту, которому разрешено подготовить выплату до установленного лимита».

Делегирование прав по этапам
Ключевая идея здесь — не выдавать агенту доступ ко всему процессу целиком. Полномочия можно разделить на небольшие шаги и сужать при передаче задачи.
Пример сценария с возвратом
- Агент поддержки получает право найти заказ по идентификатору и прочитать статус доставки.
- Агент проверки может сопоставить заказ с правилами возврата, но не менять финансовые записи.
- Финансовый агент получает право подготовить выплату в пределах лимита, но не отправить деньги.
- Платёжный сервис запускает операцию только после дополнительного подтверждения сотрудника.
Такой подход отличается от модели «дать доступ к CRM» или «разрешить работу с финансовой системой». Полномочие описывается через бизнес-действие: отменить заказ до определённой суммы, создать черновик платежа, изменить только конкретное поле или запросить согласование.
Если агент выходит за пределы разрешений, система может отклонить запрос, потребовать дополнительный контекст, перенаправить задачу человеку или остановить выполнение. ServiceNow также заявляет возможность экстренного отключения агента.
Что делает криптографическая подпись
Подписанное удостоверение позволяет проверить, кто выдал полномочия и менялись ли они после выпуска. Это полезно для аудита и отзыва доступа: организация может точнее связать операцию с конкретным цифровым исполнителем, его владельцем и политикой.
Но криптография не превращает неправильное правило в правильное. Если компании ошибочно разрешили агенту удалять клиентские записи, паспорт лишь надёжно подтвердит это слишком широкое право. Подпись фиксирует полномочия, но не оценивает качество бизнес-логики.
Есть и проблема контекста. Агент может иметь законное право оформить возврат, но неверно понять сообщение клиента, выбрать не тот заказ или принять вредоносную инструкцию из подключённого документа. Поэтому удостоверение не заменяет защиту от prompt injection, тестирование сценариев, фильтрацию данных и человеческое подтверждение критических операций.

Иными словами, «паспорт» отвечает на вопрос «кто и с каким разрешением действует», но не гарантирует, что действие было разумным.
Почему здесь важна независимость от поставщика
ServiceNow связывает AI Passport с более широкой системой управления агентами: каталогом цифровых исполнителей, контролем политик, обнаружением несанкционированных агентов и оценкой их использования. Компания также заявляет, что решение опирается на открытые спецификации и может взаимодействовать с технологиями других поставщиков.
Для рынка это принципиально. Если идентичность агента, политики и журнал операций будут работать только внутри одной платформы, бизнес рискует получить новый закрытый контур зависимости. Обещание открытых спецификаций снижает такой риск, но реальную совместимость предстоит проверять на разных системах управления доступом, облачных сервисах и внутренних приложениях.
Что компании могут сделать уже сейчас
Даже без AI Passport бизнесу стоит вести реестр не только моделей, но и самостоятельных агентов. Для каждого цифрового исполнителя полезно зафиксировать:
- владельца и подразделение, которое отвечает за его работу;
- используемую модель и подключённые инструменты;
- данные, которые агент может читать и изменять;
- действия, доступные без подтверждения человека;
- ограничения по сумме, частоте, времени и типу операции;
- правила передачи задачи другому агенту;
- способ мгновенного отзыва полномочий;
- журнал, позволяющий восстановить всю цепочку решений.
Критические действия лучше разделять. Агент может подготовить платёж, но не отправить его; сформировать изменение в CRM, но не опубликовать; предложить возврат, но не перечислить деньги. Чем выше цена ошибки, тем меньше должна быть самостоятельная зона агента.
Главный сдвиг состоит в том, что бизнес начинает управлять не только моделями, но и исполняемыми субъектами. Языковая модель может быть общей, а полномочия — разными. Поэтому вопрос «какая модель используется?» всё чаще будет уступать место вопросу «какой агент сейчас действует, на каком основании и кто отвечает за его следующий шаг?».



