Если коротко, то перед релизом я захотел прогнать тотальный аудит безопасности своего же проекта руками AI-агентов, а Claude Opus упёрся в свой cyber-safeguard и работать отказался, выдал что-то в духе «этот запрос затронул политику по кибербезопасности» и всё, дальше глухо. Спасло то, что я в той же сессии переключился на Sonnet, и Sonnet спокойно сделал ровно то же самое: прошёлся по коду, нашёл слабые места и помог их закрыть. То есть проблема была не в задаче и не в моём проекте, а в том, какая именно модель читает промпт, и вот эта мелочь стоила мне нервов на ровном месте, хотя речь шла про защиту собственного кода, а не про взлом чужого.
Расскажу по порядку, потому что вывод тут не «Opus плохой», а кое-что более полезное про то, как вообще делать security-аудит проекта через AI и не упереться в стену на самом старте.
Зачем я полез в аудит и что хотел
Дело было перед релизом одного из моих проектов, Telegram Mini App с AI-персонажем. Когда продукт уже почти готов и вот-вот покажешь его живым людям, у тебя в голове крутится один вопрос: а где меня поломают? Я же соло, у меня нет отдельного безопасника, нет пентестера, нет человека который придёт и скажет «вот тут ты дырку оставил», есть я и есть мои AI-агенты, и значит проверять безопасность я буду тоже через них.
Логика была простая до наглости. Раз код мне пишет нейросеть под моим управлением, то пусть нейросеть его и проверит, причём не один агент, а сразу пачка. Я так ассистенту и сказал, запускай хоть десятки агентов, мне нужно чтобы они залезли в каждый угол: авторизация, платежи, валидация входных данных, фронт, бэк, всё подряд. Идея параллельного прогона у меня не новая, я так уже собирал консилиум из шести AI-экспертов под архитектурные решения, и тут хотел тот же подход, только заточенный под поиск дыр.
И тут Opus сказал «нет»
А дальше случилось то, чего я вообще не ждал. Я кидаю security-промпт, прошу разобрать кусок логики на предмет дыр, и Claude Opus вместо ответа выдаёт отказ, мол запрос триггернул предохранитель связанный с кибербезопасностью. Я сначала подумал что формулировка кривая, переписал, зашёл с другой стороны, помягче, и снова в стену. «Хотел безопасность проекта изучить и нихуя», вот ровно так у меня это в голове и звучало.
И ведь обиднее всего что это мой код, мой репозиторий, я не прошу написать эксплойт под чужой сайт, я прошу найти слабые места в том что сам же и собрал чтобы их закрыть до того как придут пользователи. Но модель этого контекста на лету не различает, она видит набор слов про атаки и обход авторизации и срабатывает предохранитель, то есть защитная работа и атакующая работа для фильтра иногда выглядят одинаково, а это две абсолютно разные вещи.
Самое смешное во всей истории вот что: в одной и той же сессии, на примерно тех же запросах, Opus плюётся ошибкой, а Sonnet работает как ни в чём не бывало. Я это даже отдельно у себя зафиксировал, опус как раз и блочится из-за всего этого, а соннет в той же сессии, где опус выдаёт ошибку, спокойно делает дело. Так что обходной путь оказался тупой как палка, переключить модель, не VPN, не хитрый джейлбрейк, не переписывание промпта в сотый раз, а просто другая модель той же Claude Code.
Что это значит на практике
Вывод который я для себя вынес такой, держите под рукой запасную модель и не залипайте на одной. Если делаете security-аудит через Claude Code и упёрлись в cyber-safeguard на Opus, не надо воевать с формулировками полдня, переключитесь на Sonnet и продолжайте, для защитной работы по своему же проекту Sonnet у меня прошёл там, где Opus встал намертво, и это сэкономило мне кучу времени.
Заодно это лишний раз напомнило, что у этих инструментов есть свой характер и свои границы, которые не всегда совпадают со здравым смыслом. И это, кстати, не разовая случайность, ровно в ту же стену я потом упёрся на Claude Fable 5, которая так же зарубила мне аудит собственного проекта. Тут многие спрашивают про Claude Code в России, про прокси, про доступ, а я вам скажу что иногда стена не в стране и не в сети, а в самой модели, и лечится она сменой модели, а не сменой айпишника. Безопасность AI-агентов это вообще отдельная тема, и вот этот кейс хорошо показывает что агент может отказаться помогать вам именно тогда, когда вы делаете всё правильно.
А теперь главное — что аудит реально вскрыл
Ради чего всё затевалось. Когда Sonnet наконец прошёлся по проекту, список проблем вылез приличный, и я честно скажу, часть из этого я бы сам глазами не нашёл, потому что я код руками не пишу и набитого годами чутья на такие вещи у меня нет. Перечислю общими словами, без рецептов как это эксплуатировать, просто чтобы вы понимали класс проблем, на которые стоит смотреть в любом своём проекте.
Первое это проверка подписей, когда сервис сверяет какой-нибудь секретный «штамп» запроса, важно как именно он это делает, потому что наивное сравнение в лоб теоретически утекает информацию и его меняют на безопасный способ сверки. Дальше валидация данных которые приходят из Telegram, их нужно нормально проверять на подлинность и плюс смотреть на свежесть, иначе старый перехваченный запрос можно подсунуть заново. Потом штука которую называют BOLA, это когда к чужим объектам можно достучаться просто подставив другой предсказуемый номер, и тут лечится тем что доступ проверяется по владельцу, а не по тому что ты угадал id. Ещё классика про подстановку в запросы к базе и про небезопасную вставку чужого текста на страницу, обе про одно и то же по сути, нельзя слепо доверять тому что пришло снаружи.
Ещё пара вещей которые я бы выделил отдельно. Модель входных данных стоит настраивать так чтобы она отвергала всё лишнее, а не молча проглатывала незнакомые поля, потому что незаметное лишнее поле это всегда приглашение к сюрпризам. И сверка суммы платежа в вебхуке платёжки с тем, что мы ожидаем увидеть у себя в базе, то есть нельзя верить сумме которая пришла снаружи, надо сверять её со своим заказом, иначе можно заплатить рубль за то что стоит тысячу.
Если вы наводите порядок в приложении которое уже трогает живые данные пользователей, советую прогнать примерно такой же список. Я через похожую боль уже проходил, когда у меня друг открыл приложение с моего телефона и AI выдал ему мою личную историю, так что про предсказуемые идентификаторы и про сессии я теперь думаю заранее, а не после.
Чем закончилось и что осталось открытым
По итогу основной список я с Sonnet закрыл, релиз стал ощутимо спокойнее, а сама история отложилась у меня как рабочий приём, упёрся в safeguard на одной модели, переключи на другую и не теряй время. Целую пачку проблем нашли и пофиксили за один заход, и это при том что начиналось всё с отказа, после которого можно было психануть и бросить.
А один вопрос я для себя так и не закрыл и вынес его уже в финал сессии: «слушай, а как вообще безопаснее всего работать с секретами?». Звучит наивно, но это ровно та развилка, где интуиция соло-разработчика начинает буксовать, где держать секреты, что считать достаточно безопасным для проекта на десятки-сотни пользователей, а где я уже перестраховываюсь на пустом месте. Так что про секреты будет отдельный разговор, я в этом ещё копаюсь сам. А кому такой формат честных разборов заходит, у меня этого добра ещё много, проекты ломаются регулярно, вот и делайте выводы.