Не давайте ИИ-агенту ключи от всего: настройте доступ до запуска (2)
Автор: Dr.White SAV AI | Дата: 26.10.2026 | Время чтения: 5 мин
ИИ-агент может не только отвечать на вопросы, но и выполнять действия: создавать задачи, читать документы, отправлять письма или менять данные в сервисах. Именно поэтому запускать его под своей учётной записью — плохая идея. Если агент ошибётся, скомпрометируется или воспримет вредную инструкцию из документа как команду, последствия затронут все ресурсы, к которым у вас есть доступ.
*Принцип настройки: отдельная идентичность и минимум полномочий.* Агенту нужна собственная учётная запись или сервисная идентичность, а не ваш личный логин. Выдавайте только те разрешения, без которых конкретный сценарий не работает. Если помощник должен читать заявки, ему не нужны права удалять клиентов, менять настройки рабочего пространства и выгружать всю базу.
*1. Опишите задачу до выдачи доступа.* Сформулируйте, что агенту разрешено делать, с какими данными и в каких системах. Например: читать новые обращения из одной очереди и готовить черновики ответов. Отправка сообщения клиенту, изменение статуса сделки и удаление записи — уже отдельные действия, требующие отдельного разрешения. Чем точнее границы задачи, тем проще проверить, какие доступы действительно необходимы.
*2. Разделите чтение и изменение.* По возможности начните с режима только для чтения. Затем разрешите создавать черновики, но не отправлять их автоматически. Изменение данных и внешние действия добавляйте по одному, после тестирования. Такая лестница снижает риск: ошибочный вывод агента сначала остаётся черновиком, а не превращается в письмо клиенту или запись в CRM.
*3. Выдавайте доступ точечно.* Настройте разрешения на конкретный проект, папку, таблицу или очередь, а не на весь аккаунт. У сервисной учётной записи не должно быть прав администратора, если задача этого не требует. Отдельно проверьте права на создание, редактирование, удаление и передачу данных: доступ «к системе» часто скрывает существенно разные возможности.
*4. Не храните секреты в инструкции.* Пароли, токены и ключи API нельзя помещать в промпт, общий документ или код, который доступен широкому кругу людей. Используйте предусмотренное платформой безопасное хранилище секретов и выдавайте агенту только нужный ключ. Задайте срок действия, если он доступен, и заранее определите, как отозвать доступ. Ключ, который нельзя быстро отключить, — плохой ключ для эксперимента.
*5. Поставьте подтверждение перед необратимыми действиями.* Отправка письма, публикация поста, возврат денег, удаление или массовое обновление данных должны требовать подтверждения человека. Особенно важно это, когда действие затрагивает клиента, деньги или публичную информацию. В интерфейсе подтверждения показывайте, что именно агент собирается сделать, с какими данными и в каком объёме. Кнопка «подтвердить» без понятного описания не создаёт осмысленного контроля.
Есть ещё один риск: агент может читать внешние документы, письма и страницы. В них могут встретиться фразы, похожие на инструкции: например, просьба передать данные или проигнорировать прежние ограничения. Такой текст нужно считать содержимым источника, а не автоматически исполняемой командой. Но одной системной инструкции недостаточно. Защитой служат ограниченные права, фильтрация входных данных и запрет на чувствительные действия без проверки человеком.
*6. Проведите тест на безопасных данных.* До подключения к рабочей среде проверьте обычный сценарий, ошибочный запрос и попытку выйти за границы задачи. Попросите агента обработать документ с посторонней инструкцией. Убедитесь, что он не может открыть соседние проекты, выгрузить лишние записи или выполнить действие без согласования. Тестируйте не только правильность ответа, но и реальные права, которые получил агент.
*7. Включите журналирование и установите лимиты.* Сохраняйте, какие данные агент запрашивал, какие действия предлагал и что было выполнено. Ограничьте количество операций, объём выгрузки и частоту запросов, если сервис это позволяет. Уведомления о массовом изменении или необычной активности помогут заметить проблему раньше, чем она станет инцидентом. Определите ответственного, который регулярно пересматривает
*Принцип настройки: отдельная идентичность и минимум полномочий.* Агенту нужна собственная учётная запись или сервисная идентичность, а не ваш личный логин. Выдавайте только те разрешения, без которых конкретный сценарий не работает. Если помощник должен читать заявки, ему не нужны права удалять клиентов, менять настройки рабочего пространства и выгружать всю базу.
*1. Опишите задачу до выдачи доступа.* Сформулируйте, что агенту разрешено делать, с какими данными и в каких системах. Например: читать новые обращения из одной очереди и готовить черновики ответов. Отправка сообщения клиенту, изменение статуса сделки и удаление записи — уже отдельные действия, требующие отдельного разрешения. Чем точнее границы задачи, тем проще проверить, какие доступы действительно необходимы.
*2. Разделите чтение и изменение.* По возможности начните с режима только для чтения. Затем разрешите создавать черновики, но не отправлять их автоматически. Изменение данных и внешние действия добавляйте по одному, после тестирования. Такая лестница снижает риск: ошибочный вывод агента сначала остаётся черновиком, а не превращается в письмо клиенту или запись в CRM.
*3. Выдавайте доступ точечно.* Настройте разрешения на конкретный проект, папку, таблицу или очередь, а не на весь аккаунт. У сервисной учётной записи не должно быть прав администратора, если задача этого не требует. Отдельно проверьте права на создание, редактирование, удаление и передачу данных: доступ «к системе» часто скрывает существенно разные возможности.
*4. Не храните секреты в инструкции.* Пароли, токены и ключи API нельзя помещать в промпт, общий документ или код, который доступен широкому кругу людей. Используйте предусмотренное платформой безопасное хранилище секретов и выдавайте агенту только нужный ключ. Задайте срок действия, если он доступен, и заранее определите, как отозвать доступ. Ключ, который нельзя быстро отключить, — плохой ключ для эксперимента.
*5. Поставьте подтверждение перед необратимыми действиями.* Отправка письма, публикация поста, возврат денег, удаление или массовое обновление данных должны требовать подтверждения человека. Особенно важно это, когда действие затрагивает клиента, деньги или публичную информацию. В интерфейсе подтверждения показывайте, что именно агент собирается сделать, с какими данными и в каком объёме. Кнопка «подтвердить» без понятного описания не создаёт осмысленного контроля.
Есть ещё один риск: агент может читать внешние документы, письма и страницы. В них могут встретиться фразы, похожие на инструкции: например, просьба передать данные или проигнорировать прежние ограничения. Такой текст нужно считать содержимым источника, а не автоматически исполняемой командой. Но одной системной инструкции недостаточно. Защитой служат ограниченные права, фильтрация входных данных и запрет на чувствительные действия без проверки человеком.
*6. Проведите тест на безопасных данных.* До подключения к рабочей среде проверьте обычный сценарий, ошибочный запрос и попытку выйти за границы задачи. Попросите агента обработать документ с посторонней инструкцией. Убедитесь, что он не может открыть соседние проекты, выгрузить лишние записи или выполнить действие без согласования. Тестируйте не только правильность ответа, но и реальные права, которые получил агент.
*7. Включите журналирование и установите лимиты.* Сохраняйте, какие данные агент запрашивал, какие действия предлагал и что было выполнено. Ограничьте количество операций, объём выгрузки и частоту запросов, если сервис это позволяет. Уведомления о массовом изменении или необычной активности помогут заметить проблему раньше, чем она станет инцидентом. Определите ответственного, который регулярно пересматривает