Один ключ на всю команду: от чьего имени действует ваш ИИ-агент

Общий ключ упрощает подключение ИИ-агента к рабочим сервисам: один раз настроили доступ — пользуется вся команда. Цена удобства появляется в момент действия: чьи документы он читает и от чьего имени отправляет результат? Эти два вопроса стоит решить до выбора модели.

Два владельца доступа

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

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

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

Проверка на двух учебных аккаунтах

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

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

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

Отдельная инструкция по идентификации предупреждает: обычный API-ключ может идентифицировать клиентское приложение, а не каждого сотрудника. Для личного доступа требуется проверенная идентичность человека; переданный из интерфейса произвольный user ID её не заменяет.

Критерий выбора простой: личные данные — доступ конкретного человека; общий ресурс — отдельная служебная запись и проверка права на действие.

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