Microsoft Project Perception: как руководителю ограничить риск AI-агентов

19 октября 2026 года Microsoft сообщила о расширении Project Perception для защиты корпоративных AI-агентов. Компания предлагает учитывать агента как отдельного участника рабочего процесса: он получает доступ к данным, вызывает инструменты и выполняет действия от имени организации. Руководителю важно заранее определить границы этих действий. Какие сведения агент видит во время конкретной задачи? Кто подтверждает исключение? По каким записям команда восстановит ход работы, если результат вызовет вопросы?

В материалах Microsoft описаны отдельная идентичность агента, Dynamic Permissions, Dynamic Agent Risk, Dynamic Conditional Access и Guardian Agents. Эти названия стоит перевести на язык рабочего процесса до закупки или настройки платформы. Ниже разберём, как назначить владельца агенту, ограничить полномочия, выбрать сигналы риска и проверить схему на небольшом пилоте. Доступность конкретных функций в вашем контуре нужно уточнять отдельно.

Что Microsoft объявила 19 октября 2026 года

Microsoft расширила Project Perception для защиты «agentic insider»: агента, который работает внутри корпоративной среды и получает доступ к приложениям, данным или инструментам. В официальных публикациях компания описывает связку сигналов о действиях агента, контекста задачи и мер защиты. Такой подход позволяет пересматривать решение о доступе по мере работы агента.

Отдельная идентичность помогает связать действие с конкретным агентом и его владельцем. Dynamic Permissions описывает права, ограниченные задачей и временем. Dynamic Agent Risk учитывает изменение обстановки во время выполнения работы. Dynamic Conditional Access и Guardian Agents дополняют эту схему мерами управления и наблюдения. За подробным описанием компонентов лучше обращаться к двум официальным публикациям Microsoft в блоке источников.

Business Today отдельно сообщило о расширении Project Perception. Это независимое подтверждение самого инфоповода. Технические детали в статье ниже опираются на официальные материалы Microsoft. Сообщение о развитии продукта не означает, что весь описанный набор уже доступен каждой компании. Перед внедрением уточните поддержку функций, требования к окружению и условия использования у поставщика.

Зачем агенту отдельная идентичность

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

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

Создайте для сценария отдельную идентичность и назначьте владельца процесса. Запишите, к каким системам агент обращается, какие данные читает и какие поля меняет. Добавьте ответственного за технические права и сотрудника, который принимает спорные решения. Тогда запись в журнале связывает действие с агентом, задачей и конкретным маршрутом согласования.

Идентичность сама по себе не заменяет контроль. Она даёт основу для правил: доступ можно выдать определённому агенту, ограничить по назначению, а затем проверить его запросы. При подключении нового инструмента пересматривайте этот список вместе с владельцем процесса.

Dynamic Permissions: права под текущую задачу

Dynamic Permissions в описании Microsoft связывает разрешения с задачей и временем её выполнения. Для бизнеса смысл прост: агенту дают доступ к тем действиям, которые нужны для конкретного маршрута. После завершения работы или изменения контекста права можно пересмотреть.

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

Перед запуском сценария ответьте на пять вопросов:

1. Какую задачу агент выполняет и какой результат передаёт сотруднику?
2. Какие источники данных нужны для результата?
3. Какие поля и объекты агент вправе создавать или менять?
4. Когда доступ заканчивается или требует повторной проверки?
5. Где команда увидит исходные данные, вызванные инструменты и исключения?

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

Запишите ответы рядом с настройками интеграции. Если агенту понадобится новый API, владелец процесса сможет сравнить запрос с исходной задачей. Принцип разделения идентичности, политики доступа и аудита также разобран в статье о контроле доступа AI-агентов к API через Apollo GraphOS Agent Services. В контексте Project Perception к этой схеме добавляется пересмотр прав во время работы.

Dynamic Agent Risk: риск меняется вместе с контекстом

Даже корректно запущенный сценарий может встретить неожиданный ввод. В письме окажется инструкция, адресованная агенту; в карточке появится новая внешняя ссылка; инструмент попросит доступ к другому разделу системы. Microsoft описывает Dynamic Agent Risk как оценку по сигналам из идентичности, данных, среды выполнения и активности агента.

Руководителю не нужна оценка ради оценки. Нужна заранее согласованная реакция на наблюдаемый сигнал. Например, агент поддержки обычно читает одно обращение и готовит один черновик. Если он внезапно запрашивает массовую выгрузку клиентских данных, система должна зафиксировать событие и применить установленное ограничение. Команда затем проверит, было ли это ошибкой маршрута, вредоносной инструкцией во входящем тексте или разрешённой задачей, которую забыли описать.

Составьте короткую шкалу реакции для своего процесса. Низкий уровень может означать запись события для последующего просмотра. Более серьёзное отклонение может требовать подтверждения сотрудника перед записью или отправкой данных. Для критического действия предусмотрите остановку задачи и передачу материалов ответственному. Конкретные пороги определяют ваши данные, системы и допустимый ущерб; универсальной шкалы для всех компаний здесь нет.

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

Такой разбор дополняет материал о границах действий и контроле AI-агентов. Агент может собрать сведения и подготовить вариант решения. Разрешение на действие задаёт политика процесса, а сотрудник получает данные для проверки спорного шага.

Dynamic Conditional Access и Guardian Agents в рабочей схеме

Dynamic Conditional Access в описании Microsoft связан с пересмотром условий доступа по текущему контексту. Для проектной команды это повод проверить, что правило реагирует на изменение обстановки во время задачи. Доступ, подходящий для чтения обычной карточки, может оказаться чрезмерным после появления чувствительного вложения или необычного вызова инструмента.

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

Возьмите один тестовый маршрут и составьте таблицу из трёх колонок: «обычное действие», «подозрительное отклонение», «реакция». Например: агент ищет договор по номеру заявки; затем пытается прочитать соседний раздел с личными делами сотрудников; правило закрывает запрос и передаёт событие администратору. Такая таблица помогает обсуждать защиту без общих обещаний и даёт команде сценарий для проверки настроек.

Журнал действий: что понадобится при разборе ошибки

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

Заранее определите состав журнала. Сохраняйте идентификатор агента, время, источник задания, обращения к системам, итоговое действие и сработавшие ограничения. Для данных с ограниченным доступом согласуйте срок хранения и круг сотрудников, которые могут просматривать записи. Журнал должен помогать восстановить решение, не открывая лишние сведения всей команде.

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

Где пригодится мультиагентный контур

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

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

Мультиагентная схема оправдана, когда роли действительно различаются и результат каждого шага можно проверить. Для короткой классификации обращения достаточно одного агента с ясными ограничениями. Усложнение архитектуры добавляет новые точки передачи данных и новые события, которые придётся учитывать в журнале.

План проверки на ближайшие две недели

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

Затем подготовьте отдельную идентичность, минимальный набор прав и журнал. Проверьте обычный пример и несколько отклонений: неверное вложение, запрос к запрещённому разделу, попытку записи без подтверждения. Для каждого случая зафиксируйте ожидаемую реакцию до теста. Так команда увидит, совпадает ли настройка с принятой политикой.

На второй неделе запустите ограниченный пилот под наблюдением владельца процесса. Считайте корректно подготовленные карточки, исключения, время проверки сотрудником и случаи, когда доступ пришлось менять. Сравните результаты с исходной ручной работой. Расширяйте полномочия только после разбора ошибок и повторной проверки правил.

В этой новости ценность для руководителя состоит в управляемом маршруте: известный агент, ограниченные права, пересмотр риска и запись действий. Project Perception показывает направление развития корпоративной защиты; практическую пригодность конкретных функций и настроек подтвердит пилот в вашем окружении.

Timeweb: not-applicable

Материал посвящён функциям и принципам корпоративной защиты Microsoft. Дополнительный серверный шаг не даёт читателю конкретного действия в этом сценарии, поэтому инфраструктурную рекомендацию здесь не добавляем.

Источники

• Microsoft Security: Agents are your newest insiders. Security must move at their speed — официальный материал от 19 октября 2026 года.
• Microsoft: Securing the agentic insider — официальное описание Project Perception и Guardian Agents.
• Business Today: Microsoft expands Project Perception — независимое подтверждение инфоповода от 19 октября 2026 года.

Если хочешь внедрить ИИ агентов в свой бизнес, но не знаешь с чего начать, пиши мне в телеграм t.me/berdoff, я проведу бесплатную консультацию, поделюсь своим опытом.