AIRUS ToolOps — Agent Action Gateway

Как только агент получает право «нажимать кнопки» во внешних системах — вопрос уже не в модели, а в governance: какое действие, кто разрешил, что оно затронет и как откатить. AIRUS ToolOps — контроль-плейн между агентом и реальными действиями.

Что делает

Между «агент решил» и «действие выполнено» встаёт детерминированный слой политики. Каждый инструмент описан Tool Contract, каждый вызов проходит action policy и оставляет Tool Call Receipt:

Tool Registry

POST /v1/airus/tools/register → контракт инструмента: verbs (search/resolve/preview/execute/verify/recover), risk level, destructive, requires_approval, allowed_roles, data-classes, rollback.

Preview-before-execute

POST /v1/airus/tools/preview → governance-решение и blast radius без исполнения. Агент видит, что действие потребует одобрения, ещё до вызова.

Action Policy

POST /v1/airus/tools/execute → allow (исполнить) / needs_approval (в очередь) / block (запретить с причиной: роль, data-class, деструктивность, лимит действий/час).

Approval Gates + Receipt

Деструктивные действия ждут одобрения ИБ/админа (/calls/:id/approve). Каждый вызов — receipt: verb, решение, blast radius, latency, rollback. Metadata-only, без сырых параметров.

Как вызвать

# 1. Админ регистрирует инструмент (Tool Contract)
POST /v1/airus/tools/register        # JWT
{ "tool_key": "crm_deal_update", "name": "CRM: обновить сделку",
  "tool_type": "http_webhook", "provider": "bitrix24",
  "risk_level": "high", "verbs_supported": ["preview","execute","recover"],
  "destructive": true, "requires_approval": true, "rollback_supported": true,
  "endpoint_url": "https://hooks.client.ru/crm" }

# 2. Агент проверяет план перед действием (ничего не исполняется)
POST /v1/airus/tools/preview         # API-ключ агента
{ "tool_key": "crm_deal_update", "verb": "execute", "input": { "deal_id": 42 } }
# → { "governance_decision": "needs_approval", "blast_radius": "destructive_cross_system" }

# 3. Агент выполняет → уходит в approval-очередь
POST /v1/airus/tools/execute         # → approval_status: "pending"

# 4. ИБ одобряет → действие исполняется через адаптер, остаётся receipt
POST /v1/airus/tools/calls/{id}/approve
GET  /v1/airus/tools/calls/{id}/receipt

Честно про исполнение

v0 реально исполняет только два типа: http_webhook — подписанный HTTP-вызов эндпоинта клиента (с SSRF-guard: только публичный HTTPS), и simulated — детерминированный dry-run без внешнего эффекта.
Коннекторы Bitrix24 / amoCRM / 1С / GitHub / email / Drive и MCP-адаптер — roadmap. Они есть в Connector Registry со статусом roadmap и НЕ выдают себя за рабочие. Пока их вызов идёт как http_webhook на ваш backend.
Honest-differentiator — это детерминированный governance-слой (реестр, политика, preview, approval, receipt, blast radius, лимиты действий/час), а не «магия» над чужими API.
Sandbox-исполнение, автоматический rollback-движок и сканер tool-poisoning (prompt-injection в описаниях инструментов) — roadmap; recover требует явного одобрения и rollback_supported.
Списания за governance в v0 нет (cost_rub = 0); тарификация действий — позже.

Зарегистрировать инструмент ToolOps API Registry Reference