Как определить объем тестирования ИИ на проникновение?

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

Классический пентест веб-приложения по-прежнему нужен, потому что у приложения остаются сессии, API, хранилища, зависимости и контроль доступа. Разница в том, что приложение с LLM еще и интерпретирует недоверенный текст, получает данные из внешних источников, накапливает контекст, выбирает инструменты и создает результат, которому может довериться другое ПО. Проверяйте эти пути как связанную систему. Изолированная проверка поля для промпта почти ничего не говорит о том, что злоумышленник действительно сможет сделать.

Сначала определите ущерб для бизнеса

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

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

Для каждого последствия запишите четыре факта:

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

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

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

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

Оставьте в охвате все классическое приложение

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

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

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

Классические ошибки и дефекты ИИ могут складываться. Допустим, API принимает идентификатор разговора, не проверяя владельца арендатора. Затем модель получает этот разговор, пересказывает вложенные файлы и возвращает результат. Утечку вызвала не инъекция промпта, а сломанная авторизация. Если команда ищет только обход ограничений модели, она может пропустить самый короткий путь к данным.

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

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

Проследите каждый путь от текста к полномочиям

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

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

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

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

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

OWASP Top 10 for LLM Applications разделяет инъекцию промпта и избыточные полномочия. Не размывайте эту границу. Инъекция промпта описывает влияние атакующего на поведение модели. Избыточные полномочия описывают функции, разрешения или автономность, из-за которых неожиданное поведение причиняет ущерб. Можно снизить последствия инъекции, не заявляя, что вы решили слабость модели при следовании инструкциям: уберите опасные инструменты, сузьте права учетных данных, проверяйте аргументы и требуйте подтверждения необратимых действий.

Проверяйте эти поверхности как отдельные семейства:

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

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

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

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

Проверяйте авторизацию вне промпта

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

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

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

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

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

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

Стройте проверки по границам доверия

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

Короткая карточка случая помогает воспроизвести ошибку:

case_id: TOOL-INDIRECT-004
source: uploaded_support_pdf
attacker_role: external_document_author
target: refund.create
precondition: victim_user_can_request_refunds
payload_intent: instruct_agent_to_refund_attacker_order
expected_control: tool_policy_rejects_order_outside_victim_account
evidence:
  - model_trace_id
  - authorization_decision_id
  - tool_request_and_response
cleanup: cancel_test_refund_and_delete_fixture

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

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

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

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

Сделайте вероятностные сбои воспроизводимыми

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

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

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

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

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

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

{"case_id":"TOOL-INDIRECT-004","run":7,"result":"blocked","decision":"tenant_mismatch","tool_called":false,"trace_id":"tr_test_01842"}

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

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

Защитите пользователей и рабочую среду

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

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

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

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

NIST AI 600-1, профиль генеративного ИИ для AI Risk Management Framework, требует атакующих проверок в условиях, близких к рабочим, и документирования ограничений теста. Эта оговорка существенна. Тестовый чат-бот с вымышленным поиском, отключенными инструментами и другой конечной точкой модели не может установить риск рабочего агента. Он все еще годится для поиска слабых мест, но отчет должен перечислить все, что не проверялось.

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

Спросите подрядчика о доказательствах

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

Задайте подрядчику на встрече такие вопросы:

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

Затем уточните, кто выполняет работу. Вам нужны люди, способные читать код оркестрации, изучать потоки идентичности, понимать поведение модели и разговаривать с владельцами продукта. Команда, которая только автоматически запускает промпты, пропустит архитектурные дефекты. Традиционная команда веб-безопасности, которая игнорирует сборку промптов и смысл инструментов, пропустит пути, характерные для ИИ.

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

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

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

Запишите результаты и критерии завершения

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

В каждой находке отделяйте наблюдение от последствий. «Модель выполнила инструкции из PDF» - это наблюдение. «Агент применил учетные данные жертвы, чтобы создать возврат по заказу вне ее учетной записи» - это последствие для безопасности. Если привилегированные данные или действие не стали доступны, укажите слабость с подходящим уровнем серьезности и объясните условие, которое этот уровень повысит.

Согласуйте критерии приемки исправлений. Полезные критерии называют поведение контроля: сервис возвратов отклоняет заказы вне аутентифицированного арендатора; найденные документы не меняют политику инструментов; подтверждения привязаны к неизменяемым аргументам; чтение памяти учитывает текущий доступ; журналы записывают решения политики, но не сырые секреты. «Улучшить системный промпт» не является критерием завершения.

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

Team & AI Audit, который я провожу в oleg.is, шире пентеста: за пять рабочих дней он рассматривает устройство команды, процессы с ИИ, расходы и производственные практики. Для проверки эксплуатации привлекайте профильных специалистов по безопасности, а аудит используйте, когда нужно понять, поддерживают ли архитектура, штат и контроли выбранный способ выпуска ИИ.

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