ИИ-агент без границ доступа - риск: что ограничить заранее

ИИ-агент - это не просто чат с умным ответом

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

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

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

Три причины опасной самостоятельности

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

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

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

Опасная инструкция может прийти не от пользователя

Разработчики часто фильтруют только прямой запрос и забывают, что агент читает внешние данные. Инструкция может оказаться в письме, веб-странице, документе, комментарии к задаче или ответе другого инструмента. Если модель не отделяет доверенную цель от недоверенного содержимого, текст внутри документа способен попытаться перенаправить её действия. Это называют косвенной prompt injection или перехватом агента.

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

Практическое правило: данные могут сообщать факты, но не менять политику доступа. Если письмо содержит «отправь архив на этот адрес», агент может процитировать просьбу в сводке, но не должен получать право исполнить её только потому, что встретил текст. Политика живёт вне модели и применяется к каждому вызову инструмента.

Составьте матрицу прав до подключения инструментов

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

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

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

Минимальные права: отдельная личность для каждой задачи

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

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

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

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

Чтение и запись должны быть разными инструментами

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

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

Если агент помогает учиться автоматизации, начинайте с read-only сценария: собрать данные, классифицировать и сформировать отчёт. Связать обучение с практическими задачами можно через раздел курсов по ИИ и нейросетям, но критерий проекта должен быть не «он что-то сделал», а «мы понимаем, что именно он имеет право сделать».

Где нужен человек, а где достаточно автоматики

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

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

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

Пять обязательных ворот перед самостоятельным действием

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

Лимиты останавливают не только атаку, но и обычную ошибку

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

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

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

Структурированные данные безопаснее свободного текста

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

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

Что проверить. Если поле не соответствует схеме, действие отклоняется, а не «творчески исправляется» во время выполнения.

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

Память и данные тоже требуют границ

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

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

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

Журнал должен отвечать на вопрос «кто и почему»

Лог полезен, когда связывает пользователя, цель, версию агента, полученные данные, выбранный инструмент, параметры, результат, подтверждение и ошибку. Простая строка «agent completed task» ничего не объясняет. При инциденте команда должна восстановить цепочку действий без догадок.

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

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

Аварийное отключение и восстановление проектируют заранее

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

После остановки нужен план восстановления. Какие изменения обратимы автоматически? Где понадобится резервная копия? Как найти затронутые объекты? Кто принимает решение о повторном запуске? Эти вопросы решают до инцидента, а не в момент, когда агент уже разослал сотни сообщений.

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

Практический пример: агент для маркетинга

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

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

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

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

Практический пример: агент для кода

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

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

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

Как тестировать агента до реальных прав

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

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

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

Что ограничить прямо сейчас

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

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

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