Excessive agency и confused deputy

Агент, имеющий больше возможностей, чем требует его задача, — это уязвимость, ожидающая эксплуатации. Украдите его ключ, обманите инъекцией или скомпрометируйте одну зависимость — и всё, что может делать этот ключ, теперь в руках злоумышленника. Это проблема excessive agency, и она усугубляется тесно связанным паттерном, называемым confused deputy: агент не скомпрометирован напрямую, он убеждён использовать свои законные полномочия в интересах злоумышленника. Обе проблемы имеют одну первопричину: ключ, которым держит скомпрометированный агент, слишком мощный для выполняемой им задачи. Защита — минимальные полномочия — давать каждому агенту ровно те возможности, которые требует его задача, и не более.

​

1. Что делает агента избыточно мощным

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

• Неограниченные модели — агент может вызывать любую модель в рабочем пространстве, включая дорогие или высокомощные, которые ему никогда не нужны.
• Нет потолка расходов — бесконечный цикл, инициированная инъекция или биллинговая атака могут исчерпать баланс рабочего пространства до вашего замечания.
• Нет срока действия — ключ, выпущенный во время спринта, всё ещё валиден год спустя, долго после отставки агента, для которого он был создан.
• Нет IP-ограничения — учётные данные работают откуда угодно, поэтому утёкший ключ не имеет географического предела.
• Нет allow-листа инструментов — агент может вызывать любой инструмент, даже не связанный с его функцией.

Любого из этих аспектов по отдельности достаточно для расширения радиуса взрыва. В совокупности один скомпрометированный агент может делать всё, что может делать workspace admin — вызывать самую мощную модель, тратить весь баланс, достигать каждого инструмента.

​

2. Паттерн confused deputy

Confused deputy — специализация excessive agency. Агент не взломан; он убеждён. Payload prompt injection в извлечённой веб-странице, документе или результате инструмента говорит агенту совершить действие, которое он законно авторизован выполнять — перевести деньги, удалить запись, отправить сообщение — в интересах злоумышленника. Агент действует. Он был авторизован делать именно это. Проверка авторизации проходит. Ущерб нанесён. Защита требует двух вещей, работающих вместе:

1. Узкая область — агента нельзя обмануть на выполнение того, что его задача никогда не предполагала, потому что он вообще не авторизован это делать.
2. Подтверждение человека для необратимых действий — даже в рамках авторизованной области высокорисковый вызов требует подтверждения человека перед выполнением.

​

3. Эшелонированная защита: четыре слоя

OrcaRouter применяет минимальные полномочия на четырёх независимых средствах управления, компонующихся на одном API-ключе. Ни одно не требует изменений в коде агента.

​

Слой 1 — Ограниченный ключ (идентификация + жёсткие лимиты)

У каждого агента должен быть собственный API-ключ. Ключ несёт жёсткие лимиты, которые шлюз применяет независимо от того, что запрашивает агент: Эти лимиты применяются на уровне ключа — до любой политики, до любого вызова модели. Они — самая внешняя граница радиуса взрыва.

​

Слой 2 — Политика Firewall (allow-list инструментов)

Привяжите политику firewall к ключу через firewall_policy_id. Политика управляет каждым вызовом инструмента, инициируемым этим ключом:

• Пишите правила, которые разрешают имена инструментов, которые агент законно использует (глобы имён инструментов поддерживаются — например, db.query*).
• Устанавливайте default_verdict политики в deny, чтобы всё, что явно не перечислено, блокировалось.
• Добавляйте предикаты аргументов для ограничения даже разрешённых инструментов — например, разрешать db.query только когда аргумент database совпадает с конкретной схемой.

Ключ без привязки firewall откатывается к default-политике рабочего пространства. Для агентов с узкими потребностями инструментов явная привязка со строгой политикой всегда предпочтительнее зависимости от default’а рабочего пространства. См. Правила Firewall для полного языка сопоставления.

​

Слой 3 — Подтверждение человека для высокорисковых действий (pending_approval)

Для необратимых или высокоценных вызовов инструментов — диспетч платежа, удаление записи, отправка email — добавьте правило pending_approval. Поток:

1. Агент инициирует вызов инструмента. Firewall удерживает его и возвращает ответ «held», несущий id подтверждения. Вызов не достигает инструмента.
2. Проверяющий одобряет или отклоняет вне основного канала — из консоли (Developer+) или через HMAC-подписанный webhook вашей собственной системы подтверждений.
3. Ваш агент опрашивает id подтверждения. После одобрения он повторно отправляет оригинальный вызов с одноразовым заголовком X-OrcaRouter-Firewall-Approval. Шлюз пропускает его один раз.

Здесь confused deputy останавливается даже когда область валидна: человек подтверждает, что действие является намеренным, до его выполнения.

​

Слой 4 — Ограничение стоимости на прогон (cap_cost)

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

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

cap_cost работает на уровне прогона, а не пожизненном уровне ключа — поэтому он сбрасывается на каждый вызов агента, и один плохо ведущий себя прогон не может исчерпать потолок credit_limit_usd ключа.

​

4. Хорошо ограниченный ключ агента — пример

Агент, резюмирующий тикеты клиентов с использованием gpt-4o-mini и запрашивающий реплику только для чтения, должен выглядеть так:

• model_limits: ["openai/gpt-4o-mini"] — не может эскалировать до более мощной или дорогой модели.
• allow_ips: CIDR исходящего трафика пула воркеров — ключ инертен везде ещё.
• credit_limit_usd: недельный потолок, соответствующий ожидаемой стоимости задачи, с запасом — например, 5.00.
• expired_time: конец спринта или периода развёртывания — ключ самоистекает без ручной очистки.
• environment: "prod" — появляется в фильтрах логов и представлениях аномалий.
• guardrail_id: guardrail, ограниченный чувствительностью данных этого агента (маскирование PII, нет секретов в выводе).
• firewall_policy_id: политика, allow-list которой содержит только db.query* и ticket.read*, вердикт по умолчанию deny.

Когда этого агента обманывают эксфильтрировать данные через внедрённую инструкцию, радиус взрыва: одна модель, один диапазон IP, одно пространство имён инструментов, один потолок стоимости. Остальная часть рабочего пространства не затронута.

​

5. Требуемые роли

​

6. Связь с другими угрозами

Excessive agency является включателем почти каждой другой агентной угрозы:

• Опасные вызовы инструментов — ключ со строгим allow-листом инструментов не может быть вынужден вызывать инструмент, который не перечислен, даже при успехе инъекции.
• Prompt injection — ограничение области снижает ущерб от инъекции; шлюзы подтверждения блокируют необратимые действия, которые инъекция пытается запустить.
• Модель угроз — полная карта поверхности атаки, показывающая место excessive agency относительно других векторов.

Минимальные полномочия не предотвращают инъекцию. Они уменьшают то, чего может достичь инъекция. Минимальные полномочия — один узкий ключ на агента, строгий allow-list инструментов, лимит расходов и подтверждение человека для необратимых действий — является основной защитой от атак excessive agency LLM и паттерна confused deputy.