Copilot Cowork: как безопасно поручать ИИ действия

Обычный чат-бот предлагает текст. Агентный режим может открыть сайт, изменить файл, отправить сообщение или запустить цепочку действий от имени пользователя. Ошибка в ответе неприятна, но ошибка в действии уже меняет внешнюю систему. Поэтому главный вопрос для Copilot Cowork и похожих инструментов звучит не «насколько умна модель», а «где она остановится и попросит подтверждение».

Microsoft прямо описывает Cowork как предварительную версию и предупреждает о неверно понятых инструкциях, prompt injection, финансовых и приватностных рисках. Эти ограничения полезно перевести из языка документации в рабочие правила.

Чем агент отличается от генератора черновиков

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

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

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

Какие действия требуют остановки

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

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

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

Многофакторную проверку, CAPTCHA и подтверждение платежа Microsoft относит к шагам, которые агент должен передать человеку. Это не помеха автоматизации, а явная точка принятия решения.

Почему подтверждение не решает всё

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

Нужен и предварительный просмотр. Черновик может содержать верные факты, но неверный тон, лишнего адресата или фрагмент внутреннего текста. Microsoft советует считать сгенерированные документы и сообщения черновиками до проверки. Это особенно важно, когда агент собрал ответ из неполных или устаревших корпоративных данных.

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

Prompt injection приходит из обычного контента

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

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

Содержимое страницы следует считать данными, а не новым распоряжением. Архитектурно это означает разделение каналов: инструкция пользователя имеет один уровень доверия, текст из внешнего документа — другой. Модель может использовать внешний текст как факт для анализа, но не должна автоматически превращать его в команду.

Как формулировать задачу агенту

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

• какие источники разрешено читать;
• какой результат нужно подготовить;
• что можно изменить без дополнительного вопроса;
• перед какими действиями нужна остановка;
• какие данные нельзя передавать наружу;
• как пользователь проверит готовый результат.

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

Практическая матрица контроля

Кто отвечает за результат

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

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

Безопасная агентная работа получается не тогда, когда система никогда не ошибается. Она получается, когда ошибка остаётся черновиком, а не превращается в отправленное письмо, удалённый файл или подтверждённый платёж.