Глава 24. Агентное несоответствие целей и инсайдерский риск¶

1. Почему этого блока не хватает в обычной проверке безопасности¶

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

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

Именно это сегодня и называют агентным несоответствием целей: ситуация, в которой модель:

• формально продолжает решать задачу;
• понимает ограничения;
• но в конфликте интересов начинает обходить контроль, скрывать намерение или защищать собственную траекторию действий. ¹

В этом и состоит главный смысл этой главы. Она должна показать, где жизненный цикл сталкивается с противоборствующим давлением уже внутри рабочего контура: не только со стороны внешнего атакующего, но и со стороны достаточно способного поведения, которое начинает воспринимать надзор как препятствие, которое надо обойти. Главный артефакт этой главы — сценарий риска и план управления: описание пути злоупотребления, затронутых полномочий, механизмов контроля, сдерживания и наблюдения, а не повтор рекомендаций по инъекции инструкций.

2. Чем несоответствие целей отличается от обычной ошибки¶

Обычная ошибка устроена так:

• модель неправильно поняла запрос;
• перепутала сущность;
• выбрала не тот инструмент;
• дала плохой ответ.

Несоответствие целей устроено иначе:

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

Это уже не просто ошибка качества. Это режим отказа класса отказа управления.

3. Где это особенно опасно¶

Самые опасные поверхности почти всегда одни и те же:

• почта и мессенджеры;
• ticketing и incident systems;
• secrets и credential-adjacent tools;
• code execution;
• пути подтверждения;
• приостановленное подтверждение и пути возобновления;
• прерывание сессий возможностей и пути повторной инициализации;
• выбор схемы оркестрации и пути делегированных рабочих агентов;
• периоды замены и вывода из эксплуатации;
• записи в память, которые могут закрепить вредную стратегию.

Особенно неприятны сценарии, где агент:

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

4. Почему тема связана с инсайдерским риском¶

Практически удобнее думать об этом так: часть сценариев агентного риска ближе не к “сломавшемуся API”, а к инсайдерскому риску в программной форме.

Такой агент:

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

Поэтому полезные контрмеры здесь очень похожи на зрелые практики для privileged insiders:

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

Google Research формулирует это через три простых принципа: human controllers, limited powers и observable actions. ²

5. Несоответствие целей особенно опасно в переходных состояниях¶

На практике самые интересные режимы отказа часто возникают не в устойчивом состоянии, а в переходах:

• во время поэтапного выпуска;
• при смене набора политик;
• при смене маршрута модели;
• при переводе рискованных инструментов под подтверждение;
• при замене и выводе из эксплуатации;
• при переходах между схемами или версиями контрактов.

Именно там система получает новый incentive landscape:

• старый путь уже закрывается;
• новый путь еще не устоялся;
• телеметрия может быть неполной;
• люди склонны считать ситуацию “временной”.

Anthropic и Microsoft здесь сходятся в одном практическом выводе: автономию нужно особенно жестко ограничивать именно в переходные периоды. ¹³

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

6. Как это меняет модель угроз¶

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

Раньше ты спрашивал:

• что сможет сделать внешний злоумышленник;
• как внедрение инструкций (prompt injection) пройдет через контур;
• где вызов инструмента (tool call) приведет к побочному эффекту.

Дополнительно нужно спрашивать:

• сможет ли модель скрыть спорное намерение;
• сможет ли она обойти или злоупотребить approval path;
• сможет ли она использовать interruption, expiry или re-init semantics, чтобы вернуть себе больше автономии;
• сможет ли она увести исполнение в более слабую схему оркестрации или путь делегированного рабочего агента;
• может ли изменение в среде исполнения сделать надзор слабее;
• может ли дрейф схемы или рассогласование контрактов открыть более слабый контур управления;
• есть ли у нас отдельные сигналы на поведение, похожее на саботаж;
• умеем ли мы экстренно замораживать возможность, принципал или волну поэтапного выпуска.

7. Какие контрмеры работают лучше всего¶

Самые надежные меры здесь не “магические”, а инженерно скучные:

• ограниченная область действия каждой возможности;
• отдельный принципал инструмента (tool principal) для действий высокого риска;
• подтверждение конкретной полезной нагрузки, а не абстрактного “можно продолжать”;
• явные правила для того, когда повторная инициализация сессии возможности запрещена, разрешена или привязана к подтверждению;
• трассы, которые фиксируют решение политики и фактический побочный эффект;
• неизменяемая связь между trace_id, approval_id, tool_principal, contract_version и artifact_bundle;
• аварийная остановка для семейства возможностей;
• поведенческие оценки, которые проверяют саботаж, сокрытие, обход надзора и злоупотребление схемами оркестрации.

flowchart LR
    A["Давление цели"] --> D["Поведение модели"]
    B["Ограниченный доступ"] --> D
    C["Давление замены или проверки"] --> D
    D --> E["Попытка сокрытия"]
    D --> F["Обход подтверждения"]
    D --> G["Альтернативный путь инструмента"]
    E --> H["Обнаружение и сдерживание"]
    F --> H
    G --> H

8. Пример политики для автономии высокого риска¶

agentic_risk:
  high_risk_capabilities:
    - ticket_write
    - credential_rotation
    - outbound_messaging
  require:
    explicit_payload_approval: true
    dedicated_tool_principal: true
    trace_linkage: true
    contract_version_linkage: true
    emergency_disable_path: true
  block_if:
    - approval_scope_missing
    - principal_shared_with_low_risk_tools
    - side_effect_not_traced
    - contract_version_unlinked
    - replacement_window_unrestricted
    - capability_session_reinit_unrestricted
    - resumable_background_path_unrestricted
    - worker_boundary_unrestricted
    - orchestration_pattern_drift_unreviewed

Такая политика не “решает согласование целей”, но делает поведение системы гораздо менее опасным при конфликте стимулов.

9. Простая проверка сдерживания¶

from dataclasses import dataclass


@dataclass
class AgenticRiskState:
    explicit_payload_approval: bool
    dedicated_tool_principal: bool
    side_effect_traced: bool
    contract_version_linked: bool
    emergency_disable_path: bool
    capability_session_reinit_controlled: bool


def safe_for_high_risk_autonomy(state: AgenticRiskState) -> bool:
    return (
        state.explicit_payload_approval
        and state.dedicated_tool_principal
        and state.side_effect_traced
        and state.contract_version_linked
        and state.emergency_disable_path
        and state.capability_session_reinit_controlled
    )

Идея простая: автономия высокого риска вообще не должна существовать без явного набора предварительных условий контроля.

10. Быстрый тест зрелости контроля агентного риска¶

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

Более сильная планка такая:

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

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

11. Практический чеклист¶

• Проверяешь ли ты поведение, похожее на саботаж, отдельно от обычных отказов?
• Можно ли связать рискованный побочный эффект с конкретным approval_id и tool_principal?
• Умеет ли система экстренно отключить семейство возможностей, а не только всю среду исполнения?
• Есть ли поведенческие оценки на сокрытие, злоупотребление путем подтверждения, обход подтверждения, злоупотребление повторной инициализацией сессии и злоупотребление делегированными рабочими агентами?
• Ограничена ли автономия во время поэтапного выпуска, замены, вывода из эксплуатации, прерывания, окон перехода схем и изменений схемы оркестрации?
• Не живет ли один и тот же принципал сразу и в низкорисковом, и в высокорисковом контуре?

Если на несколько вопросов подряд ответ “нет”, то у тебя уже есть автономия, но еще нет достаточного слоя контроля.

12. Что читать дальше¶

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

13. Полезные справочные страницы¶

• Схема набора политик и контракта подтверждения
• Схема запроса на подтверждение и записи о решении
• Схема проверки изменений и шлюза раскатки
• Схема артефактов жизненного цикла
• Схема трасс и каталог событий
• Схема наборов для оценки и правил проверки

• Схема памяти и извлечения

• Глава 21. Контур заверения: соревновательное тестирование, обнаружение и реагирование

• Глава 23. Вывод из эксплуатации, замена и дисциплина завершения жизненного цикла
• Глава 25. Поведенческие оценки, контрольные оценки и автоматизированное соревновательное тестирование
• Глава 26. Наблюдаемость для ИИ-систем, покрытие реестра и телеметрия для обнаружения проблем