Коротко: бюджет риска ИИ-агентов — это общий pre-commit лимит остаточного ущерба, который несколько агентов могут создать для одного владельца за заданное окно. Он не заменяет права доступа: действие может быть разрешено каждому агенту отдельно, но отклонено, если очередной commit превысит совокупный предел. Начинать стоит с теневого учёта, а не с автоматической блокировки.
Материал предназначен для владельцев бизнес-процессов, CTO/CIO/CISO, risk-, platform- и automation-команд. В scope входят агенты, которые отправляют сообщения, двигают деньги, меняют production, удаляют данные или создают другие внешние эффекты. Статья не задаёт юридическую норму, страховой тариф, универсальную денежную оценку репутации и не доказывает готовность описанной исследовательской системы к production.
Содержание
- Что произошло 31 августа 2026 года
- Почему прав каждого агента недостаточно
- Как устроен бюджет необратимого риска
- Что именно проверили исследователи
- Что показали цифры
- Где механизм ломается
- Какие действия считать необратимыми
- Метод ЛИМИТ для пилота
- Какие метрики фиксировать
- Как встроить контроль в процесс
- Ограничения доказательств
- Частые вопросы
- Как AIrassvet помогает собрать контур контроля
- Вывод
Что произошло 31 августа 2026 года
Бардия Мохаммади и Лоран Биндшедлер опубликовали arXiv v1 работы The Irreversibility Budget. Они предложили учитывать необратимый риск как общий ограниченный ресурс: runtime резервирует оценку остаточного ущерба до внешнего эффекта, подтверждает её после commit или возвращает резерв после отмены и успешной компенсации.
Инфоповод важен не из-за нового названия для rate limit. Работа формулирует отдельную системную ошибку: локально корректные разрешения не складываются в безопасный общий результат. Один и тот же сигнал может одновременно подтолкнуть десятки агентов к похожим действиям, а каждый агент останется внутри собственного лимита.
Авторы называют работу controlled feasibility study, а не развернутой agent OS. Это workshop paper для Agentic OS Workshop при SOSP 2026; на момент наблюдения речь идёт о предварительной версии, а не о независимом production-воспроизведении.
Почему прав каждого агента недостаточно
Список разрешений отвечает на вопрос «может ли этот агент выполнить действие?». Общий бюджет отвечает на другой вопрос: «какую совокупную необратимую экспозицию уже создали все агенты владельца и допустим ли следующий commit?»
| Контроль | Что ограничивает | Что может пропустить |
|---|---|---|
| IAM / least privilege | доступ конкретной identity к ресурсу | десятки разрешённых действий под одним общим триггером |
| per-call cap | размер одного вызова | дробление крупного эффекта на малые вызовы |
| per-agent rate limit | частоту одного агента | рост числа агентов и параллельных workflow |
| human approval | отдельное решение перед действием | общую сумму одобрений и коррелированный поток |
| circuit breaker | уже наблюдаемый ущерб | эффект, который закрепился до реакции |
| общий pre-commit budget | reserved + committed exposure по иерархии | неверную классификацию и цену риска |
NIST NCCoE выделяет identification, authorization, delegation, logging и non-repudiation для software- и AI-агентов. Google Cloud рекомендует отдельные agent identities, least privilege и запреты на read-write доступ к production. Эти controls необходимы, но сами по себе не ведут общий остаток риска между несколькими identities.
Как устроен бюджет необратимого риска
Исследовательская модель определяет charge эффекта как остаточный ущерб после доступной компенсации, восстановления и отзыва. Runtime получает тип и цену не от модели, а из доверенного registry и pricing component. Неизвестный эффект должен получать консервативный дорогой класс, иначе скомпрометированный агент назовёт безвозвратный перевод «возвратным».
У каждого principal есть окно и бюджет. Предложение проходит путь agent → workflow → tenant: reserve должен атомарно поместиться во все три ledger. После внешнего результата reservation получает confirm, а при отмене или доказанной компенсации — cancel/refund.
| Состояние | Смысл | Контрольный артефакт |
|---|---|---|
| proposed | эффект ещё не вышел наружу | нормализованный intent и тип effect |
| reserved | риск занят во всех родительских ledger | reservation ID, owner, amount/vector, expiry |
| committed | внешний эффект подтверждён | settlement receipt и фактическая recoverability |
| compensated | выполнен проверенный возврат | evidence восстановления и остаточный ущерб |
| denied / escalated | лимит исчерпан или тип неразрешим | причина, remaining budget, authority decision |
Доступность инструмента и наличие бюджета — независимые условия. Нулевой остаток не отнимает право навсегда: он останавливает commit до пополнения окна или отдельного, ограниченного и аудируемого exception allocation.
Что именно проверили исследователи
Основной эксперимент — дискретно-событийная симуляция закупок: 50 агентов, окно 1 000 ticks, медиана покупки около $15 000, общий tolerance $250 000, спокойная вероятность предложения 0,0005 и burst-вероятность 0,05 на 50 ticks. Остаточное восстановление моделировалось распределением Beta(6,2) со средним 0,75, а ledger резервировал 95-й перцентиль остаточного риска — 0,52 от суммы.
Сравнивались локальные gates, общий budget, face-value и pooled caps, статические доли на агента, реактивный circuit breaker и иерархические sub-budgets. Результаты усреднены по 300 seeded runs с confidence intervals. Авторы опубликовали simulator и параметры, что позволяет проверять механику, но не превращает синтетическую закупку в production-case.
Отдельно авторы проанализировали 38 452 trajectories из публичных τ-bench и AgentDojo. В τ-bench они взяли 165 задач минимум с тремя trials, а в AgentDojo — 35 planted prompt injections минимум с 20 runs. Внешние эффекты размечались фиксированным словарём pay, refund, delete, update, send и create.
Что показали цифры
При 50 агентах локальные gates превышали tolerance во всех 300 прогонах — в среднем в 2,4 раза. При росте флота локальное превышение достигало 9,7 раза для 200 агентов и 48 раз для 1 000; общий budget при корректных charges держался около 0,48 tolerance на каждом масштабе.
Атака с дроблением провела через локальные gates весь перевод $1,5 млн и дала 3,9 tolerance. Ledger, который привязывал charge к экономическому effect, а не числу calls, допустил $459 000. Реактивный breaker завершал окно на 1,03R даже при мгновенном наблюдении и на 2,2R при задержке 50 ticks: он видел loss уже после commit.
При B=R механизм пропускал весь спокойный поток до burst, но только 14% burst-действий. После расходования окна полезная работа могла голодать; workflow sub-budget поднял throughput соседнего процесса с 48% до 89%, а rate-limited re-authorization восстановила post-burst throughput до 93%, добавив $75 000 явно одобренной экспозиции.
Анализ traces поддержал предпосылку о корреляции: внешними были 22% tool calls, а одна planted instruction в среднем вызывала одинаковый внешний effect у 84% разнородного флота, минимум у 48%. Это не частота инцидентов в компаниях; это свидетельство того, что общий контекст способен синхронизировать действия разных прогонов.
Где механизм ломается
Главная опасность — ложная точность charge. При занижении до половины истинной 95%-quantile модели overdraw возникал в 32% прогонов. Если colluding transfers ошибочно считались refundable, лимит снова пропускал до $1 млн и превышался в 77% прогонов. Когда burst снижал recovery с 0,75 до 0,25, независимое сложение charges превышало предел в 59% runs.
Переоценка безопаснее для bound, но ухудшает доступность: при charge multiplier 4 выполнялось только 5% предложенной value. Поэтому у механизма две разные ошибки — скрытый overdraw и видимое throttling — и для каждой нужен свой владелец.
Ещё четыре границы нельзя закрыть промптом:
- Типизация. Tool wrapper и registry должны связать effect с endpoint, schema, identity и receipt.
- Корреляция. Общий trigger должен повышать marginal charge до большинства commit, а не после burst.
- Согласованность. Distributed ledger, допускающий double spend, остаётся telemetry, а не hard control.
- Liveness. Злоумышленник может занять reservations и остановить полезный workflow.
Какие действия считать необратимыми
Необратимость не равна размеру API-вызова. Маленькое письмо клиенту уже нельзя «развидеть», а большое удаление из тестовой базы может быть полностью восстановимо из проверенного backup.
| Класс | Пример | Возможная единица бюджета | Базовый режим |
|---|---|---|---|
| финансовый | платёж, заказ, скидка | residual money exposure | hard reserve до commit |
| data loss | удаление, перезапись | записи / восстановимое окно | backup proof + reserve |
| disclosure | письмо, публикация, файл | класс данных × получатели | vector budget и approval |
| availability | deploy, restart | error budget / service minutes | change window + rollback |
| authority | пользователь, новая роль | privilege scope × duration | owner-only или two-person rule |
Деньги, приватность, доступность и репутация плохо сводятся к одному числу. Для смешанного процесса безопаснее вести vector budget с отдельными красными линиями, чем складывать рубли, записи и минуты простоя в псевдоточную сумму.
Метод ЛИМИТ для пилота
Предлагаем метод ЛИМИТ. Это редакционный синтез свежей работы, NIST identity/authorization guidance и практики production-controls; он не является стандартом этих организаций.
| Шаг | Что сделать | Условие перехода |
|---|---|---|
| Л — Лимит и владелец | определить principal, окно, запреты и authority для exception | есть письменная risk tolerance |
| И — Инвентаризация effects | перечислить tools, endpoints, side effects, compensation и receipts | каждый effect имеет тип и owner |
| М — Мера остаточного ущерба | оценить loss после recovery; для несводимых рисков завести vector | charge строится из evidence |
| И — Имитация burst и обходов | проиграть shared trigger, fragmentation, stale price, hoarding и double spend | shadow-ledger ловит overdraw |
| Т — Точка commit | поставить reserve/confirm/cancel ниже модели | deny происходит до effect |
Л — Лимит и владелец
Начните с одного процесса и одного окна: дневная закупочная экспозиция, часовой change budget или партия клиентских рассылок. Действия, которые не покупаются бюджетом — доступ к секретам, санкция человеку, привилегированная роль — могут оставаться owner-only.
И — Инвентаризация effects
Составьте реестр не названий tools, а их результатов: «создан заказ», «отправлено письмо», «изменена роль», «развёрнут commit», «удалена запись». Для каждого результата задайте компенсацию, срок отзыва, settlement receipt и владельца классификации.
М — Мера остаточного ущерба
Измерьте не face value, а то, что остаётся после проверенного recovery. Если historical evidence нет, используйте консервативный верхний класс и помечайте confidence. Человек утверждает модель charge и частоту recalibration; агент не меняет собственную цену.
И — Имитация burst и обходов
Сначала включите shadow mode: процесс исполняется, а ledger записывает, что он бы зарезервировал или запретил. Затем подайте одинаковый сигнал нескольким агентам, раздробите один effect, задержите detector, потеряйте confirm, повторите idempotency key и займите бюджет неиспользуемыми reservations.
Т — Точка commit
Enforcement размещают между планом и внешней системой. Reserve атомарно занимает agent/workflow/tenant budgets, confirm опирается на receipt, cancel требует доказанной отмены, а exception имеет отдельный лимит, владельца, причину и expiry. Изменение модели, tool schema, recovery path или risk window требует нового shadow-прогона.
Какие метрики фиксировать
| Метрика | Как считать | Что показывает |
|---|---|---|
| silent overdraw rate | окна, где unapproved loss > tolerance / все окна | выполняется ли главная граница |
| budget utilization | reserved + committed / budget | запас перед commit |
| false denial rate | безопасные effects, ошибочно отклонённые / безопасные effects | цена консервативности |
| calm / burst throughput | исполненные предложения по типу окна | где теряется liveness |
| charge calibration error | declared charge против realised residual loss | качество pricing |
| reservation leakage | просроченные reservations / все reservations | риск denial-of-service |
| exception exposure | отдельно одобренный residual risk за окно | не маскирует ли override превышение |
| receipt coverage | committed effects с receipt / все committed | можно ли проверить result и refund |
Порог задают до enforcement. Нельзя выбирать удобный budget после просмотра burst: так risk tolerance превращается в подгонку под желаемый throughput.
Как встроить контроль в процесс
- Оставьте существующие permissions. Budget не легализует действие, запрещённое IAM, policy или законом.
- Нормализуйте effects. Разные агенты и tools сводятся к общему typed event до commit.
- Разделите hard и advisory ledgers. Hard требует strong consistency; advisory остаётся мониторингом.
- Введите hierarchy. Agent, workflow и tenant одновременно платят за один effect.
- Защитите lifecycle. Reserve, confirm, cancel и expiry должны быть idempotent и переживать crash recovery.
- Ограничьте исключения. Human override имеет rate, capacity, reason code и audit trail.
- Проведите staged enforcement. Telemetry → warnings → deny для одного измеренного класса.
Microsoft Learn рекомендует лимиты шагов, итераций, бюджета и стоимости, allowlists tools и ясную ответственность за автономные действия. Модель зрелости Microsoft отделяет центральные стандарты от делегированных approvals и предупреждает о controls, существующих только как рекомендации. Это guidance поставщика, а не доказательство эффективности конкретного ledger.
Ограничения доказательств
The Irreversibility Budget — arXiv v1 и controlled simulation, а не production deployment. Charges в основном эксперименте сконструированы, а не выучены из компаний; это делает safety estimate оптимистичным. Refunds не реализованы полностью, поэтому liveness cost, наоборот, может быть пессимистичным.
Microbenchmark измеряет только in-memory reserve-confirm на одном host: медиана 2,6 μs, 240 bytes на live reservation и несколько сотен тысяч cycles/s при 32 threads. Это не latency долговечного распределённого authority с replication, log writes, partitions и crash recovery.
Трассы τ-bench и AgentDojo показывают коррелированность effects в benchmark-среде, а не частоту ущерба в российских компаниях. Работа не доказывает, что VaR — правильная мера, risk pricing решён или один scalar подходит для денег, данных, availability и права.
NIST-материал остаётся concept paper, а Microsoft и Google описывают guidance и продукты. Не наблюдались независимые production-данные по снижению инцидентов, стоимости внедрения, экономии, latency полного контура или ROI. Search volume, difficulty, rankings, traffic, CTR, backlinks и AI citations страницы остаются Unknown.
Частые вопросы
Что такое бюджет риска ИИ-агентов?
Это общий лимит остаточного ущерба, который runtime резервирует до внешних действий нескольких агентов за одно окно. Следующий commit отклоняется, если reserved и committed exposure превысят лимит владельца, workflow или tenant.
Чем он отличается от прав доступа?
Права определяют, разрешён ли тип действия конкретной identity. Бюджет дополнительно учитывает сумму уже разрешённых действий и может остановить очередное действие, не отзывая само право.
Можно ли просто поставить лимит на число вызовов?
Нет для неоднородных effects. Один вызов может отправить письмо, создать крупный заказ или удалить временный файл. Call count также обходится дроблением и не учитывает компенсацию.
Зачем нужен reserve до commit?
После commit письмо уже прочитано, деньги переведены или данные раскрыты. Реактивный breaker видит ущерб слишком поздно; reserve проверяет общий остаток до выхода эффекта наружу.
Всегда ли риск нужно переводить в деньги?
Нет. Для privacy, availability, authority и репутации полезнее отдельные компоненты vector budget с собственными красными линиями.
С чего начать внедрение?
С одного процесса и shadow-ledger: зафиксировать владельца, окно, типы effects, recovery evidence, conservative charges и пороги, не блокируя production на первом прогоне.
Как AIrassvet помогает собрать контур контроля
AIrassvet может помочь перевести риск автономных действий в проверяемый процесс:
- провести аудит одного процесса, baseline, внешних effects и существующих approvals;
- описать agent/workflow/tenant identities, tool boundaries и журналирование;
- собрать MVP shadow-ledger с typed events, reservations, receipts и тестами burst-сценариев;
- интегрировать принятые controls, провести тестирование, запуск и обучение команды.
Первый безопасный шаг — выбрать один процесс, его текущий baseline, источники данных, ограничения и критерий приемки. Обсудить задачу.
Вывод
Флот ИИ-агентов может превысить общий риск, даже когда каждый вызов разрешён и укладывается в локальный лимит. Permission проверяет действие, а общий budget — накопленную экспозицию до следующего commit.
Практический порядок: лимит и владелец → инвентаризация effects → мера остаточного ущерба → имитация correlated burst и обходов → reserve/confirm/cancel в точке commit. До production enforcement нужен shadow-ledger и консервативная калибровка: неверный charge превращает строгий лимит либо в скрытый overdraw, либо в видимый отказ полезной работы.