
Комментарии 10
Такое чувство, что автоматическое сканирование llm на уязвимости это какая-то кроличья нора
Сфера только развивается. Пока что в принципе много белых пятен. Время должно всё расставить на места))
Согласен).
Автоматизированное выявление уязвимостей должно быть только одним из методов контроля. Дальше нужна экспертная оценка применимости уязвимостей, моделирование реализации актуальных угроз, проверка достаточности реализованных мер защиты и, при необходимости, компенсирующие меры.
спасиб за интересный материал
Пара вопросов: По цифре “GigaChat-2 MAX в 208 раз дороже DeepSeek” от Nodul — интересно, какие именно тарифы и сценарии там сравнивались? DeepSeek через публичный API и корпоративный GigaChat это всё-таки разные продукты в разных периметрах и Denial-of-Wallet как риск зависит скорее от разрыва “цена токена vs маржа на запрос”, чем от абсолютной стоимости. Если есть ссылка на методологию, было бы здорово.
И про LLAMATOR: вы сами отмечаете, что публичных ASR-цифр в README нет, но при этом она идёт как заметно более сильная на русском в 2–4 раза. Это внутрение замеры команды или где-то есть воспроизводимый бенч? Хочется понять, на что опираться при выборе. В остальном плейбук на четыре уровня выглядит здраво, особенно акцент на ручной экспертизе, её и правда мало кто закладывает в скоуп.
«208», конечно, как показатель для новости звучит ярко.
Но если рассуждать, то DoW лучше оформлять не через абсолютную цену токена, а через недопустимое событие (негативное последствие), т.е. исчерпание лимитов, нарушение функционирования сервиса, использование ИС не по назначению, рост затрат на обработку запросов сверх допустимых значений. Тогда уже можно задавать контролируемые параметры (лимиты по токенам, сессиям, инструментам, внешним вызовам, контексту, RAG-запросам и событиям мониторинга ИБ).
Методология, насколько её раскрыли в пресс-релизе (полный отчёт публично не выкладывали, есть версии у CNews и Sostav): взяли 9 типовых сценариев — переводчик (1 тыс. знаков), копирайтер (10 тыс. знаков), оператор поддержки (одно обращение), документооборот, секретарь на 5 минут разговора, SDR на лиде, супервайзер кол-центра, HR на одном резюме, аналитик на сводном отчёте из 10 документов. Для каждого посчитали ввод/вывод в токенах и умножили на действующие публичные тарифы. Цифра 208× — это именно копирайтинг на 10 тыс. знаков (154,5 ₽ против 0,74 ₽).
Воспроизводимого публичного бенча с конкретными ASR-цифрами по русскому у них действительно нет. В README (актуальный 3.5.0 от января 2026) есть только перечень атак с маркерами, классификация по OWASP и описание архитектуры attack/tested/judge — без таблиц сравнения. Цифра «в 2–4 раза выше базового на русском» для Linguistic Sandwich — это, насколько я понимаю, внутренний замер команды AI Security Lab ИТМО, который мелькал в их докладах и обсуждениях, но не оформлен как публикация
Хорошая систематизация. От себя добавлю по практике пентестов агентных систем: классический LLM-prompt-injection — это только поверхность. Самое больное начинается когда у агента есть tool-use (особенно MCP-серверы) — там вектора уже не “обмани модель”, а “подмени контекст через downstream-сервис”. OWASP Agentic AI Top-15 описывает 7 таких векторов отдельно от LLM Top-10. У нас в практике ещё ни один MCP-сервер не прошёл проверку на tool-poisoning с первого раза, включая популярные опенсорсные. Авторы, не планируете дополнить обзор agentic-частью?
LLM-пентест в 2026: что изменилось за год