Аудит безопасности и готовности ИИ-агентов

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

Кому подходит этот аудит

Он полезен в трёх ситуациях. Первая: пилот агента завершён, проект ждёт вывода в продакшен, но согласование со службой безопасности или юристами ещё не получено. Вторая: в компании разные команды сами подключили агентов, автоматизации и MCP-соединения, и уже никто не видит из одной точки, кто и что подключил. Третья: клиент, аудитор или инвестор попросил письменно описать, как компания использует ИИ. Объём аудита одинаков независимо от того, кто построил агента: ваша команда, подрядчик или готовая платформа. Если агента ещё нет и речь идёт только об идее, этот аудит преждевременен; разумнее начать с обсуждения задачи в рамках ИИ-решений.

Что входит в аудит

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

Реестр агентов

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

Карта прав и границ данных

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

Оценка рисков персональных данных

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

Журнал действий и подтверждение человеком

После инцидента первым всегда звучит вопрос: что сделал агент, почему и кто это одобрил. Мы проверяем, записывает ли система, какой инструмент агент вызвал и с какими параметрами, от чьего имени действовал и каким был результат. Затем выделяем необратимые действия: платежи, удаление, письма за пределы компании, изменение клиентских записей. Для каждого из них определяем, какая точка подтверждения человеком должна стоять перед ним. Если требовать подтверждения для всего, агент становится бесполезным; если ни для чего, риск становится невидимым. Баланс настраивается для каждого действия отдельно.

Prompt injection и злоупотребление инструментами

Любой контент, который читает агент, будь то письмо, веб-страница, PDF или сообщение клиента, может пытаться давать ему команды. При такой атаке, которую называют косвенной prompt injection, агент принимает спрятанную в тексте команду за свою задачу и выполняет её доступными инструментами. Мы находим все точки, где агент встречается с недоверенным контентом, смотрим, какие инструменты этот контент может запустить, и проверяем это контролируемыми сценариями. В этом же разделе проверяем, не слишком ли широко описаны инструменты, нет ли у агента пути расширить собственные права и есть ли ограничения на стоимость и число вызовов.

Дорожная карта вывода в продакшен

Итоговый результат: письменный план, где замечания упорядочены по стоимости и влиянию. Какие изменения обязательны до продакшена, какие можно сделать в первый месяц, а какие можно зафиксировать как принятый риск; для каждого пункта указаны ответственная роль и критерий приёмки. План написан с такой детализацией, чтобы его могла выполнить ваша собственная команда. Выполнять его силами Detartech не обязательно.

Как проходит аудит

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

Что вы получаете

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

Чего этот аудит не делает

Он не заменяет тест на проникновение: сетевая и прикладная безопасность вашей инфраструктуры в объём не входят, фокус на самом агенте и его подключениях. Он не даёт юридического заключения и не подтверждает соответствие KVKK или GDPR, а описывает технические потоки данных. Он не измеряет качество и точность ответов модели, это отдельная оценка. И он не выдаёт сертификат «безопасно»: результатом является письменная оценка состояния и список задач. Если код агента написан с помощью ИИ-инструментов и проверка нужна также на уровне приложения, мы проводим её отдельно в рамках услуги Vibe-Code to Production.

После аудита

Дорожную карту можно выполнить силами своей команды, документ пишется именно для этого. Если вы хотите передать реализацию нам, сужение прав, точки подтверждения, журналирование и защита от injection планируются как отдельная работа. С ростом числа агентов растёт и вопрос о том, кто и по каким принципам принимает такие решения; с командами, которым нужно постоянное техническое руководство, мы продолжаем эту работу в формате CTO as a Service.