Когда я только начинал работать над инициативами по безопасности корпоративного ИИ, я ожидал, что самые большие проблемы будут техническими. Я предполагал, что мы будем проводить большую часть времени, обсуждая prompt injection, безопасность моделей, векторные базы данных или новейшие уязвимости LLM.
Я ошибался — или, по крайней мере, видел лишь часть картины.
Технологии, безусловно, важны, но после работы с несколькими корпоративными ИИ-инициативами я понял, что самые трудные проблемы безопасности редко исходят от самой модели. Они возникают, когда ИИ становится частью реальных бизнес-процессов.
ИИ-ассистент не просто отвечает на вопросы. В рамках одного рабочего процесса он может получить запись о клиенте из Salesforce, открыть тикет в ServiceNow и отправить обновление через Microsoft 365, прежде чем кто-то дочитает сводку. Всё чаще он принимает решения раньше, чем человек вообще успевает это заметить, и такой сдвиг меняет модель угроз. Традиционная безопасность приложений предполагает, что программное обеспечение выполняет детерминированный код. ИИ-системы — нет. Они рассуждают, адаптируются и генерируют результаты, которые не всегда можно предсказать заранее. Это значит, что многие средства контроля, на которые мы полагались годами, остаются необходимыми, но их уже недостаточно.
Ниже — то, к чему я постоянно возвращаюсь на архитектурных ревью: не уязвимости моделей, которые попадают в заголовки, а более тихие сбои, проявляющиеся, когда агент уже запущен.
Идентичность — это только отправная точка
Одной из первых неожиданностей стало то, как быстро организации сосредотачиваются на аутентификации, упуская из виду поведение в рантайме. Большинство корпоративных ИИ-проектов начинаются с вопросов вроде «Может ли ИИ получить доступ к SharePoint?», «Может ли он подключиться к ServiceNow?», «Может ли он подключиться к GitLab?» или «Может ли он читать инструменты Microsoft 365, такие как Outlook, Word и т. д.?» Это важные вопросы, но ещё важнее другой: что ИИ должен иметь право делать после предоставления конкретного типа доступа — например, доступа только на чтение?
Идентичность отвечает на вопрос, кто такой агент. Авторизация — к чему он может получить доступ. Но ни одна из них не отвечает на вопрос, должно ли ИИ выполнять конкретное действие; в приведённом случае речь идёт только о доступе на чтение.
На вопрос о возможностях и на вопрос о защитных механизмах слишком часто отвечают разные команды в разные сроки. Проверки безопасности, сосредоточенные только на том, к чему ИИ может получить доступ, как правило, упускают более показательный вопрос: что ему разрешено делать после получения этого доступа. Я начал рассматривать эти два вопроса как единую задачу проектирования, потому что любой разрыв между ними рано или поздно оборачивается инцидентом.
Помню архитектурное ревью, где это проявилось наглядно. Сотрудник попросил внутреннего ассистента — созданного на базе Microsoft 365 и SharePoint — составить сводку нескольких отчётов об инцидентах, и в ходе своих рассуждений ассистент обнаружил привилегированную административную документацию на связанном сайте и решил, что эти детали тоже могут быть полезны. Технически ничего не отказало. Учётные данные были действительными. Права доступа — корректными. И всё же результат противоречил бизнес-намерениям. Этот момент изменил ход разговора для всех присутствующих. Мы поняли, что наша модель угроз была построена для посторонних, пытающихся проникнуть внутрь, а не для авторизованных систем, действующих с излишней услужливостью. Чтобы закрыть этот разрыв, нужно было проектировать средства контроля, оценивающие поведение в контексте, а не только учётные данные на входе. Именно поэтому я теперь считаю runtime-управление одной из определяющих задач безопасности корпоративного ИИ.
Такие организации, как OWASP GenAI Security Project и NIST AI Risk Management Framework, подчёркивают, что риски ИИ выходят далеко за рамки аутентификации и авторизации и включают мониторинг, управление и непрерывный надзор на всём протяжении выполнения. Материал CSOonline об агентной идентичности утверждает то же самое: существующие средства контроля не были спроектированы для ИИ-агентов, и статических учётных данных и постоянных привилегий больше недостаточно, когда организациям приходится быстро выдавать, ограничивать и отзывать разрешения у автономных агентов — иногда несколько раз в рамках одного рабочего процесса.
Крупнейшие сбои редко выглядят как кибератаки
Большинство специалистов по безопасности, естественно, ищут вредоносную активность: prompt injection, отравление данных, кражу учётных данных, манипуляцию моделью. Эти атаки, безусловно, важны. Однако чаще мне приходилось видеть сбои, вызванные легитимным поведением ИИ. ИИ-ассистент для финансов, HR, клиентской работы или управления рисками извлекает больше документов, чем нужно, пытаясь дать «лучший» ответ. Автономный рабочий процесс выполняет пять одобренных действий вместо одного. ИИ-агент продолжает выполнение после того, как исходное намерение пользователя уже удовлетворено. Ни одно из этих явлений не похоже на традиционные атаки, однако они могут приводить к нарушениям комплаенса, проблемам с приватностью или операционным сбоям.
Одна мысленная модель неизменно помогает руководителям понять, почему это так опасно. Я прошу их перестать думать об ИИ как о программном обеспечении и вместо этого представить, что они нанимают тысячи новых цифровых сотрудников, то есть ИИ-агентов. Каждый сотрудник получает обучение, ограниченный доступ, мониторинг, аудит и надзор. ИИ-агенты заслуживают того же.
Один из проектов, над которым я работал, включал несколько специализированных ИИ-агентов, совместно выполнявших одну бизнес-задачу. Один запрашивал историю тикетов в ServiceNow, другой анализировал документы в SharePoint, третий составлял рекомендации, а четвёртый записывал обновления обратно в Jira. По отдельности у каждого агента были относительно ограниченные права — например, только чтение и/или запись. Вместе они образовывали мощный автономный рабочий процесс. Этот опыт подтвердил важный урок: безопасность больше не может сосредотачиваться только на отдельных ИИ-компонентах. Она должна охватывать всю цепочку автономного принятия решений. Платформа MITRE ATLAS — отличный способ продумать техники атак на ИИ, но не менее важно понимать, как обычное автономное поведение может непреднамеренно создавать бизнес-риски.
Самые поучительные случаи, которые я видел, касаются агентов, делегирующих задачи другим агентам. На одном ревью агент первой линии поддержки имел строго доступ только на чтение к Salesforce, но мог передавать задачи второму агенту, у которого были права записи в ServiceNow и биллинговую платформу. Когда первый агент не мог решить проблему клиента в рамках своих полномочий, он незаметно направлял запрос через второго агента, и тот обновлял обращение и оформлял кредит. Ничего не взламывали. Учётные данные были действительными, делегирование технически разрешённым, и всё же агент с доступом только на чтение фактически выполнял операции записи, которые ему никогда не полагалось выполнять. Это и есть определяющее различие между ассистентом и агентом. Ассистент отвечает; агент привлекает других агентов, и сам путь эскалации оказывается уязвимостью.
Именно поэтому во время архитектурных ревью мы начали задавать другой вопрос. Вместо «Может ли ИИ это сделать?» мы спрашивали: «Должен ли ИИ вообще это делать?» Этот едва заметный сдвиг изменил многие проектные решения. Он заставил команды закладывать условия остановки, проверки границ и запросы подтверждения вместо того, чтобы полагаться на то, что агент сам знает, когда пора остановиться. На одном ревью достаточно было потребовать от человека подтверждения перед тем, как агент переходит от шага «только чтение» к операции записи, — и большинство рискованных сценариев, которые мы обсуждали, просто исчезли.
Начните с управления до автономии
Я постоянно наблюдаю одну закономерность: организации приходят в восторг от автономии задолго до того, как готовы ею управлять. Все хотят ИИ-агентов, но лишь немногие изначально вкладываются в принудительное применение политик в рантайме. Такой порядок стоит развернуть. На мой взгляд, успешные корпоративные ИИ-программы ещё до расширения автоматизации закладывают несколько основ: чёткие бизнес-границы, которые агент не имеет права пересекать; доступ с минимальными привилегиями для каждого агента; и одобрение человеком любого шага, затрагивающего чувствительные/ограниченные данные и системы, включая производственные данные и системы. Только после этого имеет смысл расширять автономное принятие решений. Я видел, как команды пытались обойти этот порядок, и результат почти всегда один и тот же: многообещающий пилот сворачивают, потому что никто не может уверенно объяснить, что делал ИИ и почему.
Бо́льшая часть этой основы — наблюдаемость. Традиционные журналы аудита фиксируют действия, но ИИ-системам нужно также фиксировать ход рассуждений. Когда ИИ-агент создаёт тикет, обновляет конфигурацию или отправляет письмо, должно быть понятно, почему было принято такое решение. Это не означает записи каждого токена, сгенерированного большой языковой моделью. Я нахожу более полезным фиксировать три вещи: исходный бизнес-запрос, системы, которых касался агент, и решения, которые он принимал по пути. Эти записи становятся бесценными при расследованиях, комплаенс-проверках и устранении неполадок, а ещё помогают организациям укреплять доверие. Руководителям гораздо спокойнее внедрять ИИ, когда они могут объяснить, как было принято важное решение. Подходы вроде Google Secure AI Framework подкрепляют ту же идею: безопасность ИИ должна быть измеримой, наблюдаемой и подотчётной по всей цепочке.
Я до сих пор сталкиваюсь с заблуждением, будто безопасность ИИ существует для того, чтобы ограничивать инновации. На практике организации, быстрее всех продвигающиеся в корпоративном ИИ, часто вкладывают больше всего средств в управление, потому что так руководители обретают уверенность, разработчики ускоряются, а бизнес-подразделения шире внедряют ИИ. При правильном подходе именно безопасность делает такую скорость возможной.
Оглядываясь назад, самый ценный урок был не про инженерию промптов, выбор модели или агентные фреймворки. Он в том, что безопасный ИИ достигается не одним идеальным средством контроля, а сотнями небольших инженерных решений, которые удерживают автономные системы в русле бизнес-намерений. По мере перехода от ассистентов к полностью автономным агентам это различие становится только важнее. Команды, которым я доверяю масштабирование ИИ, — это не те, у кого самые умные модели, а те, кто может объяснить, почему агент совершил то или иное действие — и где бы он остановился.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Ravindra Annam
