Безопасность без тормозов: почему ИИ-агенты застревают между пилотом и продом
Автор Светлана Маркова, архитектор направления ИИ-трансформации Neoflex
Пилот ИИ-агента сегодня собирают за несколько недель, а до промышленной эксплуатации доходят единицы. Проект обычно встаёт на согласовании с безопасностью, а если её требования выполнить буквально, агент теряет большую часть пользы. Светлана Маркова, архитектор направления ИИ-трансформации Neoflex, десять лет оценивала риски в банке и теперь проектирует ИИ-решения. Она рассказывает, как защищать агентов и при этом сохранить их экономику.
Агентов уже наняли, причём без собеседования
Исследователи METR в работе «Measuring AI Ability to Complete Long Tasks» (март 2025 года) показали, что длина задачи, которую агент доводит до конца без человека, удваивается примерно раз в семь месяцев. Gartner в июне 2025 года предсказал, что к 2028 году агенты будут сами принимать не меньше 15% повседневных рабочих решений. В том же прогнозе больше 40% агентных проектов закроют к концу 2027 года, и среди причин назван слабый контроль рисков.
Учесть всех агентов компании обычно не успевают. Бухгалтер пишет с помощью модели скрипт для сверки счетов, и в компании появляется ещё один агент, о котором никто не знает.
Так случилось в крупном промышленном холдинге, где мы участвовали в проработке требований и архитектуры защиты. Внутри контура там работает собственный сервис моделей с OpenAI-совместимым API, а пользоваться им в течение года будут десятки тысяч сотрудников. Защитный шлюз к сервису собрали как прототип за две недели, и прототип, как водится, сразу ушёл в прод. Журналирование отложили, чтобы не застрять в согласованиях. Доступ получили люди, информационные системы и агенты на рабочих станциях, а сотрудники начали автоматизировать работу скриптами. Служба безопасности по-прежнему видит обращения к модели, но почти не видит, что агенты делают дальше.
Почему агент перестаёт приносить деньги
Шлюз проверял запросы цепочкой фильтров на регулярных выражениях и умел отвечать только «да» или «нет». Под нагрузкой цепочка перестала справляться, а каждая попытка проверять глубже прибавляла задержку. Новую архитектуру заказчик строит с нуля, сохранив внешний API, чтобы клиентам сервиса ничего не пришлось переделывать.
Цена отказа растёт вместе с автономией. На отказ чат-бота человек ответит повторным вопросом. Автономный агент делает на одну задачу тысячи обращений, промежуточные результаты часто никто не смотрит, и одного заблокированного запроса хватает, чтобы весь запуск пропал.
Заказчик сформулировал это жёстко: внутри периметра ложное срабатывание ломает рабочий процесс и обходится дороже пропуска. Поэтому он сознательно выбрал минимальную задержку и согласился на часть пропусков.
Под этот компромисс устроены и проверки в новом шлюзе: несколько движков проверяют запрос одновременно, поэтому ждать приходится только самый медленный. Перед проверкой текст раскодируется из base64 и очищается от подмены символов, а номер карты подтверждается алгоритмом Луна, чтобы случайное совпадение с маской не поднимало тревогу.
Я считаю выбор заказчика правильным и предлагаю делать его явным, то есть считать защиту в бизнес-кейсе наравне с эффектом: сколько рабочих запросов отсекают ложные срабатывания и сколько времени добавляют проверки. Об этих цифрах финансовому директору и безопасности проще договориться ещё до пилота.
Риск переехал из ответа в действие
Красть из такого сервиса почти нечего: модели свои, данные внутри контура. Prompt injection перестал быть главной угрозой, хотя из объёма работ его в итоге не убрали. Опаснее момент, когда ответ модели превращается в действие и агент запускает сгенерированный код на рабочей станции. Шлюз видит имя вызываемой функции и аргументы. Если модель подберёт аргументы, при которых функция поведёт себя иначе, защитнику, по словам заказчика, пока нечего противопоставить.
Сложнее всего с агентами, которые переписывают собственные скрипты прямо в работе: подпись кода и проверка при запуске здесь не помогают. Заказчик предложил пускать такого агента к модели в обмен на журнал его действий. Мы обратили внимание на подвох: журнал пишет сам агент, и безопасность в итоге проверяет его рассказ о себе. Примерно так новый сотрудник мог бы сам составить себе характеристику для службы безопасности.
Похожая история с внешними сервисами, которые агенты подключают через MCP. Свой MCP-шлюз в закрытом контуре поставить можно, но что происходит за ним, не видно. Холдинг решил следить, как меняется схема MCP-сервера, и разрывать соединение, если она сменилась без согласования или в ответе появилась инъекция.
Решения, которые не может принять ИТ
Технические настройки защиты упираются в вопросы, ответить на которые может только бизнес.
Первый касается того, что агенту можно делать самому. Каждое действие удобно оценивать по двум признакам: насколько велик риск и можно ли его отменить. Например, сортировку заявок агент делает сам, заказ расходников тоже, пока укладывается в лимит, а платёж или удаление данных подтверждает человек. Где проходит граница, решает владелец процесса, ведь цену ошибки знает только он.
Второй вопрос: что делать с небезопасным ответом. Отказ на найденные в запросе персональные данные остановит автономного агента, поэтому устранимое дешевле исправить: замаскировать данные или попросить модель переписать ответ по требованиям безопасности. Решения о блокировке самого агента в холдинге тоже вероятностные: его останавливают, когда уверенность в опасной активности переходит порог. Где ставить этот порог и что делать, если проверка не успела ответить, технология не решит. В банках это называют аппетитом к риску, и утверждают его бизнес вместе с риск-менеджментом.
Третий вопрос о том, кто наблюдает за агентом. Журнал должен вести шлюз, через который идут запросы. В новой архитектуре холдинга аудит заложен с самого начала: пишется почти всё, а для чувствительных сценариев запись можно отключить на уровне отдельного токена.
Что говорят ИТ-директора
Этой осенью мы обсуждали агентов с ИТ- и ИБ-руководителями нескольких десятков компаний. Чаще всего звучит «мы строим платформу сами», и для зрелой компании это разумный выбор. Холдинг из нашего примера идёт тем же путём, и его опыт показывает, где собственная разработка буксует: аудит, контроль действий агентов и подключения внешних сервисов через MCP.
Безопасники часто добавляют, что прокси с гардрейлами собирается на open source за неделю. Это правда, только первый шлюз холдинга тоже собрали быстро, а под нагрузкой его пришлось переписывать.
С чего начать масштабирование
Прежде чем тиражировать агентов, я бы спросила у ИТ и безопасности: сможем ли мы узнать, что агент сделал вчера, не спрашивая самого агента? На этом вопросе обычно возникает самая долгая пауза.
Если уверенного ответа нет, начинать лучше с одного процесса: найти агентов, вместе с владельцем процесса определить границы автономии и подключить контроль. Для этого мы сделали модули Guard и Lens, которые входят в состав Neoflex Neon – корпоративной платформы для внедрения и промышленной эксплуатации ИИ-агентов и GenAI-сценариев с полным контролем над безопасностью. Они ставятся отдельно от платформы, рядом с уже работающими агентами. Guard проверяет запросы и ответы параллельно и исправляет устранимые нарушения, а Lens записывает каждый шаг агента в журнал, недоступный самому агенту.
Готовой коробки на все случаи пока нет ни у кого. Контроль вызова функций и сервисов за MCP-шлюзом холдинг вынес в отдельный исследовательский трек, а передавать инструменту права конкретного пользователя, по нашей оценке, пока корректно не умеет ни одна платформа на рынке. Но границы автономии, журнал вне агента и параллельные проверки можно внедрять уже сейчас, не дожидаясь, пока рынок закроет эти пробелы.
