Що сталося
AWS повідомляє, що AgentCore Identity додала портал отримання згоди для тристороннього потоку OAuth AgentCore Gateway. Адміністратори налаштовують постачальника ідентифікаційних даних організації, цілі шлюзу, вихідних постачальників OAuth і роль виконання, а потім надають URL-адресу порталу користувачам. Користувачі самостійно входять, переглядають доступні служби та авторизують постачальників, наприклад GitHub або Slack.
AWS описує портал згоди як керований веб-доступ і кінцеву точку прив’язки до сеансу для шлюзу AgentCore. Портал обробляє переспрямування браузера та пов’язує користувача, який повернувся, з дозволом OAuth, тоді як AgentCore Identity зберігає результуючі маркери для кожного користувача у своєму сховищі маркерів.
Задокументована настройка вимагає, щоб адміністратор налаштував постачальника корпоративної ідентифікації, який видає маркер доступу JWT, який портал може перевірити, створити або надати роль виконання IAM, пов’язати цілі шлюзу з вихідними постачальниками OAuth і налаштувати URL-адреси повернення за умовчанням. Джерело наводить приклади з Okta та Auth0, але не стверджує, що це єдині підтримувані постачальники.
Потік кінцевого користувача залежить від постачальника та не залежить: розробник відкриває спільну URL-адресу порталу, проходить автентифікацію через постачальника ідентифікаційної інформації організації, переглядає запитаний доступ до служби та підключає GitHub або Slack. Існуючі з’єднання залишаються видимими після повторного відкриття порталу, якщо грант не відкликано, термін дії не закінчився або не вимагає оновленої згоди. Джерело підкреслює використання з Kiro, Claude Code, Cursor і Visual Studio Code, але не встановлює, що підтримується кожна версія або конфігурація цих клієнтів.
Деталі джерела: aws.amazon.com ↗
Чому це важливо
Ця функція вирішує практичну проблему контролю для агентів ШІ: гарантує, що доступ, наданий до таких служб, як GitHub і Slack, залишається прив’язаним до працівника, який його схвалив. Раніше клієнтам доводилося самостійно створювати та розміщувати перенаправлення браузера, кінцеву точку зворотного виклику, автентифікацію користувача, обробку сеансу та логіку зв’язування сеансу. Керований потік може зменшити роботу над впровадженням і зробити авторизацію для кожного користувача більш узгодженою для агентів, які використовуються через IDE та клієнти MCP, хоча джерело не встановлює доступність, надійність або результати безпеки за межами опису AWS.
Для помічника кодування AI прив’язка OAuth для кожного користувача визначає, чиї дозволи використовує агент, коли викликає інструменти. Це суттєво відрізняється від надання агенту спільних облікових даних служби, оскільки результуюча діяльність може залишатися пов’язаною зі співробітником, який авторизував доступ, залежно від ідентифікаційної інформації організації та конфігурацій постачальника.
Ця зміна може зменшити кількість спеціальної інфраструктури, необхідної для розгортання доступу до інструментів агента. AWS конкретно говорить, що раніше клієнтам доводилося розміщувати загальнодоступний зворотний виклик HTTPS, керувати сеансами браузера, автентифікувати користувача, що повернувся, і самостійно викликати CompleteResourceTokenAuth. Портал централізує ці дії в AgentCore Identity.
Видимість CloudTrail забезпечує операційний контроль: AWS каже, що події GetResourceOauth2Token ідентифікують постачальника облікових даних, запитані області, потік OAuth, роль виконання та регіон, тоді як конфіденційні значення маркера та стану редагуються. Джерело незалежно не перевіряє безпеку реалізації або кількісно будь-яке зниження ризику.
Інтерактивний механізм: як він насправді працює
Дослідіть технологію, що лежить в основі цієї розробки, в інтерактивному режимі.
crm_get_transaction(id='4092').An agent must create a draft calendar event for Tuesday at 2 p.m. Which evidence would establish the requested result?
Що дивитися далі
Організаціям, які розглядають цю функцію, потрібно буде підтвердити регіональну доступність, ціни, обмеження послуг, підтримуваних постачальників ідентифікаційної інформації та те, наскільки керований портал відповідає їхнім вимогам щодо перевірки доступу та життєвого циклу маркерів. Покрокове керівництво AWS також висвітлює події CloudTrail для перегляду операцій отримання згоди та усунення несправностей запитів маркерів.
Джерело не надає ціни, дати запуску, зобов’язань щодо рівня обслуговування, підтримуваних регіонів AWS, окрім того, що портали перераховані за обліковим записом і регіоном, або позначення загальної доступності. Тому доступ і комерційні умови залишаються невідомими.
Адміністратори повинні перевірити формат маркера постачальника ідентифікаційної інформації та ретельно визначити область дозволів IAM. Задокументована настройка також створює залежність між цільовими шлюзами та постачальниками вихідних облікових даних: AWS інструктує адміністраторів видалити цільовий шлюз перед видаленням постачальника, на який посилається.
Організаціям слід перевірити поновлення згоди, відкликання, закінчення терміну дії, поведінку відключення та повторного підключення, запитані області та аудит робочих процесів, перш ніж дозволити агентам отримати доступ до виробничих систем. Джерело описує ці потоки, але не повідомляє про незалежне тестування чи результати користувачів.