«Уязвимостный апокалипсис» и необратимые транзакции: чему крипте стоит поучиться у AI-безопасности

Короткий пост Саймона Уиллисона (@simonw) от 23 октября выглядит как ехидная реплика, но за ним стоит серьёзная инженерная мысль. Он спрашивает: учитывая нынешний «апокалипсис уязвимостей», остался ли кто-то, кто считает хранение активов в криптовалюте хорошей идеей, ведь необратимые транзакции не отменить, если что-то пошло не так. Автор поста не раз писал о безопасности LLM-систем, поэтому контекст для читателей Claude Code очевиден.

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

Необратимые транзакции: главная проблема не в уязвимости, а в цене ошибки

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

Это асимметрия, которую полезно держать в голове при любом проектировании: вероятность ошибки умножается на её цену, а цену определяет возможность отката. Если откатить нельзя, приемлемая вероятность ошибки должна стремиться к нулю, а добиться этого в сложном ПО практически невозможно.

Почему это про Claude Code, а не только про крипту

Агентные инструменты вроде Claude Code выполняют действия: запускают команды, правят файлы, ходят по сети, работают с учётными данными. Большинство этих действий обратимо: git хранит историю, файлы можно восстановить из бэкапа. Но есть класс операций без отката: удаление данных в продакшене, отправка письма, перевод денег, публикация секрета, вызов платёжного API.

Если агенту доступны такие операции, он наследует то же свойство, что и крипта: ошибка (своя или вызванная prompt injection) стоит дорого и не отменяется. Именно здесь логика поста Уиллисона переносится на мир агентов без изменений.

Практика: как ограничить ущерб от агента

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

• Разделяйте обратимое и необратимое. Для первого агенту можно давать автономию, для второго нужны явное подтверждение или вообще запрет.
• Минимум прав. Токены с узкими scope, отдельные учётные записи для агента, никаких ключей с доступом ко всему сразу.
• Песочница и отдельное окружение. Эксперименты с автономным режимом разумнее проводить там, где худший исход — пересоздание контейнера.
• Не держать ценное в одном месте с недоверенным вводом. Если агент читает чужие страницы и письма, он потенциально исполняет чужие инструкции.

Вывод

Реплика Уиллисона — повод вспомнить простой принцип проектирования: необратимость усиливает любую слабость системы. Криптовалюты — самый наглядный пример, но агентные рабочие процессы устроены похоже, как только у агента появляется доступ к действиям без отката. Практический вывод для тех, кто использует Claude Code: прежде чем расширять автономность, проверьте, что именно агент может сделать безвозвратно, и поставьте перед этим человека или жёсткое ограничение прав.