От интеллекта к полномочиям

Искусственный интеллект выходит за рамки ответов на вопросы и создания контента. Всё чаще системы ИИ способны интерпретировать инструкции, составлять планы, выбирать инструменты и выполнять задачи без постоянного руководства со стороны человека.

Это различие имеет значение.

Система ИИ, которая рекомендует действие, отличается от системы, которой разрешено его выполнить. Разница заключается не обязательно в интеллекте или сложности системы. Она — в полномочиях.

Автономные системы не ограничиваются передовыми большими языковыми моделями. К ним относятся специализированные системы машинного обучения, робототехника, автономные транспортные средства, программные агенты и сочетания технологий, которые самостоятельно принимают решения или выполняют действия в заданных условиях эксплуатации.

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

В работе Проблемы безопасности при проектировании автономных систем Мохаммад Хамад и Себастьян Штайнхорст рассматривают проблемы безопасности, связанные с автономным реагированием на инциденты, оценкой рисков, контролем доступа, достоверностью данных и взаимодействием автономных систем. Их исследование, в значительной части посвящённое киберфизическим системам, показывает, что обеспечение безопасности при самостоятельных действиях машин сопряжено с трудностями, выходящими за рамки современных агентов на основе больших языковых моделей.

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

Точно так же свидетельства того, что автономный ИИ может причинить вред, не доказывают, что механизмы управления обязательно отстают. Не следует также исходить из того, что автономные системы по своей природе трудно защитить.

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

Кибербезопасность даёт особенно полезную перспективу для рассмотрения этого вопроса, поскольку специалисты по безопасности десятилетиями подвергают сомнению предположения о доверии, разрешениях, доступе и поведении систем.

Игра в кошки-мышки на машинной скорости

Кибербезопасность давно описывают как игру в кошки-мышки.

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

Автономный ИИ не обязательно меняет фундаментальные правила этой игры. Он может изменить то, кто — или что — в неё играет, скорость действий и объём работы, которую можно выполнять без постоянного участия человека.

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

Именно этот потенциал двойного применения лежит в основе понимания последствий автономного ИИ для безопасности.

Проект Glasswing компании Anthropic служит примером применения ИИ для обнаружения уязвимостей. В исследовательском обновлении за май 2026 года Anthropic сообщила о значительных результатах в обнаружении уязвимостей, одновременно подчеркнув операционные трудности, связанные с их проверкой, раскрытием информации о них и выпуском исправлений.

Это различие имеет значение. Обнаружить уязвимость — не то же самое, что подтвердить возможность её эксплуатации, устранить её или доказать, что затронутая система защищена.

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

Результат для безопасности зависит от того, что происходит дальше.

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

Традиционное тестирование на проникновение не устаревает из-за того, что ИИ способен выполнять наступательные задачи. Его рамки необходимо расширить, включив в них системы, которые интерпретируют инструкции, вызывают инструменты, объединяют разрешения и преследуют цели в несколько этапов.

Цель остаётся прежней: обнаружить слабые места, оценить их значимость, устранить их и доказать, что меры защиты работают.

Архитектурные стыки: где встречаются границы безопасности

Один из менее очевидных рисков автономных систем возникает, когда взаимодействие компонентов, каждый из которых по отдельности действует с соответствующими полномочиями, приводит к непредвиденным последствиям.

Я называю такие точки взаимодействия архитектурными стыками.

Рассмотрим типичный пример. Организация ограничивает доступ к файлу с помощью разрешений NTFS. Отдельный облачный сервис для обмена файлами позволяет пользователю с соответствующими правами делиться этой информацией с внешними получателями.

Каждая система может действовать по собственным правилам. Однако их взаимодействие может привести к обмену информацией, который нарушает установленные организацией границы безопасности.

Это пример потенциально конфликтующих политик, а не утверждение о том, что какой-либо продукт для обмена файлами уязвим.

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

Сходные ситуации могут возникать в автономных системах ИИ, объединяющих модели, приложения, учетные записи, инструменты, репозитории и внешние сервисы.

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

Исследования дают практические основания изучать подобные взаимодействия.

В AgentDojo исследователи оценили атаки с внедрением инструкций против ИИ-агентов, использующих инструменты, на 97 реалистичных задачах и 629 проверочных сценариях безопасности. Результаты показали, что вредоносные инструкции, переданные через недоверенные выходные данные инструментов, могут нарушать некоторые свойства безопасности, хотя успешность атак и агентов была неодинаковой.

Исследование не устанавливает, как часто такие атаки успешны в производственных средах. Однако оно показывает, почему для понимания поведения системы, подключенной к инструментам, недостаточно оценивать только ответы модели.

Связанный с этим риск иногда называют «отмыванием разрешений»: действие выглядит законным, поскольку выполняется через авторизованный инструмент или посредника, хотя совокупное поведение нарушает установленные границы полномочий.

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

Необходимо также распределить ответственность между участниками архитектуры.

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

Автономность не снимает ответственности. Она лишь повышает важность понимания того, на ком именно эта ответственность лежит.

Строгая наступательная проверка: проверяем то, что, как нам кажется, мы знаем

Так мы подходим к концепции, которую я называю строгой наступательной проверкой.

Строгая наступательная проверка — это системный подход к тестированию в условиях противодействия, критическому анализу и проверке на основе фактических данных, призванный подвергать сомнению предположения о безопасности. Он оценивает поведение систем в реалистичных условиях, а не полагается исключительно на архитектурные проекты, задокументированные средства контроля или предполагаемую защиту.

В основе этого подхода лежат давно известные практики. Тестирование на проникновение, моделирование угроз, командные учения с имитацией атак и проверка безопасности уже много лет помогают ставить под сомнение предположения о надежности защиты.

Строгая наступательная проверка объединяет эти практики вокруг главного вопроса:

Какие доказательства подтверждают, что установленная граница безопасности действительно соблюдается?

В организации могут действовать политики, ограничивающие доступ к конфиденциальной информации; модель может быть настроена на отклонение запрещенных запросов, а агент — работать с ограниченными правами.

Это значимые меры защиты. Однако само их наличие еще не доказывает, что вся система в целом будет безопасно работать в условиях противодействия.

Модель может отклонить вредоносную инструкцию, но авторизованный инструмент все равно позволит выполнить непредусмотренное действие. Политика может казаться корректной, однако взаимодействие систем способно создать неожиданный способ ее обойти.

Иногда я называю это «иллюзией защитных барьеров»: наличием таких барьеров ошибочно считают доказательство того, что система не сможет пересечь границу, которую они должны были защищать.

Защитные барьеры полезны. Но их эффективность все равно необходимо подтверждать.

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

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

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

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

Строгий наступательный подход объединяет пять видов деятельности:

1. Сформулировать предположение: определить, какое свойство безопасности должна обеспечивать архитектура.
2. Проверить предположение на прочность: испытать реалистичные сценарии атак, манипулируемые входные данные и сочетания легитимных возможностей.
3. Собрать свидетельства: выяснить, что пыталась сделать система, что было выполнено и какие средства контроля сработали.
4. Устранить уязвимость: исправить модель, рабочий процесс, разрешения, архитектуру или операционный процесс, приведшие к сбою.
5. Проверить исправление: повторно испытать соответствующий сценарий атаки и подтвердить, что требуемое свойство безопасности обеспечивается.

В этом и состоит различие между проверкой реакции модели и проверкой безопасности системы в целом.

Кроме того, необходимо изучить, что происходит после первоначального проникновения. Злоумышленник может попытаться собрать учетные данные, повысить привилегии, закрепиться в системе или перемещаться по сети, используя уже доступные в среде возможности.

Легитимность инструмента не означает, что любое его использование также легитимно.

Цель строгого наступательного подхода — не исходить из того, что автономные системы небезопасны, а с помощью испытаний определить, где проходят и насколько надежны их границы безопасности.

Условная автономность: отделение интеллектуальных возможностей от полномочий

Один из архитектурных подходов — разграничить возможности ИИ-системы и действия, на которые она уполномочена.

Я называю этот подход условной автономностью.

Условная автономность предполагает, что подходящая степень самостоятельности зависит от задачи, условий работы, возможных последствий, неопределенности и имеющихся данных, подтверждающих обоснованность действия.

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

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

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

Агент может пересмотреть способ выполнения разрешенной задачи, не получая дополнительных полномочий.

В десятке главных рисков OWASP для приложений на основе больших языковых моделей эта проблема рассматривается в категории LLM06:2025 — чрезмерная агентность. OWASP относит к источникам риска избыточную функциональность, чрезмерные разрешения и автономность и рекомендует ограничивать возможности и независимо обеспечивать соблюдение правил авторизации.

Принципы условной автономности применяются с учетом операционного риска.

Доступ к информации следует ограничивать тем, что необходимо для выполнения задачи. Разрешения на использование инструментов должны распространяться только на одобренные операции. Ограничить выполнение можно с помощью лимитов на действия, ограничений частоты запросов, требований к одобрению и условий остановки.

Эти меры защиты особенно важны при автономном тестировании на проникновение.

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

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

Это соответствует устоявшимся принципам минимальных привилегий и разделения обязанностей.

Это также поднимает интересный вопрос об архитектуре Bring Your Own Model (BYOM) или Bring Your Own LLM (BYO-LLM).

Если завтра базовую модель заменят, какие гарантии безопасности сохранятся?

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

Это не означает, что защитный контур автоматически безопасен или что модели взаимозаменяемы. Разные модели могут по-разному интерпретировать инструкции, использовать инструменты и создавать различные сценарии отказа.

Полноценная оценка должна проверять как средства контроля, которые должны оставаться неизменными, так и особенности поведения, меняющиеся при замене модели.

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

Когда ИИ воздействует на ИИ: проблема проверки

Рассмотрим гипотетический рабочий процесс центра управления безопасностью:

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

Один агент-аналитик изучает телеметрию. Другой рекомендует меры по локализации инцидента. Уполномоченный агент выполняет изменения. Агент проверки оценивает результат.

Это пример автономного реагирования на инцидент с замкнутым циклом, а не задокументированный сбой, характерный для всей отрасли.

Предположим, первый агент ошибочно определяет, что учетная запись скомпрометирована. Второй агент принимает этот вывод и отключает учетную запись. Третий подтверждает, что учетная запись отключена, и сообщает об успешном выполнении.

Выбранное действие было выполнено.

Но верно ли было первоначальное заключение? Было ли действие санкционировано? Устранило ли оно реальную угрозу? Не вызвало ли оно ненужных сбоев?

Проверка не может сводиться лишь к подтверждению того, что агент выполнил выбранное им действие.

И поручение проверки другому ИИ-агенту само по себе не делает ее результат независимым.

Разные агенты могут опираться на одни и те же неточные данные телеметрии, скомпрометированную информацию или ошибочные предположения. Их согласие не является независимым подтверждением лежащих в основе фактов.

Чем серьезнее последствия автономного действия, тем важнее проверка, независимая от системы, принимающей решение.

Независимость может обеспечиваться отдельно полученными данными, детерминированными проверками политик, изолированной средой выполнения, проверкой человеком или сочетанием этих мер защиты.

Меры контроля должны быть соразмерны последствиям ошибки.

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

Четыре вопроса помогают разграничить соответствующие свойства безопасности:

• Правильно ли система поняла поставленную задачу?
• Входило ли действие в пределы предоставленных ей полномочий?
• Оставалось ли выполнение в рамках разрешенных границ?
• Соответствовал ли полученный результат поставленной цели безопасности?

Эти вопросы связаны между собой, но не взаимозаменяемы.

Агент может выполнить санкционированное действие, которое приведет к непредусмотренному результату. Он также может добиться, на первый взгляд, полезного результата с помощью несанкционированного действия.

Ни то ни другое не следует автоматически считать успешным обеспечением безопасности.

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

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

Доверие должно опираться на доказательства

Последствия применения автономного ИИ для безопасности не сводятся исключительно к негативным.

Автономные системы могут помогать специалистам по защите находить уязвимости, расследовать угрозы и выполнять проверочные работы, которые в противном случае потребовали бы значительных усилий от людей.

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

Поэтому было бы преждевременно заключать, что автономный ИИ по своей природе небезопасен или что системы управления не могут поспевать за его развитием.

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

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

Уже существующие меры контроля могут обеспечить практичные решения, если их правильно внедрять и проверять.

Автономность может изменить скорость, масштаб и сложность применения этих мер. Но сама по себе она не делает их недействительными.

Данные позволяют поставить более полезный вопрос: при каких условиях автономным системам можно доверить осуществление делегированных полномочий и как доказать, что эти условия соблюдены?

Ответ не может определяться одними лишь возможностями модели.

Для этого необходимы архитектурные границы, четко распределенная ответственность, авторизация с независимым обеспечением ее соблюдения, надлежащий надзор и доказательства того, что меры защиты работают в реалистичных условиях.

Для этого также необходимо последовательное, но развивающееся представление о безопасности и рисках.

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

В этом и состоит цель строгого подхода к наступательной безопасности.

Не для того, чтобы доказать, что системы ИИ дадут сбой, а для того, чтобы выяснить, где это может произойти, определить последствия и проверить средства контроля, призванные предотвращать такие сбои или сдерживать их последствия.

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

Игра в кошки-мышки продолжается. Всё чаще в ней могут участвовать автономные игроки с обеих сторон.

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

Доверие должно основываться на доказательствах.

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