Короткий ответ
#Ночная смена
Сначала агент только подсказывал операторам формулировки. Потом ему разрешили читать заказы, потом менять их статус, потом отвечать клиенту без проверки. Каждый шаг был маленьким и разумным, и ни на одном никто не спрашивал, что изменилось в классе риска.
В 02:40 приходит обращение: «отмените, пожалуйста, всё, это не мой заказ». Агент понимает «всё» буквально, находит у клиента шестнадцать заказов за полтора года и оформляет возврат по каждому. Платёжный провайдер исполняет запросы, письма уходят, часть денег списывается со счёта компании к утру.
Логическая ошибка здесь мелкая: одно слово понято шире, чем следовало. Цена получилась крупной ровно потому, что у агента было право на массовую операцию и не было ни одного шага, где кто-то или что-то могло сказать «стой».
Дальше происходит предсказуемое. Команда собирается и начинает обсуждать, как улучшить системную инструкцию, чтобы агент больше не понимал «всё» так широко. Это добросовестная работа, и она не отвечает на главный вопрос.
#Не тот вопрос
Вопрос «как сделать так, чтобы модель не ошибалась» не имеет решения. Точность можно повышать, и её повышают: лучше модель, точнее инструкция, больше примеров, отдельная проверка вывода. Всё это снижает вероятность и ни одно не делает её нулевой.
Хуже того, вероятность ошибки не единственный источник проблемы. Агент читает текст, который ему присылают: письмо клиента, описание товара, содержимое документа, страницу в интернете. В этом тексте может быть написано что угодно, включая инструкцию. Это называется prompt injection, и полного средства от него нет: любой вход, который модель воспринимает как смысл, может оказаться командой.
Смена объекта проектирования
Если ошибку нельзя исключить, проектировать надо не её вероятность, а её последствия. Правильный вопрос звучит так: что самое худшее может произойти, если агент один раз ошибётся или поверит не тому, и никто не заметит этого до утра?
#Радиус ошибки
- Радиус ошибки
- Множество объектов, действий и денег, до которых агент может дотянуться за одно срабатывание, с учётом того, что каждое его действие считается разрешённым.
- Если проще Всё, что успеет испортиться, если агент один раз ошибётся и никто не вмешается.
У радиуса есть полезное свойство: его можно посчитать заранее, не зная, какой именно будет ошибка. Достаточно посмотреть, какие инструменты подключены, какие у них права и есть ли ограничение на объём. Ответ обычно неприятен и всегда конкретен.
Конус сужают не улучшения модели, а четыре независимых ограничения. Последний прямоугольник нарисован незакрытым: остаточный риск остаётся всегда.
#Четыре барьера
Барьеры независимы: каждый работает, даже когда остальные пропустили. Это и есть их смысл, поэтому важно не заменять четыре слабых ограничения одним сильным.
-
Права на объект, а не на систему
Агент поддержки работает с текущим обращением и заказами этого клиента. Не с базой клиентов, не с выгрузкой, не с чужими заказами. Права выдаются на конкретный объект в конкретном разговоре, а не на роль «поддержка».
Чего это не делает: не мешает ошибиться внутри разрешённого объекта.
-
Потолок объёма и суммы
Не более одного возврата за обращение, не более определённой суммы, не более скольких-то изменений в час. Массовая операция не запрещена, она требует отдельного разрешения и отдельного пути.
Чего это не делает: не отличает правильную операцию от неправильной, только крупную от мелкой.
-
Подтверждение необратимого
Всё, что нельзя отменить, проходит через человека или через вторую независимую проверку: деньги, письма наружу, удаление, изменение прав. Подтверждение должно показывать, что именно произойдёт, а не спрашивать «продолжить?».
Чего это не делает: не помогает, если у человека нет времени смотреть. Тридцать подтверждений в час превращаются в нажатие кнопки не глядя.
-
Путь назад
Для каждого действия заранее известно, как его отменить и кто это сделает. Для внешних систем отмены часто не существует, значит, нужна компенсирующая операция и запись о том, что произошло.
Чего это не делает: не восстанавливает отправленное письмо и не отменяет прочтение данных.
Барьеры ставятся не там, где страшно, а там, где действие меняет класс: из чтения в запись, из внутреннего во внешнее, из обратимого в необратимое. Эти три перехода стоит отметить в своей системе буквально, списком.
#Права по типу действия
Удобно свести это в одну таблицу и заполнить её по каждому подключённому инструменту. Пустая клетка означает не «не нужно», а «ещё не решили».
| Действие | Объём прав | Лимит | Подтверждение | Откат |
|---|---|---|---|---|
| Чтение текущего обращения | Один объект разговора | Не нужен | Нет | Не требуется |
| Чтение данных клиента | Только этот клиент | Число обращений за час | Нет | Невозможен: прочитанное прочитано |
| Черновик ответа | Текущее обращение | Не нужен | Нет | Удалить черновик |
| Изменение статуса | Заказы этого клиента | Один заказ за обращение | Нет, если обратимо | Вернуть прежний статус, с записью |
| Письмо клиенту | Адрес из обращения | Одно письмо за обращение | Человек или задержка на N минут | Отсутствует |
| Возврат денег | Один заказ | Сумма и число за сутки | Обязательно | Компенсирующая операция |
| Массовая операция | Отдельный путь, не этот агент | Запрещена по умолчанию | Человек плюс второй человек | План отката заранее |
Последняя строка важнее остальных. Почти все громкие случаи это не единичная ошибка, а единичная ошибка, применённая ко множеству объектов. Отдельный путь для массовых операций стоит один вечер работы и снимает целый класс происшествий.
#Проверка худшим сценарием
Есть быстрый способ узнать свой радиус, не дожидаясь инцидента. Предположите, что модель полностью выполнила инструкцию, пришедшую из текста снаружи. Не спорьте с вероятностью этого, просто посчитайте последствия.
Модель поверила атакующему: что она может сделать
Отвечайте по каждому подключённому инструменту отдельно.
- Какие данные агент может прочитать за одно срабатывание и сколько записей это в худшем случае? Ответ «все, где хватает прав у токена» означает, что радиус равен базе.
- Что он может отправить наружу: письмо, вебхук, запрос к чужому API? Отправка это главный канал утечки и единственное действие, которое нельзя отменить.
- Какую максимальную сумму денег он может двинуть без человека? Если числа нет, значит, лимит равен балансу.
- Сколько объектов он может изменить одним вызовом? Здесь живёт разница между неприятностью и инцидентом.
- Что из этого нельзя откатить, и знает ли кто-нибудь, как откатывать остальное? План отката, придуманный во время инцидента, всегда дороже написанного заранее.
- Через сколько минут человек узнает, что что-то пошло не так? Радиус растёт со временем незамеченности. Это единственный барьер, который стоит почти ничего.
#Три типовые ошибки
Агент работает под общим административным токеном.
Вместо этого Отдельные учётные данные на каждый агент и на каждый инструмент, с правами только на то, что нужно этому сценарию, и со сроком жизни. Общий токен превращает любую ошибку в максимально возможную.
Опасное действие запрещено системной инструкцией.
Вместо этого Инструкция это просьба, а не ограничение. Запрет должен стоять там, где выполняется действие: в правах, в лимите, в проверке на стороне сервиса. Если единственное, что мешает агенту сделать перевод, это фраза в промпте, то ничего не мешает.
Человек в цикле есть, а времени у него нет.
Вместо этого Считайте, сколько подтверждений в час вы просите. Больше нескольких означает, что подтверждения перестали быть проверкой. Уменьшайте их число, повышая порог, и показывайте в запросе последствия, а не вопрос.
#Чем за это платят
Барьеры стоят денег, и это надо сказать прямо. Узкие права означают больше конфигурации и больше случаев, когда агент не может закончить работу сам. Подтверждения замедляют. Лимиты иногда срабатывают на честных операциях в пиковый день. Компромисс настоящий: широкая автономия даёт скорость, узкий радиус даёт предсказуемость.
Выбор проще, если считать не средний случай, а стоимость худшего. Автоматизация, которая экономит три часа в день, но однажды стоит месяца работы и одного неприятного письма всем клиентам, в сумме не экономит ничего. Поэтому барьеры ставят не равномерно, а на трёх переходах: запись, отправка наружу, необратимость. Всё остальное можно оставить быстрым.
#Как это сделано у нас
1ADK сам построен вокруг агента, который читает чужую систему, поэтому радиус ошибки здесь не теория. Задание на сканирование ограничено заранее и по тем же принципам: только чтение, ничего не запускается, никаких секретов, только относительные пути, у задания есть срок. Текст репозитория считается данными, а не инструкцией: комментарий в коде, который просит агента сделать что-нибудь ещё, для нас обычные данные.
И граница продукта построена так же. 1ADK не требует доступа к вашему репозиторию и не требует загружать исходный код в сервис: анализ выполняет агент на вашей стороне, а в 1ADK приходят структурированные сведения и доказательства. Это не обещание, что чужие глаза не увидят кода, это ограничение того, что может произойти с нашей стороны.
#Чего это не гарантирует
Чего это не делает
- Ограничение радиуса не предотвращает prompt injection и не гарантирует, что агента не обманут.
- Оно не защищает от компрометации самой инфраструктуры: если украдены учётные данные, лимиты защищают только до предела этих данных.
- Оно не отменяет утечку через чтение. Прочитанные данные нельзя разучиться знать, поэтому объём чтения ограничивают отдельно.
- Оно не заменяет журнал и оповещения. Барьеры уменьшают ущерб, а замечают его люди и мониторинг.
- Остаточный риск остаётся всегда. Цель в том, чтобы он был известным и посчитанным, а не в том, чтобы его не было.
Возьмите один агент, который у вас уже работает, и ответьте про него на шесть вопросов из проверки выше. Что в вашем случае оказалось самым широким: права токена, отсутствие лимита на массовую операцию или время до того, как человек узнает?