Разработчик просит AI написать новый обработчик API. Код компилируется, тесты проходят, интерфейс работает, но в одном месте отсутствует проверка владельца объекта. Пользователь из одного клиента может обратиться к записи другого клиента, если угадает идентификатор. В отчёте сборки всё зелёное, а ошибка уже стала нарушением изоляции арендаторов.
AI-код часто выглядит логично, потому что повторяет привычную структуру: получить объект, изменить поле, вернуть ответ. Но модель может пропустить главное правило безопасности — объект должен принадлежать текущему пользователю или его организации. Такая ошибка не всегда видна статическим тестам и редко ловится позитивным сценарием.
Практическая задача AppSec — проверять не только стиль и синтаксис AI-кода, а инварианты доступа. Если в системе есть арендаторы, проекты, команды или роли, каждый новый путь должен доказывать, что чужой объект недоступен.
Эта тема важна для команд, которые ускоряют разработку с AI и рискуют принять рабочий код за безопасный код.
Типовой сбой авторизации
Сбой обычно возникает на границе объекта. Код проверяет, что пользователь вошёл в систему, но не проверяет, что запись принадлежит его организации. Иногда проверка есть в списке объектов, но отсутствует в детальной карточке, обновлении или удалении.
Такой дефект особенно опасен в многоарендных сервисах. Один забытый фильтр по идентификатор арендатора может открыть счета, документы, задачи или настройки чужого клиента.
- проверять владельца объекта;
- фильтровать запросы по арендатору;
- запрещать прямой доступ по чужому идентификатору;
- тестировать чтение и изменение;
- проверять удаление отдельно;
- не доверять данным из клиента;
- использовать запрет по умолчанию.
Негативные тесты для AI-кода
Для AI-сгенерированного кода негативные тесты обязательны. Позитивный тест показывает только то, что владелец может получить свой объект. Негативный тест доказывает, что соседний пользователь не может сделать то же самое с чужим объектом.
Тесты лучше хранить рядом с правилом доступа. Тогда любое изменение обработчика будет ломать сборку, если разработчик или модель убрали важный фильтр.
- создать двух пользователей из разных арендаторов;
- создать объект для первого пользователя;
- попробовать чтение вторым пользователем;
- попробовать изменение вторым пользователем;
- попробовать удаление вторым пользователем;
- проверить ответ и журнал;
- повторить для каждой роли.
Ревью инвариантов
Ревью кода должно содержать отдельный пункт про авторизацию. Ревьюер не должен искать только опасные функции или секреты. Он проверяет, где формируется запрос к данным, откуда берётся идентификатор арендатора, можно ли подменить идентификатор и какие условия сохраняются при изменении роли.
Если AI предложил изменение в зоне доступа, ревью должно быть строже, чем для обычной правки интерфейса. Любая новая точка API должна иметь доказательство отказа для чужого объекта.
- проверить источник идентификатор арендатора;
- проверить серверную фильтрацию;
- найти прямые обращения по ID;
- проверить обход через поиск;
- проверить массовые операции;
- сравнить роли до и после изменения;
- добавить тест отказа в задачу.
Журналирование и доказательства
Контроль работает только тогда, когда его можно проверить после инцидента. Для AI-системы важно хранить не только итоговый ответ, но и источник данных, роль пользователя, версию политики, решение фильтра и действие человека. Иначе расследование превращается в спор о том, почему модель ответила именно так.
Команде безопасности нужен единый минимум полей. Он должен попадать в SIEM или отдельный журнал, но с ограничением доступа, потому что сами запросы и ответы могут содержать чувствительные сведения.
- идентификатор пользователя;
- роль и группа доступа;
- источник данных;
- идентификатор документа или объекта;
- решение политики;
- причина блокировки;
- следующее действие;
- владелец исключения.
Порядок внедрения
Начинать нужно с ограниченного сценария, а не со всей компании. Команда выбирает один поток данных, задаёт ожидаемые права, проводит негативные тесты и только затем расширяет область. Такой подход снижает риск скрытой утечки и позволяет быстро исправлять схему доступа.
Для каждого правила нужен владелец. Он отвечает за исключения, срок действия, качество сигнала и связь с рабочим процессом разработки или SOC.
- выбрать критичный сценарий;
- описать роли пользователей;
- подготовить запрещённые примеры;
- включить подробный журнал;
- проверить ложные срабатывания;
- назначить владельца правила;
- повторять тест после каждого изменения.
Метрики качества
Успех нельзя измерять числом красивых ответов модели. Важно считать, сколько запросов было корректно заблокировано, сколько утечек обнаружено тестами, сколько исключений выдано вручную и как быстро владелец данных исправляет неправильные права.
Если метрики показывают рост ручных исключений, значит политика доступа слишком грубая или модель получает данные раньше, чем проверяются права.
- доля заблокированных запрещённых запросов;
- доля ошибочных разрешений;
- время расследования;
- число ручных исключений;
- число повторных нарушений;
- покрытие негативных тестов;
- срок ротации ключей.
Рабочий пример контроля
Команда может начать с простой таблицы проверок. В ней для каждого критичного действия указаны роль, объект, ожидаемый отказ, журнал и владелец правила. Такая таблица удобна тем, что её понимают разработчики, SOC и владелец продукта. Она превращает общую фразу «проверить безопасность AI» в конкретный набор условий.
Пример не должен содержать реальные секреты или производственные данные. Для проверки создаются синтетические пользователи, фиктивные документы, тестовые токены и отдельная среда. Если AI-инструмент не проходит такой тест, его нельзя подключать к рабочему потоку без ограничения прав.
- создать тестовые роли;
- создать разрешённые и запрещённые объекты;
- запустить одинаковые запросы от разных ролей;
- проверить отказ для чужих данных;
- сохранить журнал источников;
- назначить владельца исправления;
- повторить проверку после изменения политики.
Что делать после найденной ошибки
Ошибка в AI-сценарии редко исправляется одной правкой текста запроса. Нужно понять, где именно нарушилась граница: в источнике данных, в индексе, в правах роли, в кэше, в командной среде или в тестах. После этого команда фиксирует не только симптом, но и корневую причину.
Если найденная проблема могла раскрыть данные, нужно считать её полноценным инцидентом низкой или средней тяжести до завершения проверки. Это означает ротацию затронутых ключей, ограничение доступа, уведомление владельца данных и повторный прогон негативных тестов.
- зафиксировать исходный сигнал;
- выделить затронутые роли;
- проверить журналы доступа;
- отключить рискованное исключение;
- ротировать затронутые секреты;
- обновить тесты;
- проверить отсутствие повторов.
