Пробел в управлении
Большая часть корпоративного управления агентами сегодня — это observability с приклеенным словарём соответствия требованиям. Дашборд фиксирует, что агент прочитал запись клиента, которую читать не должен был, дважды вызвал платёжный эндпоинт или передал контекстное окно с учётными данными сторонней модели. Запись точна. И она же — слишком поздняя.
Режим отказа здесь структурный, а не вопрос покрытия. Конвейер логирования находится ниже по потоку от решения, которое он описывает. К моменту, когда событие доходит до хранилища, вызов инструмента уже вернулся, побочный эффект уже наступил, а запуск уже пошёл дальше. Дашборд, фиксирующий нарушение, уже проиграл спор запуску.
Для агентов это важнее, чем для обычных сервисов, потому что единица поведения — не запрос, а траектория. Один запуск может породить десятки вызовов инструментов, каждый из которых зависит от предыдущего, через несколько провайдеров и учётных данных. Постфактумный разбор траектории может объяснить, что произошло. Он не может предотвратить четвёртый вызов, когда третий уже успешен. Управление, которое только описывает, — не управление; это дневник.
Как выглядит точка принуждения
Точка принуждения — это синхронное перехватывание, где решение политики может заблокировать или изменить действие до того, как оно вступит в силу. Для runtime-сред агентов три шва несут большую часть риска.
Вызов инструмента. Каждый вызов от модели к инструменту — вызов функции, MCP-инструмент, HTTP-запрос, команда оболочки — проходит через решение до отправки. Решение получает идентичность инструмента, полезную нагрузку аргументов, вызывающий запуск и шаг, а также накопленную сводку траектории. Оно возвращает allow, deny или перезапись: суженные аргументы, подставленный вариант только для чтения, внедрённый шаг подтверждения.
Исходящие данные. Каждая полезная нагрузка, покидающая границу доверия — к провайдеру модели, стороннему API, вебхуку — проверяется на метки классификации и шаблоны секретов до передачи. Именно здесь ловится утечка контекстного окна, а не при постфактумном сканировании промптов.
Выдача учётных данных. Каждый короткоживущий токен, ключ или сессионные учётные данные выпускаются через брокер, который применяет политику в момент выдачи. Область действия привязана к конкретному вызову, а не к запуску. Учётные данные, которые никогда не были выданы, невозможно использовать во вред, и этот шов — самое дешёвое место для принудительного применения наименьших привилегий, потому что радиус поражения — один токен.
Каждому шву нужны три свойства, которые легко сформулировать и трудно построить.
Во-первых, ограниченный бюджет задержки. Синхронное решение находится на критическом пути каждого вызова инструмента, поэтому у сервиса политик есть потолок задержки, выраженный в процентиле, а не в среднем. Если бюджет превышен, вызывающей стороне нужно определённое поведение, а не открытый сокет.
Во-вторых, путь default-deny, когда сервис политик недоступен. Честный компромисс: default-deny сломает production-запуски во время сбоя сервиса политик. Default-allow не сломает — и так же молча отключит управление именно в тот момент, когда оно нужнее всего. Защитимая позиция — default-deny для швов с высокими последствиями (выдача учётных данных, исходящий трафик к внешним эндпоинтам) и кэшированный, версионированный набор решений для чтений с меньшими последствиями, причём устаревание кэша ограничено и отражено в записи аудита.
В-третьих, детерминизм. При одной и той же версии политики и одном и том же запросе решение должно быть идентичным. Никаких правил, зависящих от настенных часов, никакой случайной выборки, никакого изменяемого глобального состояния в оценщике. Детерминизм — это то, что делает воспроизведение в аудите осмысленным; без него записанное решение — анекдот, а не доказательство.
Конкретный механизм, удовлетворяющий всем трём требованиям, — это контракт решения с явным контекстом оценки:
{
"request_id": "run-8f2c/step-14",
"policy_version": "2025-03-11.4",
"seam": "tool_invocation",
"subject": {"agent": "reconciliation-v3", "run": "run-8f2c"},
"action": {"tool": "payments.transfer", "args_hash": "sha256:9c1e..."},
"context": {"data_classes": ["pii"], "egress_target": "internal"},
"decision": "rewrite",
"rewrite": {"tool": "payments.transfer_preview"},
"latency_ms": 7,
"cache": "fresh"
}
Оценщик потребляет эту запись, выдаёт решение, и runtime сохраняет и то, и другое. args_hash избавляет запись аудита от сырых полезных нагрузок, оставаясь воспроизводимым по сохранённому набору аргументов. Поле policy_version — несущее.
Версионирование политик как операционное требование
Политики меняются; запуски — нет. Запуск, начавшийся под версией политики A и всё ещё выполняющийся, когда выходит версия B, должен управляться A, иначе запись аудита становится бессвязной. Правило просто сформулировать: записывайте версию политики, оценённую при каждом решении, и фиксируйте версию на всё время жизни запуска, если только не запущена явная переоценка.
Фиксация необходима, но недостаточна. Также должно быть безопасно менять политику, не ломая production. Механизм — теневая оценка. Версия-кандидат разворачивается рядом с активной. Каждый запрос на решение оценивается обеими. Решение активной версии применяется; решение кандидата записывается и сравнивается. Операторы получают diff вызовов, которые были бы заблокироск.
Теневая оценка — это место, где живёт большая часть операционных затрат. Она удваивает нагрузку оценки, требует тех же гарантий детерминизма от кандидата и нуждается в отчёте сравнения, который отличает значимое расхождение от шума. Выигрыш в том, что развёртывание политик перестаёт быть событием управления изменениями и становится рутиной.
Альтернатива — отправка изменений политики напрямую в принудительный путь — даёт предсказуемый результат. Правило с уровнем ложных срабатываний, который операторы не могут терпеть, отключается в течение нескольких дней, и точка принуждения становится декоративной.
Измерение того, работает ли это
Точки принуждения порождают небольшой, полезный набор метрик. Важны не проценты покрытия.
Отслеживайте соотношения заблокированных к разрешённым по каждому инструменту и шву. Инструмент с частотой блокировок около нуля либо действительно безопасен, либо управляется правилом, которое никогда не срабатывает; одно соотношение не скажет, что именно, но скажет, куда смотреть. Инструмент, у которого частота блокировок подскакивает после изменения политики, — кандидат на теневой разбор.
Отслеживайте частоту ложных срабатываний, которая заставляет операторов отключать контроли. Это метрика, определяющая, выживет ли управление при контакте с production. Контроль, который отключили, — не контроль. Измерение должно включать время до отключения: как долго шумное правило живёт, прежде чем кто-то обойдёт его. Короткое время до отключения — сигнал, что политика была написана без видимости реального трафика, и исправление здесь — теневая оценка, а не увещевания.
Отслеживайте задержку решений на швах, на том процентиле, который назван в бюджете задержки. Сервис политик, который укладывается в бюджет в среднем и не укладывается в пик, — это сервис политик, который будут обходить в пик.
Наконец, отслеживайте точность воспроизведения: долю записанных решений, которые воспроизводятся идентично при переоценке против сохранённой версии политики и запроса. Это операционная проверка детерминизма. Система управления, которая не может воспроизвести собственные решения, описывает поведение, а не ограничивает его — с чего и началось это эссе.
Слой, который имеет значение
Полезный слой управления мал, синхронен и скучен. Он сидит на трёх швах, принимает детерминированные решения в рамках бюджета задержки, отказывает закрыто там, где последствия высоки, версионирует свои политики и измеряет, оставляют ли операторы его включённым. Политические документы и дашборды — нижележащие артефакты этого слоя, а не его замена.
Сначала стройте точки принуждения. Аудиторский след напишется сам.