Аутентифікація визначає, хто ви є; авторизація вирішує, що ви можете робити. Дедалі більше застосунків на базі ШІ перевіряють особу користувача лише один раз під час входу, а потім дозволяють базовому агенту діяти з будь-яким ресурсом протягом решти сесії, фактично видаючи йому «порожній чек». Такий підхід відкриває двері для випадкового витоку даних, небажаних електронних листів або навіть руйнівних оновлень бази даних, а ризик зростає щоразу, коли ШІ-асистент може викликати кілька інструментів із мілісекундною затримкою.

Чому ця помилка повторюється

Більшість розробників ШІ розглядають екран входу як єдині ворота безпеки. Код запитує пароль або токен, позначає сесію як «аутентифіковану», а потім вважає, що будь-який наступний запит є безпечним. У традиційному вебзастосунку повільні кліки людини забезпечують природну точку обмеження швидкості; людина зробить паузу, перш ніж натиснути «видалити». ШІ-агент, однак, може виконувати десятки викликів інструментів за лічені секунди. Якщо платформа лише запитує «Чи увійшов користувач у систему?», кожен виклик успадковує ті ж самі необмежені привілеї.

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

Що стоїть на кону

  • Розкриття даних – Агент, який може читати будь-який файл після входу користувача, може ненавмисно включити конфіденційні документи у відповідь, яка згодом буде передана за межі організації.
  • Непередбачувані дії – ШІ-помічник інженера підтримки може виконати прямий SQL-запит до робочих баз даних просто тому, що сесія інженера все ще активна, навіть якщо запит не пов'язаний із тікетом, з яким працюють.
  • Відповідність нормативним вимогам – Багато правил захисту даних вимагають, щоб доступ був обмежений мінімально необхідним рівнем. Модель повних дозволів може порушати ці принципи та призводити до аудитів або штрафів.
  • Операційні витрати – Помилки, що видаляють або змінюють записи, змушують команди відкочувати зміни, розслідувати першопричини та відновлювати довіру користувачів — усе це витрачає час і гроші.

Відсутній крок: авторизація для кожної дії

Авторизацію слід перевіряти біля кожного «двері» всередині системи, а не лише на вході. Питання змінюється з «Хто це?» на «Чи може ця конкретна дія з цим конкретним ресурсом відбутися прямо зараз?». Впровадження такої перевірки не потребує повного перепроектування; потрібна лише зміна з єдиного прапорця сесії на короткострокові токени з обмеженою областю доступу.

Як це працює на практиці

  1. Запит токена з визначеною областю доступу – Коли ШІ-агенту потрібно викликати інструмент, він спочатку отримує токен, у якому перелічені точні дозволи (наприклад, read:ticket, execute:sql_query).
  2. Валідація токена для кожного виклику – Перед запуском інструменту сервіс перевіряє, чи містить токен необхідну область доступу і чи не закінчився термін дії токена.
  3. Відповідність ресурсу області доступу – Якщо запит спрямований на конкретний проєкт або базу даних, токен повинен явно надавати доступ до цього ідентифікатора.
  4. Відхилення або дозволу – Якщо будь-яка перевірка не проходить, виклик відхиляється, а агент отримує помилку, яку він може передати користувачеві.

Різниця в коді очевидна. «Поганий» підхід може виглядати так:

if session.is_authenticated():
    tool.run(params)

«Хороший» підхід розширює перевірку:

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

Другий патерн додає кілька рядків, але змушує систему ставити правильне запитання для кожної операції.

Стандарти, що полегшують роботу

Області доступу (scopes) OAuth 2.0 уже є широко впровадженим способом обмеження можливостей токена. Випускаючи короткострокові токени доступу, які кодують такі області, як project:1234:write або email:send, розробники можуть покладатися на існуючі бібліотеки для виконання кроку перевірки.

Новіші запити на розширену авторизацію (Rich Authorization Requests, RFC 9396) розширюють цю ідею, дозволяючи клієнту запитувати деталізовані дозволи під час виконання, а не визначати статичний список заздалегідь. Така гнучкість корисна, коли робочий процес ШІ може потребувати додавання або видалення можливостей на льоту залежно від намірів користувача.

Контраргумент: простота проти безпеки

Деякі команди стверджують, що перевірки для кожної окремої дії додають затримку та ускладнюють код, особливо коли ШІ-асистент має викликати багато інструментів поспіль. Вони зазначають, що використання одного сесійного токена дозволяє уникнути витрат на отримання та перевірку нового токена для кожного виклику. Однак ціною цього є значно вищий ризик зловживання. Сучасні сервіси валідації токенів розроблені для роботи за мікросекунди, а додатковий мережевий цикл (round-trip) можна групувати або кешувати без порушення принципу найменших привілеїв. У середовищах, де цілісність даних і відповідність нормативним вимогам є критично важливими, незначна втрата продуктивності компенсується зниженням ризиків.

На що варто звернути увагу далі

  • Впровадження токенів із обмеженим доступом (scoped tokens) в AI SDK – Стежте за оновленнями основних наборів інструментів (toolkits) для ШІ-платформ; багато з них починають надавати допоміжні функції для областей доступу (scopes) на основі OAuth.
  • Фреймворки «Політика як код» (Policy-as-code) – Нові рішення дозволяють командам описувати правила авторизації у декларативному файлі, автоматично застосовуючи їх під час виконання.
  • Журнали аудиту, що відображають рішення для кожної дії – Оскільки все більше платформ фіксують кожну перевірку авторизації, організації отримають можливість бачити, які дії ШІ дозволяються або блокуються, що допоможе в майбутньому коригувати політику.

Висновок

Сприйняття авторизованої сесії як дозволу на будь-які дії — це шлях до небажаних наслідків. Переносячи рішення про авторизацію з моменту входу в систему на кожен окремий виклик інструменту — і використовуючи короткострокові токени з обмеженим доступом — ШІ-додатки можуть зберігати зручність автономних агентів, водночас захищаючи дані, дотримуючись нормативних вимог і уникаючи дороговартісних помилок. Додаткові рядки коду — це мала ціна за систему, яка щоразу ставить правильне запитання під час спроби виконання дії.