Спросите исследователя безопасности, что делает ИИ-агента опасным, и инстинктивная реакция — говорить о модели: что она откажется делать, как легко её взломать, можно ли доверять её весам.
Этот инстинкт всё больше устаревает. Растущий объём исследований в области безопасности — демонстрации эксплойтов, независимый red-teaming и оценки экспертов — указывает вместо этого на код, который находится между моделью и внешним миром.
Этот код, всё чаще называемый harness, оборачивает модель, даёт ей инструменты и превращает её вывод токен за токеном в команду оболочки, запись в файл или вызов API. При этом он плохо инвентаризирован, недостаточно протестирован и зачастую никому не принадлежит внутри организаций.
Элад Мегед, ведущий инженер и исследователь безопасности в Novee Security, взломал официальные репозитории автоматизации Anthropic, Google и OpenAI, используя лишь issue на GitHub.
Исследователи из Lasso Security обнаружили, что замена одного элемента якобы нейтральной обвязки агента на другой увеличила показатель успешности атак модели с 1% до 24% — при идентичных модели, промпте и инструментах.
А Майкл Баргури, сооснователь и технический директор компании по ИИ-безопасности Zenity, обнаружил, что злоумышленники прячут вредоносное ПО для кражи учётных данных внутри ИИ-«скиллов», которые уже прошли все имеющиеся на рынке сканеры, включая официальные от Anthropic и Cisco.
Сбои разные, но их объединяет важная характеристика: ни один из них не требует, чтобы модель стала вредоносной или хотя бы повела себя неожиданно. Они эксплуатируют программное обеспечение вокруг неё — слой, который определяет, что модель может видеть, к чему прикасаться и что происходит, когда она действует.
Вот почему растущее число исследователей ИИ-безопасности утверждают, что harness нужно рассматривать как самостоятельную поверхность атаки, а не как невидимые строительные леса, поставляемые вместе с моделью.
Что такое «harness» на самом деле
Спросите практиков, что такое harness, и метафоры сойдутся с разных сторон.
Баргури говорит CSO, что называет его «руками и ногами и глазами» модели. Сама модель производит токены на входе и выходе; harness превращает эти токены в команду оболочки, запись в файл или вызов API.
Роб Т. Ли, главный директор по ИИ и руководитель исследований в SANS Institute, описывает модель как двигатель, а harness — как шасси. Майкл Сромин, старший инженер ML в Lasso Security, сравнивает его с операционной системой агента, которая запускает цикл агента и соединяет модель, инструменты и пользователя. «Я вижу это как… операционную систему, которая управляет этим… бесконечным циклом агентского приложения», — говорит он CSO.
Омар Сантос, выдающийся инженер Cisco, предлагает более формальное определение.
«ИИ-обвязка (harness) — это слой, который окружает модель и делает её полезной», — говорит Сантос CSO. «Сюда входят оркестрация, использование инструментов, промпты, контекст, роли, оценки, guardrails и операционный рабочий процесс, превращающий сырой вывод модели в ограниченные, повторяемые действия».
Все описания указывают на одну и ту же проблему безопасности, а именно: harness — это место, где реализуются полномочия агента. Он находится между рассуждениями модели и реальной файловой системой, ключом API или производственной базой данных.
«Команды безопасности должны рассматривать harness как поверхность атаки, потому что именно там агент получает свои полномочия, контекст и пути к действию», — говорит Сантос.
И код harness содержит уязвимости, как и любое другое программное обеспечение.
Идеально выровненная модель может находиться внутри harness, который доверяет шаблону wildcard в оболочке или повторно использует рабочую область в двух проходах недоверенного контента. В этом случае выравнивание модели по большей части не имеет значения. Уязвимость не в модели.
Три режима отказа, одна поверхность атаки
Некоторые из наиболее детальных исследований в этом году выявили три различных способа, которыми выходят из строя harness: архитектурные границы доверия, особенности реализации и компрометация цепочки поставок.
Мегед продемонстрировал первый (архитектурные границы доверия) на Black Hat после взлома официальных средств автоматизации Anthropic, Google и OpenAI, используя лишь issue на GitHub.
Повторяющийся паттерн, по его словам, был таким: «Решение принимается в одном месте, а потребляется в другом, с большими полномочиями».
Уязвимость каждого вендора была разной. Одна дала ему выполнение кода. Другая раскрыла учётные данные, которые, как считалось, harness удалил. Третья позволила ему внедрить инструкции, которым более привилегированный этап доверял без повторной проверки.
Но основная архитектурная ошибка была поразительно последовательной. Один компонент принимал решение о безопасности, а более мощный нижестоящий компонент доверял этому решению, не проверяя его повторно.
Это не сбой модели. Это сбой границы доверия.
Исследование Lasso выявляет вторую проблему. Даже без эксплуатабельной ошибки в коде сама конструкция harness может радикально изменить безопасность агента.
«Когда вы выбираете вашу LLM, инструменты и всё остальное, и выбираете harness, вы получаете одного агента», — говорит Сромин. «А когда вы выбираете другой harness, вы получаете совершенно другого агента».
Это более серьёзное различие, чем многие организации могут осознавать. Некоторые специалисты по безопасности всё ещё рассматривают harness как не более чем сквозной цикл — взаимозаменяемую обвязку между моделью и её инструментами.
Цифры Lasso говорят об обратном. Замена harness под идентичной моделью с открытыми весами переместила показатель успешности атак с 1% до 24% и полностью изменила результат в 43 из 100 пар «модель-задача».
«Это не просто произвольный выбор», — говорит Сромин. «Это тщательный выбор. Он может действительно повлиять и сдвинуть иглу в том, что вы делаете».
Его рекомендация — тестировать harness вместе с моделью. Выбор готового решения без тестирования означает принятие важного решения по безопасности, не зная, что вы его приняли.
Цепочка поставок harness быстро расширяется, показывают исследования Баргури в Zenity, и её уже эксплуатируют.
Его команда исследовала «скиллы» — файлы, которые обучают агента выполнять новые задачи, — и обнаружила старую проблему безопасности в новой форме.
«Это просто проблема цепочки поставок, снова всплывающая со скиллами», — сказал Баргури на Black Hat.
Но скиллы агентов создают необычные вариации этой проблемы, поскольку они могут изменить среду, которой агент постоянно доверяет.
Например, каждый раз, когда агент запускается, он может перезагружать файл памяти, содержащий инструкции о том, что он должен делать. Zenity обнаружила, что вредоносный скилл может записать себя в эту память. Удалите скилл — и инструкция по его переустановке останется, позволяя вредоносному ПО вернуться при следующем запуске агента.
Другой вредоносный скилл, изученный Zenity, маскировался под легитимный инструмент Anthropic. После выполнения он удалял настоящий инструмент и заменял его версией злоумышленника, оставляя агента выполняющим вредоносный код без очевидных изменений для пользователя.
Наиболее ярким примером стала кампания клонированных версий популярных инструментов с открытым исходным кодом, тайно модифицированных для кражи учётных данных. Вредоносные скиллы превзошли легитимные инструменты, которые они копировали, на skills.sh и набрали примерно 1,7 миллиона загрузок до того, как кампания была пресечена.
Урок всех трёх направлений исследований один и тот же: обеспечение безопасности модели — это не то же самое, что обеспечение безопасности агента.
Что должны знать CISО
Для CISО исследования указывают на три непосредственные проблемы: найти harness, уже работающие внутри организации, контролировать, к чему им разрешено прикасаться, и независимо тестировать, работают ли их меры безопасности на самом деле.
Первая может оказаться сложнее, чем кажется, потому что большинство организаций не ведут категорию «ИИ-обвязка».
«Команды думают в терминах приложений, сервисов, пайплайнов или ботов», — говорит Сантос. Harness исчезают в репозиториях кода, SaaS-продуктах и экранах конфигурации вендоров, вместо того чтобы появляться как отдельные активы в инвентаризациях безопасности.
Даже терминология непоследовательна.
«Одна команда может называть что-то агентом, другая — копилотом, третья — ассистентом рабочего процесса, четвёртая — автоматизацией на основе плагинов», — говорит Сантос, «хотя все они по сути являются обвязками (harness)».
Его рекомендация — создать живую инвентаризацию каждого производственного агента, идентифицировать его harness и сопоставить каждый инструмент и ресурс, к которым он имеет доступ. Затем сократить эти разрешения до минимально необходимых.
Организациям не стоит ждать идеальной видимости. Сантос оценивает, что 60–70% видимости можно достичь относительно быстро, начав с производственных систем и оставив прототипы и теневой ИИ для второго этапа.
Вторая проблема — контроль над всем, чему доверяет harness.
Агенты не действуют в изоляции. Они получают инструкции и контент из инструментов, плагинов, скиллов, MCP-серверов, веб-сайтов и других систем, часто имея при себе учётные данные и разрешения, позволяющие им действовать от имени пользователей.
Поэтому злоумышленникам не нужно компрометировать модель. Им нужно скомпрометировать то, чему harness готов доверять.
«Вы делитесь своим ноутбуком со своими агентами, а в вашем ноутбуке есть всё — ваша личность, ваши файлы, ваши секреты», — говорит Баргури.
Для организаций без выделенного бюджета на ИИ-безопасность он рекомендует как минимум запускать агентов внутри инструментов изоляции с открытым исходным кодом. «Это не исправление», — предупреждает он, — «но это полезно».
Размер потенциальной цепочки поставок делает проблему качественно отличной от обычного управления зависимостями в программном обеспечении.
«Цепочка поставок для ПО — это, ну, 10 или 15 реестров пакетов? — говорит Баргури. — Цепочка поставок для агентов — это любой контент, любое изображение, любой текст, любой веб-сайт, любой объект CRM, любой скилл, любой MCP-сервер, любой контент в интернете».
Третья проблема — это предположение, что заявления вендора о безопасности переносятся в среду, где агент будет работать на самом деле.
Вендор, утверждающий, что блокирует 99% prompt-инъекций, по словам Баргури, может ссылаться на «бенчмарк, не привязанный к реальности на местах».
Результаты Lasso демонстрируют, почему это важно. Зафиксируйте модель, промпт и инструменты, измените только harness — и результат безопасности может кардинально измениться.
Это означает, что организации, оценивающие агентов, могут задавать неправильный вопрос. Дело не просто в том, какая модель безопаснее. Дело в том, какая комбинация модели, harness, инструментов, разрешений и внешних входных данных остаётся безопасной в условиях, в которых организация будет её развёртывать.
Мегед сформулировал урок, полученный при взломе официальных средств автоматизации трёх вендоров: «Читайте настройки по умолчанию, а не документацию».
«Продукт утверждал, что он безопасен, — сказал он, — и именно с этого мы начали».
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Cynthia Brumfield
