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

Tool Permission Models в 2026: какие права давать агенту на вызов инструментов

Tool permission models в 2026: allow-lists, approval scopes, sticky approvals, hosted MCP restrictions и почему `tool available` не равно `tool allowed`.

Tool permission model в 2026 нужен потому, что "агент видит инструмент" ещё не означает "агенту можно этим инструментом пользоваться". Для production-систем вопрос уже не в том, как подключить больше tools, а в том, какой объём полномочий давать агенту в конкретном run, tenant, route и risk bucket.

Именно здесь начинается реальный control plane вокруг agents: какие tools доступны, какие требуют approval, какие запрещены всегда, какие разрешены только в read-only режиме, а какие можно использовать только после sticky human decision.

Permission model для tools похож на права в корпоративной системе. То, что сотрудник знает о существовании кнопки, не означает, что он может нажать её без ограничений. Для агента логика та же.
Самый опасный anti-pattern - давать агенту весь набор доступных tools по умолчанию и надеяться, что prompt сам ограничит поведение. Без permission model tool layer быстро становится вашей самой широкой и дорогой поверхностью риска.

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

Хороший tool permission model в 2026 обычно задаёт:

  1. Какие tools вообще видны агенту
  2. Какие из них read-only
  3. Какие требуют per-call approval
  4. Где допустим sticky approval
  5. Какие tools запрещены для конкретного route/tenant

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

  • tool availability и tool permission должны быть разными слоями;
  • high-risk tools по умолчанию deny;
  • scoped approvals лучше глобальных allow all;
  • hosted MCP tools и local function tools могут требовать разных правил.
Без техники
Агент видит search, CRM update, payment action, file delete и publish. Ограничения описаны только словами в system prompt.
С техникой
Инструменты разбиты на read-only, guarded и blocked. Routing и tenant policy решают, какие tools видимы, какие требуют approval, а какие недоступны вообще.
ПромптPermission intuition
Чем отличается `tool is available` от `tool is allowed`?
Ответ модели

Available означает, что tool вообще существует в системе. Allowed означает, что текущему агенту и текущему run-у реально разрешено его вызывать при данных условиях.

1. Доступность инструмента и право на вызов - не одно и то же

Полезно развести два уровня:

  • catalog layer: какие инструменты вообще зарегистрированы;
  • permission layer: какие из них доступны именно сейчас.

Именно второй слой должен учитывать:

  • tenant;
  • environment;
  • route;
  • current workflow step;
  • user role;
  • risk bucket.

Без этого агент живёт в мире, где любая capability потенциально доступна всегда.

2. Полезная базовая классификация tools

Read-only tools

  • search;
  • lookup;
  • list;
  • retrieve;
  • inspect.

Draft / propose tools

  • draft email;
  • prepare update;
  • generate patch preview;
  • build query preview.

Commit tools

  • send;
  • update;
  • delete;
  • execute payment;
  • publish;
  • push / deploy.

Эта классификация помогает:

  • строить approvals;
  • задавать sticky decisions;
  • отделять low-risk autonomy от high-risk commits.
Если tool меняет внешний мир, считайте его commit-tool, даже если с точки зрения интерфейса он выглядит безобидно. Именно side effect, а не marketing name, задаёт permission class.

3. Approval scopes лучше глобальных разрешений

У approval обычно есть scope:

  • только этот вызов;
  • этот tool для текущего run;
  • этот tool для текущего tenant/session;
  • deny for the rest of run.

Важно быть очень осторожным с глобальными allow:

  • они удобны оператору;
  • но могут silently расширять power агента дальше, чем планировалось.

Sticky approval оправдан скорее для bounded, low-risk или repeated benign tools, чем для dangerous commits.

4. Route- и tenant-aware restrictions обязательны

Один и тот же агентный стек может обслуживать разные сценарии:

  • internal support;
  • external customer-facing assistant;
  • enterprise admin workflow;
  • sandbox demo.

У них не должны быть одинаковые tool permissions.

То же касается tenant isolation:

  • один клиент разрешает external search;
  • другой запрещает;
  • один разрешает CRM write;
  • другой только draft mode.

Permission model обязан уметь выражать эти различия.

5. Hosted tools, MCP и local functions требуют разных правил

В 2026 tool ecosystem неоднороден:

  • local function tools;
  • hosted MCP tools;
  • remote MCP servers;
  • browser/computer-use executors.

У них разный blast radius и разные approval surfaces. Например, hosted MCP restrictions часто полезно задавать через allowed tools configuration, а local functions удобнее заворачивать в per-call approval logic.

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

All-tools-to-all-agents

Каждый агент видит весь каталог.

Prompt-only permissions

Ограничения описаны в инструкциях, но не enforced кодом.

No route scoping

Cheap lane получает те же инструменты, что и high-risk agent.

Over-broad sticky approvals

Один approve внезапно открывает длинный ряд будущих вызовов.

No deny-by-default for dangerous tools

Commit tools доступны до тех пор, пока кто-то не вспомнит их закрыть.

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

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

  • denied tool-call rate;
  • approval-required rate by tool class;
  • sticky-approval usage;
  • blocked dangerous-call attempts;
  • tool exposure by route/tenant;
  • permission mismatch incidents.

Если команда не видит, какие tools реально exposed агентам, permission model обычно существует только на словах.

Плюсы

  • Permission model делает tool layer управляемым и route-aware
  • Разделение read/propose/commit упрощает approvals и risk control
  • Scoped permissions лучше соответствуют tenant and workflow boundaries
  • Dangerous tools можно держать deny-by-default

Минусы

  • Появляется больше policy logic и operational complexity
  • Слишком грубые rules могут мешать automation coverage
  • Sticky approvals требуют особенно аккуратного scope
  • Без observability легко потерять понимание реального tool exposure

Пример tool permission policy

tool_permissions:
  default: deny
  allow:
    - search_kb
    - lookup_order
  require_approval:
    - issue_refund
    - send_external_email
  blocked:
    - delete_customer
    - git_push

Пример scoped decision

def can_use_tool(route, tenant, tool_name):
    if tool_name in {"delete_customer", "git_push"}:
        return "deny"
    if route == "support_low_risk" and tool_name == "issue_refund":
        return "approval_required"
    if tenant == "sandbox-demo" and tool_name == "send_external_email":
        return "deny"
    return "allow"

Практический совет: permission model стоит проверять до того, как tool вообще попадёт в reasoning loop. Чем позже система говорит "это нельзя", тем больше агент уже успевает построить план вокруг запрещённого действия.

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

1. Что означает разница между `tool available` и `tool allowed`?

2. Почему dangerous tools лучше держать deny-by-default?

3. Какой anti-pattern особенно вреден?

Источники

  1. OpenAI API Docs — Using tools
  2. OpenAI Agents SDK - Human in the loop
  3. OpenAI Agents SDK - MCP
  4. Anthropic Docs - Tool use
  5. OWASP Top 10 for LLM Applications
Предыдущая
Tool Output Provenance в 2026: как не потерять происхождение данных, когда агент опирается на tool result
Следующая
Tool Permission Reviews в 2026: как регулярно пересматривать, что агентам вообще разрешено