Michael Johnson7 жовтня 2026 року Apollo GraphQL представила GraphOS Agent Services — попередню версію сервісу керування доступом ІІ-агентів до корпоративних API. Адміністратори можуть надавати доступ до окремих полів даних, маскувати їх або забороняти доступ до них. Підключення організовується за участю Apollo.
Що представила Apollo
За описом компанії, Agent Services розташовується між агентом і внутрішніми системами: перетворює звернення на виклики API, забезпечує роботу з обліковими даними та застосовує обмеження. Apollo виокремлює чотири функції: пошук даних та інструментів, керування ідентичністю, політики доступу й аудит. Їх перелічено в офіційному анонсі сервісу.
Поширений пресреліз Apollo на PR Newswire опубліковано 7 жовтня о 12:02 за східним часом США — о 19:02 за московським часом. Це час публікації заяви; точний час відкриття доступу окремо не зазначено.
Навіщо обмежувати доступ агента
Практичний сценарій Apollo — робота одного агента з різними працівниками. У прикладі з блогу компанії працівник служби підтримки та фінансовий аналітик запитують відомості про спірний рахунок. Обидва отримують рахунок, але кредитний ліміт клієнта доступний лише аналітику. Різниця визначається класифікацією поля та політикою доступу.
Такий підхід корисний командам, які підключають агентів до клієнтських, фінансових та інших внутрішніх сервісів: дозволи можна визначати для конкретних даних і враховувати, хто доручив агенту завдання. Apollo також повідомляє про пілотний проєкт в Intuit. Звичайний GraphOS там уже використовується в робочому середовищі, а новий Agent Services проходить попереднє тестування. Компанія пов’язує пілот із аналізом маркетингових витрат; кількісних результатів економії в анонсі немає.
Як працюють правила
Згідно з документацією з правил доступу, правило визначає користувача або групу, програму-клієнт, захищені дані та результат перевірки. Полям призначають теги; правило може поширюватися на тег або сервіс. Передбачено три варіанти дії: повернути значення, приховати його вміст або заборонити доступ.
Для заборони передбачено кілька варіантів: повністю вилучити поле з відповіді, повернути помилку або дозволити запит на додатковий доступ. Якщо поле має кілька тегів, перевагу має суворіша дія: заборона має вищий пріоритет за маскування, а маскування — за надання доступу.
Важлива особливість налаштування: Apollo попереджає в посібнику для адміністраторів, що сервіс поки не перевіряє ідентифікатор користувача або групи в постачальника ідентичності. Через помилку в написанні правило непомітно перестає збігатися із запитами. Тому перевірку фактичного результату для кожної ролі слід включити до пілотного проєкту.
За описом архітектури Apollo, рішення про доступ ухвалює механізм політик без участі мовної моделі. Там само зазначено, що поле без класифікаційного тегу залишається без обмежень. Водночас огляд документації пропонує заборонити доступ до полів підключеного сервісу, перш ніж надавати дозволи. Ці формулювання потребують перевірки в конкретній конфігурації: команді варто окремо протестувати доступ до полів із тегами та без них.
Аудит і доступність
У посібнику з Monitor описано журнал запитів: час звернення, клієнт, інструмент, операція, задіяний сервіс і результат застосування правил. Для окремого запиту можна переглянути, які правила спрацювали та які поля було замасковано або заблоковано.
Важливе обмеження аудиту: панель перегляду відповіді показує її структуру та змінені поля, але не значення, повернуті вихідним сервісом. Перевірку конкретного вмісту відповіді потрібно планувати окремо. Експорт CSV охоплює запити, завантажені на поточній сторінці журналу.
У джерелах по-різному позначено стадію доступу. У блозі від 7 жовтня Apollo оголошує про загальнодоступну попередню версію та пропонує список очікування. Документація сервісу називає стадію закритою попередньою версією й вимагає допомоги працівника Apollo для підключення. Дата оновлення цієї сторінки відсутня, тож послідовність появи цих формулювань встановити неможливо.
Практичний шлях зараз — узгодити пілотний проєкт з Apollo. У перевірених матеріалах не зазначено термін стабільного випуску та тариф Agent Services. Перед підключенням команді варто визначити перелік полів, доступних агенту, відповідальних за дозволи та тестові запити для кожної ролі.