AIRUS Gateway
Войти

AIRUS AuthorizationOps

SSO подтвердил, что это сотрудник. IdentityOps подтвердил, что это его агент. Главный вопрос — какого действия над каким объектом агент имеет право прямо сейчас? AuthorizationOps ограничивает агента конкретной задачей, объектом, бюджетом и моментом времени — и перепроверяет разрешение до каждого реального действия. Один RBAC-чек в начале сессии не защищает всю цепочку user → agent → RAG → модель → MCP tool → CRM → финансовое действие.

Policy Decision Plane

RBAC + ReBAC + ABAC
Базовые роли + отношения (partner operator project) — authorize резолвит записанные relationships в trusted db-derived context.relations + атрибуты контекста(data_class, route_region, cost, risk). Один подход не закрывает всё.
Default deny + explicit-deny-wins
Нет разрешающей policy → deny. Явный deny побеждает allow. Конфликт policies разрешается формально, а не порядком выполнения кода.
Explainable Deny
Не {"error":"forbidden"}, а: determining policy, причина и безопасные альтернативы — какой route/модель использовать вместо запрещённого.
Task-scoped Agent Grants
Агент получает не все права пользователя, а envelope на задачу: allowed actions, конкретный объект, max cost, external writes, срок. Разрешить draft и разрешить send — не одно действие.
Порядок решения (fail-safe):
1. explicit deny (match) → DENY
2. deny (indeterminate) → fail-closed
3. require_approval → gate
4. allow_with_obligations → allow
5. allow → allow
6. нет policy → default deny

Approval, shadow mode и explainable deny

Approval Gates с diff
Для необратимых действий: карточка показывает что изменится (Deal Stage: Qualified → Proposal), стоимость, риск и срок — one-time / на задачу / запретить. Approval, который человек действительно читает.
Policy Shadow Mode
Новая policy оценивается на production-трафике, но не блокирует: «would deny 2,4%, 14 workflows, 3 клиента без RF-fallback» → сначала проверить, потом canary enforcement.
Authorization Receipt
Для любого действия восстанавливается principal, resource, policy, approval и determining reason — sha256-доказательство решения для CISO и compliance.
Decision: DENY
Principal:  ContractOps Agent 4.8
Action:     route.use_external      Resource: Contract #8821
Reason:     document classified CONFIDENTIAL
Policy:     DATA-RESIDENCY-017
Alternatives: rf/business-text · customer/local-legal

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

  • Движки детерминированы: PDP (default-deny + explicit-deny-wins + fail-safe), task envelope, approval gates, policy simulation/shadow, authorization receipt (sha256).
  • Правило зашито: tenant-решение ВЫЧИСЛЯЕТСЯ из ЗАПИСАННЫХ production-policies (не из тела запроса); shadow-policies не enforce; policy-запись — привилегированное действие (owner/admin/security).
  • Fail-safe: если deny-policy опирается на ОТСУТСТВУЮЩИЙ атрибут → indeterminate_deny (fail-closed) — обход deny опусканием поля невозможен.
  • Ключевой caveat: в v0 context (data_class/route_region/cost/risk) caller-asserted. Решение доверенно ровно настолько, насколько доверен context: enforced authorization требует, чтобы PEP инжектил trusted context (data-class из resource-системы, cost из metering, risk из fraud-control), а не принимал из запроса. PEP hot-path enforcement — roadmap.
  • Obligations advisory: mask_pii/rf_only_route возвращаются с enforced:false — PEP их пока не применяет (roadmap).
  • Roadmap: реальные OPA/OpenFGA/Cedar-интеграции, PEP в gateway/RAG/tools, continuous re-check внутри agent run, policy GitOps.
  • Поверх, не вместо: IdentityOps (principal + delegation), Fraud Control (risk как context), MarginOps (cost как context). Money: cost — атрибут context; LedgerService не трогается.
IdentityOpsTrust CenterAuthorizationOps API