Советы директоров все чаще спрашивают у CEO: как справиться с рисками, связанными с ИИ-агентами? Недавние рекомендации по безопасности ИИ от регуляторов, стандартизаторов и крупных поставщиков подчеркивают один подход: относитесь к агентам как к мощным полуавтономным пользователям и устанавливайте правила на границах взаимодействия с идентичностью, инструментами, данными и результатами.
Вот рабочий план из восьми шагов, который можно внедрить командами и по которому отчитываться.
Ограничение возможностей
Эти шаги помогают задать идентичность и сузить способности агентов.
1. Идентичность и область применения: Считайте агентов полноценными пользователями с четкими задачами
Сейчас агенты часто работают под размытыми, избыточно привилегированными сервисными учетками. Решение простое: обращайтесь с каждым агентом как с нечеловеческим субъектом, применяя те же строгие правила, что и к сотрудникам.
Каждый агент должен запускаться от имени запрашивающего пользователя в нужном тенанте, с правами, ограниченными ролью и регионом этого пользователя. Запрещайте обход через кросс-тенантные трюки. Любые значимые действия требуют явного одобрения человека с зафиксированным обоснованием. Именно так на практике реализуются Google's Secure AI Framework (SAIF) и рекомендации NIST по контролю доступа в ИИ.
Вопрос CEO: Можем ли мы прямо сейчас показать список всех агентов и точно указать, что каждый из них может делать?
2. Контроль инструментов: Фиксируйте версии, одобряйте и ограничивайте инструменты агентов
Фреймворк Anthropic против шпионажа сработал, потому что злоумышленники подключили Claude к гибкому набору инструментов — сканерам, фреймворкам для эксплойтов, парсерам данных — через Model Context Protocol, и эти инструменты не были зафиксированы или защищены политиками.
Защита похожа на управление цепочками поставок:
- Фиксируйте версии удаленных серверов инструментов.
- Требуйте одобрения для новых инструментов, областей доступа или источников данных.
- Запрещайте автоматическую цепочку инструментов без явного разрешения политики.
OWASP в своих рекомендациях отмечает это как чрезмерную автономию агентов и советует меры защиты. Согласно Закону ЕС об ИИ, такая киберустойчивость и сопротивление злоупотреблениям входят в обязательства статьи 15 по обеспечению надежности и кибербезопасности.
Вопрос CEO: Кто одобряет новый инструмент или расширение области для агента? Как это отслеживается?
3. Права по умолчанию: Привязывайте инструменты к задачам, а не к моделям
Распространенная ошибка — выдавать модели долгоживущие учетные данные и полагаться на промты для послушания. SAIF и NIST советуют обратное: учетные данные и области доступа привязывайте к инструментам и задачам, регулярно обновляйте и делайте поддающимися аудиту. Агенты запрашивают узкие возможности через эти инструменты.
На практике это выглядит так: «агент finance-ops-agent может читать, но не писать определенные реестры без одобрения CFO».
Вопрос CEO: Можем ли мы отозвать конкретную возможность у агента, не перестраивая всю систему?
Контроль данных и поведения
Эти шаги фильтруют входы, выходы и ограничивают поведение.
4. Входы, память и RAG: Считайте внешний контент враждебным, пока не доказано обратное
Большинство инцидентов с агентами начинается с подставных данных: отравленной веб-страницы, PDF, email или репозитория, которые вносят вредоносные инструкции. Шпаргалка OWASP по инъекциям промтов и рекомендации OpenAI настаивают на жестком разделении системных инструкций от пользовательского контента и на недоверии к непроверенным источникам извлечения.
На деле это значит проверку перед загрузкой в retrieval или долгосрочную память: новые источники рецензируют, маркируют и интегрируют; отключают постоянную память при ненадежном контексте; прикрепляют происхождение к каждому фрагменту.
Вопрос CEO: Можем ли мы перечислить все внешние источники контента, от которых учатся агенты, и указать, кто их одобрил?
5. Обработка и отображение выходов: Ничего не выполняется только потому, что модель это сказала
В случае Anthropic сгенерированный ИИ-код эксплойтов и дампы учетных данных сразу запустились. Любой выход, способный вызвать побочный эффект, требует валидатора между агентом и внешним миром. OWASP прямо указывает на это в категории небезопасной обработки выходов, как и лучшие практики браузерной безопасности по границам происхождения.
Вопрос CEO: Где в нашей архитектуре оценивают выходы агентов перед запуском или отправкой клиентам?
6. Защита данных во время выполнения: Сначала обезопасьте данные, потом модель
Защищайте данные так, чтобы по умолчанию нечего было раскрывать опасного. NIST и SAIF склоняются к дизайну "безопасному по умолчанию", где чувствительные значения токенизируют или маскируют, а раскрывают только для авторизованных пользователей и сценариев.
В агентных системах это контролируемая политикой детокенизация на границе выхода и логирование каждого раскрытия. Если агент полностью скомпрометирован, ущерб ограничен тем, что позволяет политика.
Здесь ИИ-стек пересекается не только с Законом ЕС об ИИ, но и с GDPR и отраслевыми нормами. Закон ЕС об ИИ требует от поставщиков и внедряющих управление рисками ИИ; токенизация во время выполнения и контролируемое раскрытие — это доказательства активного контроля рисков в продакшене.
Вопрос CEO: Когда агенты работают с регулируемыми данными, защита обеспечивается архитектурой или обещаниями?
Доказательство управления и устойчивости
Последние шаги показывают, что меры работают и продолжают работать.
7. Непрерывная оценка: Не ограничивайтесь разовым тестом — внедрите тестовый арсенал
Исследования Anthropic о спящих агентах развеивают иллюзии о единственных тестах и подчеркивают важность постоянной оценки. Это значит оснастить агентов глубоким мониторингом, регулярно проводить красные команды с adversarial-тестами и подкреплять все надежным логированием и доказательствами, чтобы сбои превращались в регрессионные тесты и обновления политик.
Вопрос CEO: Кто еженедельно пытается сломать наших агентов, и как их выводы влияют на политики?
8. Управление, инвентаризация и аудит: Ведите учет в одном месте
Фреймворки безопасности ИИ акцентируют инвентаризацию и доказательства: компании должны знать, какие модели, промты, инструменты, датасеты и векторные хранилища у них есть, кто за них отвечает и какие решения по рискам приняты.
Для агентов это живой каталог и унифицированные логи:
- Какие агенты существуют, на каких платформах.
- Какие области, инструменты и данные им разрешены.
- Каждое одобрение, детокенизация и значимое действие — с указанием одобрившего и времени.
Вопрос CEO: Если спросят, как агент принял конкретное решение, сможем ли мы восстановить цепочку событий?
Не забывайте о системной модели угроз: предположите, что угрозовый актер GTG-1002 уже внутри вашей компании. Для полной готовности смотрите шире — на продукт MITRE ATLAS, созданный именно потому, что противники атакуют системы, а не модели. Anthropic приводит кейс с государственным угрозовым актером GTG-1002, использующим агентный фреймворк.
Эти меры не делают агентов волшебно безопасными. Они возвращают ИИ, его доступ и действия в привычную рамку безопасности для мощных пользователей или систем.
Для советов директоров и CEO вопрос теперь не в "у нас хорошие барьеры для ИИ?", а в том: можем ли мы ответить на вопросы CEO выше с доказательствами, а не заверениями?