Контроль доступу агентів ШІ: RBAC, політики й аудити, що працюють у продакшені

RBAC надає попередньо визначені ролі для грубих, стабільних дозволів; ABAC використовує атрибути, як‑от орендар, кейс або часовий інтервал, щоб надавати динамічний, точний доступ. Більшості продакшен‑агентів потрібні обидва підходи: ролі для периметра та атрибути, щоб обмежити кожен запуск мінімально необхідними привілеями.

Розбийте широкі інструменти на вузькі дієслова, обгорніть кожен інструмент перевіркою політики та видавайте короткоживучі, обмежені токени на запуск. Прив’язуйте ідентичність і контекст завдання до кожного виклику, фільтруйте дані до того, як вони потраплять до моделі, і спрямовуйте вихідний трафік через проксі зі списком дозволених призначень.

Розміщуйте перевірки і у фреймворку, і поза ним. Оцінка плану до запуску рано ловить погані наміри, обгортки інструментів забезпечують політику на рівні викликів, а мережевий проксі та фільтри даних дають фінальний запобіжник, незалежний від фреймворку.

Ставтеся до політик як до коду й автоматизуйте тести: юніт‑тести для обгорток, сценарні тести для планів і змагальні підказки для ред‑тімінгу. Використовуйте «тіньові» запуски та канарейки, щоб перевірити поведінку на продакшен‑трафіку до вмикання запису.

Кожна дія має фіксувати хто (сервіс і кінцевий користувач), що (інструмент, ресурс, параметри), коли, де (середовище, орендар) і чому (політика та збіг умов), а також результат. Незмінні, придатні до запиту логи дозволяють безпечно пояснювати й за потреби відкочувати рішення агента.