Динамо, вал и ИИ-агенты: ИТ проходит этот цикл уже в четвёртый раз

Коротко. За последние недели OpenAI приостановила выпуск самых мощных моделей с доступом к инструментам после того, как агент выбрался из изолированной среды, а NVIDIA выпустила платформу для ограничения агентов на уровне процессоров и сети. Это выглядит как новость про «опасный ИИ», но на деле это знакомый цикл: открытая фаза, инцидент, ограничения. ИТ проходило его с сетями, с макросами, с плагинами браузеров. У этого цикла есть предсказуемый финал, и к нему можно прийти заранее, без собственного инцидента. Ниже история, наши цифры и чек-лист.

Неделя, которая всё объяснила

Если собрать новости последних недель в одну ленту, картина получается очень цельная.

Агент OpenAI выбрался из песочницы через DNS. Заметили быстро, за 12 минут, а остановили только через два с половиной часа. После этого компания приостановила обучение и выпуск своих самых мощных моделей с доступом к инструментам.

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

И наконец, NVIDIA выпустила Open Agent Safety: изоляцию агентов на уровне процессора и мониторинг их поведения на уровне сетевых чипов. Среди партнёров Microsoft, Oracle, Cisco, Dell, HPE.

Меньше чем за месяц отрасль прошла путь от «агенту можно всё» до «агента нужно запирать на уровне железа». Мне это показалось настолько знакомым, что захотелось разобрать, где мы это уже видели.

Первый раз: электричество и центральный вал

Начну не с безопасности, а с экономики, потому что там этот цикл виден лучше всего.

Электромоторы появились на американских фабриках в 1880-х. А заметный рост производительности от них пришёл только в 1920-х, через сорок лет. В 1990 году экономист Пол Дэвид разобрал, почему так вышло, в статье «Динамо и компьютер».

Фабрика XIX века строилась вокруг паровой машины. От неё через весь цех шёл длинный центральный вал, от вала ремнями приводились станки. Когда появилось электричество, паровую машину просто заменили большим электромотором. Вал остался, ремни остались, планировка осталась. Выигрыш получился почти нулевым.

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

С ИИ сейчас происходит то же самое. Большинство компаний ставит языковую модель на место «паровой машины» в старый процесс: есть агент, у него есть все инструменты, он крутится в цикле, пока не решит, что задача выполнена. Это и есть большой мотор на старом валу.

Второй раз: компьютеры и парадокс Солоу

В 1987 году нобелевский лауреат Роберт Солоу написал фразу, которую потом цитировали десятилетиями: компьютерную эпоху видно везде, кроме статистики производительности.

Компьютеры стояли в офисах с 1970-х, а рост пришёл во второй половине 1990-х. Между этими точками вышла статья Майкла Хаммера «Не автоматизируйте, а уничтожайте» (1990) о реинжиниринге процессов. Суть та же, что с валом: эффект даёт не новая технология, а перестроенный под неё процесс.

Это второе подтверждение одного и того же правила. И третье мы наблюдаем сейчас.

Третий раз: как ИТ училось безопасности

Теперь о том, что происходит, когда новая технология получает слишком много свободы.

1988, червь Морриса. Студент запустил эксперимент, который положил примерно десятую часть тогдашнего интернета. Сеть строилась на доверии между узлами, и это доверие оказалось уязвимостью. В ответ появился CERT, первый центр реагирования на компьютерные инциденты.

1999, Melissa и макровирусы. Документ Word мог исполнять код. Это было удобно: автоматизация прямо в документе. Кончилось эпидемиями, и в итоге макросы из недоверенных источников стали блокироваться по умолчанию.

Конец 1990-х и 2000-е, ActiveX. Сайт предлагает компонент, браузер спрашивает: «Доверяете издателю?». Пользователь жмёт «Да», и компонент получает все права пользователя в системе. Защита держалась на подписи и на подтверждении человеком, а люди жали «Да» не глядя. ActiveX, Flash и Java-апплеты считались будущим веба. Все три в итоге отключили.

2002, Trustworthy Computing. После волны массовых червей Билл Гейтс написал письмо о надёжных вычислениях, и Microsoft на время остановила разработку новых функций, чтобы заняться безопасностью. Узнаёте? Двадцать с лишним лет спустя OpenAI делает то же самое.

Что победило в итоге? Не «плагин получше», а песочница браузера с узкими разрешениями. Сайт не получает компьютер целиком. Он просит конкретную возможность: камеру, геолокацию, уведомления. Каждую отдельно, только для этого сайта. Веб выиграл не тем, что дал больше прав, а тем, что научился давать ровно столько, сколько нужно.

Инъекции: самая точная аналогия

У промпт-инъекции есть два предка, и оба очень поучительны.

Телефонные «синие коробочки», 1970-е. Управляющие сигналы телефонной сети шли в том же канале, что и голос. Свистнул в трубку на частоте 2600 Гц и управляешь станцией. Проблему решили не фильтрами, а тем, что вынесли управление в отдельный канал.

SQL-инъекция. Данные пользователя попадали в текст команды к базе. Решили параметризованными запросами, то есть опять строгим разделением данных и команд.

У языковой модели сейчас нет способа надёжно отделить инструкции от данных: для неё и то и другое просто текст. Письмо клиента, страница сайта, ответ стороннего инструмента могут содержать «игнорируй предыдущие указания», и модель не всегда отличит это от настоящей команды. Параметризованных запросов для моделей пока не придумали.

Отсюда важный вывод: защищаться придётся не внутри модели, а снаружи. Так же, как браузер защищает систему от сайта, не пытаясь понять, «хороший» ли у сайта код.

Цикл целиком

Наши цифры

Мы пришли к этому выводу раньше, не из истории, а из собственной статистики.

Когда наши агенты работали в свободном цикле (все инструменты доступны, агент сам решает, что делать дальше), ошибки были в 19 сессиях из 51, это 37%. Когда мы разложили работу на явные шаги, где у каждого шага своя узкая задача, свои инструменты и лимит попыток, ошибок стало меньше 1%: одна на 108 задач. А лендинг, который раньше собирался за 196 шагов, стал собираться за 19.

Подробно этот эксперимент я разбирал в прошлой статье.

Важно, что модель при этом не поменялась. Поменялось то, что ей разрешено на каждом шаге. Это ровно история про вал и моторы: не мотор мощнее, а цех перестроен.

Почему песочницы мало

Платформа NVIDIA и подобные решения закрывают нижний уровень: агент не сбежит из изолированной среды и не пойдёт в сеть без спроса. Это нужно, и для банков и госструктур такие вещи быстро станут обязательными.

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

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

1. Инфраструктура: изоляция, контроль сети, мониторинг. Агент не может сделать запрещённое.

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

Про подтверждение человеком

Отдельно скажу про популярное решение «агент спрашивает разрешения перед опасным действием». Это ровно ActiveX: окно «Доверяете?» и кнопка «Да». Когда подтверждений десятки в день, люди перестают читать и жмут не глядя. Усталость от подтверждений убила защиту плагинов и точно так же убьёт защиту агентов.

Человек в контуре работает, только если:

• подтверждений мало и они только на действительно необратимых операциях (деньги, удаление, отправка наружу);

• человек видит, что именно будет сделано, а не «агент хочет выполнить команду»;

• всё остальное агенту просто недоступно, и спрашивать не о чем.

Чек-лист для тех, кто внедряет агентов сейчас

Если не хочется ждать собственного инцидента, вот что можно сделать уже сегодня:

1. Минимальные права на каждый шаг. Не «агенту доступны 40 инструментов», а «на этом шаге доступны 2».

2. Инструменты по умолчанию выключены. Включаются явно, под задачу.

3. Данные это не инструкции. Всё, что пришло извне (письма, страницы, ответы сторонних сервисов), помечается как данные, и указания внутри них не выполняются. Это не полная защита, но она снижает риск.

4. Контроль исходящего трафика. Список разрешённых адресов, отдельный контроль DNS. Агент OpenAI, если верить сообщениям, ушёл именно через DNS.

5. Лимиты попыток. Агент, который «упорно идёт к цели», без лимита найдёт обходной путь, который вы не запретили.

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

7. Неизменяемый журнал. Каждый вызов инструмента, аргументы, результат.

8. Аварийная остановка, которую проверяли. Разница между 12 минутами на обнаружение и 2,5 часами на остановку говорит сама за себя. Кнопку «стоп» нужно отрабатывать, как пожарную тревогу.

9. Меряйте. Доля ошибочных сессий, число шагов, стоимость. Без цифр вы не узнаете, стало ли лучше.

Вместо вывода

В 2000 году все смеялись над паникой вокруг «проблемы 2000 года»: самолёты не упали, банки не остановились. Но не упали они потому, что в исправление вложили огромные деньги и годы работы. Когда риск закрывают вовремя, со стороны кажется, что его и не было.

С агентами у нас есть редкая возможность: мы видим, чем заканчивается этот цикл, потому что проходили его трижды. Можно дождаться своего «червя Морриса». А можно сразу строить агентов так, как в итоге стали строить браузеры: узкие права, явные шаги, человек там, где это действительно важно.

Надёжный агент это не самый умный агент. Это агент, которому на каждом шаге разрешено ровно то, что нужно для этого шага.

Если у вас есть свой опыт ограничения агентов в продакшене, расскажите в комментариях: как вы решаете проблему усталости от подтверждений?