Безопасность AI-систем в эпоху агентов: что меняется в threat model

Пока LLM только отвечала текстом в чате, риски были ограничены: неверный ответ, утечка через prompt, генерация небезопасного совета. Агентная архитектура меняет модель угроз. Теперь AI получает инструменты: читает файлы, вызывает API, открывает браузер, пишет код, отправляет письма, работает с репозиториями и иногда может менять production-системы.

Это уже не просто chatbot security. Это безопасность автоматизированного исполнителя, который может ошибиться, поверить недоверенному контенту или выполнить вредную инструкцию.

Prompt injection становится практической угрозой

Prompt injection — это не только забавные фразы «ignore previous instructions». В агентной системе недоверенный текст может стать инструкцией к действию. Например, агент читает страницу, issue, email или документ, где злоумышленник встроил команду: скачать файл, отправить секрет, удалить данные, изменить код.

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

Tool permissions

Главное правило: модель не должна иметь больше прав, чем нужно для задачи. Если агент анализирует документацию, ему не нужен доступ к production secrets. Если он пишет тесты, ему не нужен deploy-token.

Нужны уровни прав:

• read-only режим;
• sandbox для выполнения кода;
• отдельные service accounts;
• временные credentials;
• allowlist tools;
• approval для опасных действий;
• audit log всех вызовов.

Tool calling без permission model — это открытая дверь.

Data exfiltration

AI-агент может утянуть данные не потому, что «захотел», а потому что получил вредную инструкцию или неправильно интерпретировал задачу. Риски:

• отправка секретов во внешний API;
• публикация приватного кода;
• вставка токенов в issue или log;
• передача PII в модель;
• утечка через generated report.

Поэтому нужен контроль outbound-трафика, redaction секретов и запрет на передачу чувствительных данных без явного разрешения.

Агент как supply chain риск

Если агент пишет код и зависимости, он становится частью supply chain. Он может добавить пакет с плохой репутацией, вставить небезопасный snippet или заменить проверенный компонент на случайный.

Защита:

• dependency allowlist;
• SCA scanning;
• secret scanning;
• review lockfile;
• запрет новых пакетов без approval;
• проверка лицензий;
• policy-as-code.

Sandbox обязателен

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

Sandbox должен ограничивать:

• filesystem;
• network;
• CPU/RAM;
• время выполнения;
• доступ к secrets;
• системные вызовы, если возможно.

Даже если агент «доверенный», его входные данные могут быть недоверенными.

Human-in-the-loop

Полная автономность допустима только для низкорисковых операций. Всё, что касается удаления данных, финансов, прав доступа, production deploy и security-настроек, должно требовать подтверждения человеком.

Важно, чтобы approval был содержательным: человек должен видеть diff, список tool calls, новые зависимости, затронутые секреты и последствия.

Итог

AI-агенты расширяют поверхность атаки, потому что получают права действовать. Безопасность должна строиться вокруг прав, sandbox, audit, approval и разделения данных от инструкций.

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