RBAC для AI-агентів: контроль доступу за ролями без зайвих прав

Ідея за 30 секунд

RBAC (Role-Based Access Control) для AI-агента визначає, хто і які дії може виконати через tools у runtime.

Коли це потрібно: коли агент працює з різними ролями, різними тенантами або має доступ до write-дій у реальних системах.

Проблема

Без RBAC агент часто запускається з "широким" доступом: одна роль, багато інструментів, мінімум меж. У demo це виглядає зручно. У production це швидко стає джерелом інцидентів.

Одна помилка в плані агента може запустити зайву дію: не той tool, не той tenant, не той рівень доступу. Після цього складно відповісти навіть на базове питання: хто саме отримав доступ і чому. Щоб така помилка не перетворювалась на інцидент, перевірка доступу має жити не в prompt, а в policy layer перед кожним tool call.

Аналогія: це як універсальний пропуск у бізнес-центрі. Поки все спокійно, різниці не видно. У момент збою такий пропуск відкриває занадто багато дверей.

Рішення

Рішення — винести контроль доступу в policy layer у runtime. Кожен tool call перевіряється за user context (role, permissions і tenant scope) перед виконанням. Почни з базового правила: default deny і явні дозволи лише для потрібних ролей.

RBAC ≠ просто allowlist

Allowlist визначає, які tools існують у системі.
RBAC визначає, хто і коли може їх викликати.

Одне без іншого не працює:

• без RBAC доступи між ролями розмиваються
• без allowlist набір інструментів неконтрольовано росте

Приклад:

• allowlist: tool refund.create існує і доступний у системі
• RBAC: тільки роль billing_manager може викликати refund.create у своєму tenant

Рівні контролю доступу (RBAC layers)

Ці перевірки працюють разом на кожному кроці агента.

Як це виглядає в архітектурі

Policy layer (tool gateway) стоїть між runtime і tools та перевіряє кожен виклик. Кожне рішення (allow, deny, approval_required) фіксується в audit log.

Flow: від запиту до рішення

Кожен tool call проходить через цей flow перед виконанням: runtime не виконує дії напряму, а передає рішення policy layer.

Коротко по флоу:

• Runtime формує tool request
• RBAC policy layer перевіряє роль і tenant scope
• allow -> виконується tool call
• deny -> stop reason + запис в audit log
• approval_required -> stop reason + запис в audit log

Policy decisions

Кожен tool call закінчується одним із рішень:

• allow — дія виконується
• deny — дія заборонена
• approval_required — потрібне підтвердження

Це централізована точка, через яку проходять усі рішення перед виконанням дії. Ці рішення використовуються як stop reasons і логуються в audit log.

Приклад

Агент підтримки (role = support_agent) отримав запит на повернення коштів. Tool refund.create дозволений тільки ролі billing_manager у власному tenant.

Результат:

• support_agent -> refund.create -> deny("permission_denied")
• role mismatch або tenant scope mismatch -> deny("permission_denied")
• подія записана в audit log з причиною відмови

RBAC зупиняє помилку на рівні виконання через перевірку доступу перед кожною дією.

У коді це виглядає так

decision = rbac.check(user_context, tool, tenant_id, args)
if not decision.allowed:
    audit.log(user_context, tool, tenant_id, decision.outcome, reason=decision.reason)
    return deny(decision.reason)

if decision.requires_approval and not approval.ok():
    audit.log(user_context, tool, tenant_id, "approval_required", reason="approval_required")
    return stop("approval_required")

result = tool.execute(args)
audit.log(user_context, tool, tenant_id, decision.outcome, reason=decision.reason, result=result)
return result

Як це виглядає під час виконання

Сценарій 1: доступ заборонено (deny)

Запит: користувач просить зробити refund
Runtime: сформовано tool call -> refund.create
Policy: перевірка role + tenant scope + permissions
Decision: deny (permission_denied)
Audit: decision=deny, role=support_agent, action=refund.create, reason=permission_denied
Stop: дія не виконана

---

Сценарій 2: доступ дозволено (allow)

Запит: той самий кейс для billing_manager у своєму tenant
Runtime: сформовано tool call -> refund.create
Policy: перевірка role + tenant scope + permissions
Decision: allow
Tool: refund.create виконано
Audit: decision=allow, role=billing_manager, action=refund.create, result=ok
Return: результат повернуто клієнту

Типові помилки

• одна "service" роль для всіх агентів і користувачів
• відсутність default-deny allowlist
• перевірка тільки ролі без tenant scope
• відсутність централізованого policy layer
• однакові права для read і write дій
• RBAC-логіка тільки в UI або промпті
• відсутній audit trail: роль, action, tenant, policy decision reason

У результаті система виглядає контрольованою, але доступи з часом втрачають межі.

Самоперевірка

Швидка перевірка RBAC перед запуском у production:

FAQ

Q: Як працювати з tools, які ходять у GitHub, Jira або інші зовнішні API?
A: Не давай агенту один спільний ключ на все. Краще використовувати user-scoped credentials, OAuth-токени або окремі service-account policy з явними межами доступу.

Q: Чим role відрізняється від tenant scope?
A: Role визначає, що можна робити. Tenant scope визначає, де це можна робити.

Q: Як безпечно додати новий tool у RBAC?
A: Додавай його через явну permission-модель: default deny, окремі права для read/write і перевірка tenant scope.

Q: Що впроваджувати першим: RBAC чи approval?
A: Спочатку RBAC з default deny і tenant scope. Потім додавай approval для ризикових write-дій.

Q: Чи достатньо тільки RBAC для production?
A: Ні. Додатково потрібні execution limits, бюджети, audit logs і kill switch.

Де RBAC у загальній системі

RBAC — це один із рівнів Agent Governance.
Разом із бюджетами, лімітами, approval і audit він формує єдину систему контролю виконання.

Пов'язані сторінки

Далі за темою:

• Огляд Agent Governance — загальна модель контролю агентів у production.
• Allowlist vs Blocklist — чому default-deny краще масштабується.
• Human Approval — як додати ручне підтвердження для ризикових дій.
• Audit Logs для агентів — як відновлювати ланцюг рішень у інцидентах.
• Kill Switch — як аварійно зупинити агента без релізу.