ИИ-агент может приносить пользу, не превращаясь в хранилище секретов компании. Безопасная архитектура отделяет рассуждение от учётных данных: агент запрашивает разрешённую операцию, доверенный сервис проверяет запрос и только затем использует нужный секрет.
Прямой доступ создаёт лишний риск
Агенты обрабатывают недоверенный контент. Письмо клиента, загруженный файл, веб-страница или найденная заметка могут содержать инструкции, которые конфликтуют с задачей оператора. OpenAI описывает инъекцию промпта как социальную инженерию против ИИ-систем. Поэтому простой фильтр подозрительных слов не способен распознать все замаскированные команды.
Если агент видит платёжный ключ, токен почты, облачную учётную запись или пароль базы, успешная манипуляция превращает ошибку работы с контентом в инцидент. Секрет внутри системного промпта не становится защищённым. Модель всё равно получает его и может передать значение в ответ, аргументы инструмента, журнал или непредусмотренное действие.
Базовый чек-лист защиты данных компании помогает задать правильный порядок вопросов. Сначала нужно понять, что агент может прочитать и изменить, а также какое действие сложнее всего отменить. Уже после этого выбирают модель и интерфейс.
Передавайте возможности, а не пароли
Агенту лучше выдавать конкретные операции: подготовить черновик, найти разрешённую запись или сформировать заявку на платёж. Учётные данные остаются в узком сервисе-посреднике. Он проверяет личность, область доступа, аргументы и политику, прежде чем обратиться к рабочей системе.
- Ограничьте область: откройте минимальную операцию и только нужные данные.
- Проверяйте параметры: отклоняйте неожиданные адреса, поля, форматы и объёмы.
- Разделяйте среды: тестовый агент не должен наследовать рабочие полномочия.
- Сокращайте срок: временный делегированный доступ безопаснее постоянного токена.
- Ведите журнал: фиксируйте запрос, решение политики и результат без записи секрета.
Такая схема упрощает сопровождение. Учётные данные можно менять без переписывания промптов, а скомпрометированную операцию можно отключить отдельно. Материал о том, как снижать риск выдуманных фактов ИИ-агентов, показывает тот же принцип: надёжность строится на проверяемом процессе, а не на обещании модели.
Подтверждайте действия с последствиями
Некоторые операции требуют подтверждения даже после автоматической проверки. Перевод денег, удаление данных, публикация, изменение прав или контакт с новым адресатом способны заметно повлиять на бизнес. В рекомендациях OpenAI по устойчивости агентов к инъекциям предлагаются несколько уровней защиты, ограниченный доступ и подтверждение важных действий.
Окно подтверждения должно простым языком показывать цель, получателя и эффект. Общая кнопка согласия после длинного диалога слаба: человек может не понимать, что именно будет выполнено. После подтверждения система должна использовать уже проверенный запрос, а не просить агента заново сформировать команду.
Рутинные безопасные случаи может пропускать детерминированная политика. Необычный или неоднозначный запрос должен останавливаться и уходить ответственному сотруднику. Это не недостаток автоматизации, а граница между полезным ускорением и неконтролируемыми полномочиями.
Готовьтесь обнаружить проблему и восстановиться
Одной профилактики недостаточно. Стоит наблюдать за отклонёнными запросами, необычными последовательностями инструментов, попытками расширить доступ и неожиданными направлениями вывода. У команды должен быть понятный способ быстро отключить возможность посредника и заменить затронутые учётные данные.
Разбор о том, почему ИИ ошибается уверенно, напоминает о важной дисциплине: после смены модели, промпта, инструмента или маршрутизации поведение и права нужно проверять заново. Старая проверка не доказывает безопасность новой конфигурации.
Начните с перечня возможностей. Уберите секреты из промптов и доступного агенту хранилища. Чувствительные вызовы поместите за посредником. Для каждого вызова определите допустимый результат, отказ и ответственного за исключение. Проверьте, что журнал помогает расследованию, но не становится новым хранилищем секретов. Затем разыграйте попытку получить лишние права, ошибочный адрес назначения и отзыв доступа. Такая репетиция показывает пробелы до того, как их обнаружит реальный инцидент.
После запуска регулярно сравнивайте заявленную политику с фактическими вызовами. Удаляйте неиспользуемые возможности, сокращайте область доступа и проверяйте владельцев интеграций. Безопасность агента должна сопровождать изменение процесса, а не оставаться разовой настройкой при запуске.
Полезно назначить владельца каждой возможности и срок её пересмотра. Когда процесс меняется, старое разрешение не должно автоматически переноситься на новый источник, получателя или тип данных. Владелец подтверждает необходимость операции и проверяет, что более узкого доступа действительно недостаточно.
Частые вопросы
По умолчанию лучше не давать. Посредник может хранить учётные данные, проверить запрос, выполнить узкую разрешённую операцию и вернуть агенту только допустимый результат.
Фильтр отсечёт часть очевидных атак, но не станет полной границей для скрытых и убедительных инструкций. Нужны ограничение прав, изоляция, проверка и подтверждение.
Подтверждение важно для труднообратимых операций, влияющих на деньги, данные, права, публикацию, общение с клиентом или другой чувствительный результат бизнеса.
Фиксируйте проверенного инициатора, запрошенную возможность, решение политики, цель операции и результат, но не записывайте сами секреты и лишние чувствительные данные.
Если нужна внешняя оценка текущей схемы, закажите консультацию «Открытого пути».
