AI-порталAI-портал

Agent Capability Scoping в 2026: как ограничивать, что агенту вообще разрешено уметь

Agent capability scoping в 2026: как задавать agent surface area по ролям, инструментам и risk tier, чтобы агент не был слишком универсальным и слишком опасным.

Agent capability scoping в 2026 нужен потому, что самый удобный агент на демо почти всегда слишком широкий для production. Ему дали браузер, CRM, почту, поиск, file system и право решать "по ситуации". Пока кейсы простые, это выглядит мощно. Как только приходят edge cases, incident-ы и реальные клиенты, выясняется, что агент знает и может слишком много. Ошибка уже не локальная, а размазанная по большому surface area.

Capability scoping — это правило, какие действия, инструменты и типы решений доступны конкретному агенту. Хороший агент должен быть не максимально универсальным, а достаточно узким для своей роли.
Самый вредный anti-pattern - собирать одного "умного универсального агента" и надеяться, что system prompt сам удержит его в рамках. В production границы лучше задавать архитектурно, а не только текстом в промпте.

Короткая версия

Хороший capability scope в 2026 обычно определяет:

  1. Какие задачи агент решает
  2. Какие tools ему доступны
  3. Какие actions он не может коммитить сам
  4. Когда нужен handoff или review
  5. Какой risk tier у маршрута

Что особенно важно

  • scope должен быть role-based, а не "всё для всех";
  • tool availability и action authority — это разные вещи;
  • лучше несколько узких агентов, чем один слишком широкий;
  • capability scope должен проверяться не только в prompt, но и в orchestration layer.
Без техники
Один агент умеет искать, редактировать CRM, отправлять письма и запускать browser actions, потому что так удобнее.
С техникой
Research agent только собирает evidence, action agent делает узкий набор коммитов, а risky paths требуют handoff или review.
ПромптCapability intuition
Почему широкий capability scope опаснее, чем кажется?
Ответ модели

Потому что одна ошибка или injection начинает влиять сразу на большее число tools и side effects. Чем шире scope, тем труднее предсказать и ограничить поведение агента.

1. Scope должен описывать не только tools, но и полномочия

Полезно разделять:

  • read capabilities;
  • draft capabilities;
  • execute capabilities;
  • approval-required capabilities;
  • forbidden capabilities.

Иначе наличие tool-а легко путают с правом реально применять его результат.

2. Narrow roles обычно безопаснее wide roles

Например:

  • one agent researches;
  • второй формирует draft;
  • третий делает ограниченный commit;
  • человек подтверждает high-risk action.

Такой split:

  • уменьшает blast radius;
  • упрощает evals;
  • упрощает incident analysis;
  • облегчает permission policy.
Если агенту нужны десять разных инструментов "на всякий случай", почти наверняка он спроектирован слишком широко.

3. Capability scope должен быть route-aware

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

  • customer tier;
  • environment;
  • action type;
  • confidence band;
  • degraded mode.

Иногда safe capability scope для sandbox route совсем не подходит production route.

4. Handoffs полезнее, чем скрытая универсальность

Вместо того чтобы расширять один агент до всех задач, часто лучше:

  • делать handoff на специализированного агента;
  • снижать scope базового агента;
  • вводить intermediate evidence step;
  • ставить review перед risky commit.

Это делает систему медленнее на диаграмме, но надёжнее в реальности.

5. Что особенно часто ломают команды

Universal agent by convenience

Одному агенту дают всё, потому что так проще интегрировать.

Tool access = authority

Если агент может вызвать tool, считается, что он может и действовать на его основе.

Scope defined only in prompt

Нет orchestration-level guardrails.

No environment split

Sandbox и production имеют одинаковую capability surface.

Scope drift

Список доступных actions растёт быстрее, чем обновляются evals и policy checks.

6. Какие метрики полезны

Минимальный capability-scope dashboard обычно включает:

  • tools per agent;
  • percent of routes requiring handoff;
  • risky actions per capability class;
  • incidents by over-broad scope;
  • permission denials by route;
  • scope drift over time.

Плюсы

  • Узкий capability scope уменьшает blast radius ошибок и injection
  • Специализированные агенты легче тестировать и объяснять
  • Route-aware authority делает production safer
  • Handoffs помогают строить более контролируемые agent systems

Минусы

  • Система становится более модульной и сложной в orchestration
  • Слишком узкий scope может создавать лишние handoff-ы
  • Нужно поддерживать permissions и evals по нескольким ролям
  • Scope drift нужно отдельно отслеживать

Пример capability policy

agents:
  research_agent:
    tools: [search, kb_lookup]
    may_execute: false
  action_agent:
    tools: [crm_update, draft_email]
    may_execute: [crm_update]
    requires_review_for: [external_send]

Простой scope check

def can_execute(agent, action, policy):
    allowed = policy["agents"][agent].get("may_execute", [])
    return action in allowed

Практический совет: самый безопасный capability scope - не тот, который красиво описан в system prompt, а тот, который агент физически не может обойти в orchestration layer.

Проверьте себя

1. Почему capability scope нельзя задавать только через prompt?

2. Что полезнее для production?

3. Какой anti-pattern особенно опасен?

Источники

  1. OpenAI Agents SDK - Tools
  2. OpenAI Agents SDK - Handoffs
  3. OpenAI API Docs - Evaluation best practices
  4. OWASP Top 10 for LLM Applications
Предыдущая
Agent Capability Recertification в 2026: как периодически пересматривать права агента, а не только выдавать их
Следующая
Agent Delegation Boundaries в 2026: что агент может делегировать, а что обязан довести сам