Сколько прав доступа действительно нужно вашему AI-ассистенту?

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

Поручить AI разбирать почту, готовить встречи и следить за работой уже кажется вполне естественным. Сомнения возникают в момент нажатия кнопки «Авторизовать». Сколько он сможет увидеть? Что он сможет делать от вашего имени? Сможете ли вы потом отозвать этот доступ?

Недавнее обсуждение вывело эти вопросы на первый план. В интервью, опубликованном Business Insider 9 октября, генеральный директор XMTP Labs Шейн Мак рассказал, что его персональный финансовый агент отправил отчёт в корпоративный Slack компании. Статья представляет собой отредактированный рассказ от первого лица, а не независимый технический аудит.

Интервью затем опубликовали ссылку на Reddit, в разделе r/technology. В обсуждении одни выступили против того, чтобы давать AI доступ к чувствительной информации, другие спрашивали, почему личный и рабочий аккаунты вообще оказались связаны. Эти реакции отражают конкретную тревогу: когда ассистент может и читать информацию, и отправлять сообщения, как пользователю контролировать, куда эта информация уходит?

12 октября видео CNA в TikTok также затронуло вопрос, не дают ли пользователи AI-агентам слишком много прав. Согласно описанию видео, речь шла о том, понимают ли люди, какие права доступа они предоставляют.

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

Разбор почты и отправка писем требуют разных прав

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

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

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

Начните с трёх вопросов:

• Что он может читать? Какой аккаунт, за какой период, какие материалы?
• Что он может делать? Только искать и читать или также отправлять, изменять и удалять?
• Кому передаётся результат? В текущий диалог или на конкретный личный адрес?

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

Три уровня настраиваются отдельно. Это рекомендация по проектированию задачи; один переключатель не обеспечивает все границы.

Доступ только для чтения тоже требует понятного назначения

Доступ только для чтения хорошо подходит для первой версии ассистента: сначала упорядочить информацию, дать человеку проверить результат, а затем постепенно добавлять действия.

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

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

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

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

Дайте ассистенту набор возможностей, который можно объяснить

В OOMOL эти решения можно закрепить на уровне подключений к аккаунтам и объёма вызовов интерфейсов. Документация по управлению доступом отдельно описывает объём авторизации у Provider, права доступа подключения и разрешённые к вызову действия.

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

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

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

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

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

Начните авторизацию с небольшой, но полезной задачи

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

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

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

Чтобы начать, настройте в OOMOL Connections подключение, необходимое для задачи, сузьте разрешённые действия по руководству по управлению доступом и дайте ассистенту чёткий запрос:

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

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