Продукт · Identity & NHI
Дайте кожному агентові власну ідентичність — і знайте, коли її немає
Спільний службовий обліковий запис робить питання «який агент це зробив?» таким, що не має відповіді. Olivares прив’язує агента до нелюдської ідентичності, створює окрему NHI для кожного агента й виявляє агентів, що використовують спільну, — у цьому й полягає різниця між упевненою та лише приблизною атрибуцією доступу. Ідентичність, яку система не може розпізнати, ніколи мовчки не вважається справжньою.
У продукті
Консоль ідентичностей
Справжній знімок екрана, приклад даних. Вкладки для реєстру NHI, автентифікації MCP, графа WIF, стану ключів і резидентності та привілейованих входів. Вкладка SSO/SCIM відверто показує власний шов: бекенд-ендпоінт ще не працює, тому вона нічого не показує замість того, щоб вигадувати дані.
Чим ви керуєте
Від спільного облікового запису до ідентичності для кожного агента
Ідентичність — це вісь, за якою карта доступу атрибутує доступ. Окрема NHI для кожного агента перетворює «приблизно» на «упевнено»; усе наведене нижче чесно показує, наскільки далеко воно може зайти.
Прив’яжіть або створіть NHI
Прив’яжіть агента до наявної нелюдської ідентичності або створіть окрему NHI для кожного агента. Саме окрема NHI дає змогу карті доступу атрибутувати доступ упевнено до одного агента, а не приблизно до пулу.
Виявлення спільної ідентичності
Коли кілька агентів використовують один обліковий запис, атрибуція до конкретного агента справді неоднозначна. Olivares виявляє це й прямо про це повідомляє — він не йде на компроміс і не вдає, ніби знає, який агент діяв.
Граф WIF лише для читання
Граф федерації ідентичностей робочих навантажень зіставляє ідентичності ваших агентів з вашим IdP. Він відображається лише для читання на основі правил федерації, які ви оголошуєте, — це подання того, що ви задекларували, а не жива перевірка довіри на каналі зв’язку.
Чесне невідоме
Ідентичність, яку Olivares не може розпізнати, зображується як невідома й позначається — її ніколи мовчки не підвищують до названої NHI. Відсутність сигналу про ідентичність означає відсутність атрибуції, і про це сказано прямо.
Як це працює
Федерація ідентичності кожного агента з вашим IdP
Кожен агент отримує власну ідентичність — облікові дані SPIFFE/WIF, — яка федерується з вашим постачальником ідентичностей. Агент без розпізнаваної ідентичності не вливається у справжню: він зображується окремо й позначається.
Що реальне
Прив’язка NHI та граф WIF працюють; жива федерація та підвищення до AAL3 — ні
Ми точні в цьому, бо саме ця різниця — увесь сенс поверхні ідентичностей:
- Працює: прив’язка агента до NHI, створення окремої NHI для кожного агента, виявлення спільної ідентичності та граф WIF лише для читання. Граф відображає правила федерації, які ви оголошуєте, — це не перевірена наживо картина федерації на каналі зв’язку.
- У дорожній карті: жива федерація з реєстрами ідентичностей агентів від гіперскейлерів у статусі GA — Microsoft Entra Agent ID, AWS AgentCore, Google Agent Identity. Сьогодні ми відображаємо оголошені правила й не заявляємо про живу перевірку, доки її не буде випущено.
- Не реалізовано: підвищення WebAuthn AAL3 / PIV-CAC. Воно не реалізоване й сьогодні безпечно деградує до AAL1 — ми кажемо AAL1, а не той рівень довіри, якого не заслужили. Деякі живі джерела ідентичностей (LDAP, IdP, менеджери секретів) і SCIM Groups ще не підключені, і вкладка SSO/SCIM відверто про це говорить: бекенд-ендпоінт в очікуванні, показувати нічого, нічого не сфабриковано.
Identity & NHI — запитання
Чи федерується Olivares наживо з Entra Agent ID, AWS AgentCore або Google Agent Identity сьогодні?
Ні — не наживо. Граф WIF доступний лише для читання й відображається на основі правил федерації, які ви оголошуєте, тож він показує те, що ви задекларували, а не перевірені наживо відносини довіри на каналі зв’язку. Жива федерація з тими реєстрами ідентичностей агентів від гіперскейлерів у статусі GA є в дорожній карті, і ми не заявляємо про неї, доки її не буде випущено.
Два агенти використовують один службовий обліковий запис. Про якого з них Olivares каже, що він діяв?
Ні про якого, упевнено. Спільна ідентичність робить атрибуцію до конкретного агента справді неоднозначною, тому Olivares створює виявлення спільної ідентичності й атрибутує доступ лише приблизно — він не вигадуватиме впевненості щодо того, який агент діяв. Створіть окрему NHI для кожного агента, і тоді карта доступу зможе атрибутувати того агента упевнено.
Чи підтримуєте ви підвищення WebAuthn AAL3 або PIV-CAC для привілейованих входів?
Поки що ні. Підвищення до AAL3 через WebAuthn або PIV-CAC не реалізоване; сьогодні цей шлях безпечно деградує до AAL1, і саме так ми його й позначаємо — ми не показуємо рівень довіри, якого не заслужили. Вкладка привілейованих входів показує те, що фактично застосовується зараз.
Чому вкладка SSO/SCIM порожня?
Тому що бекенд-ендпоінт для неї ще не працює, тож показувати справді нічого — і продукт прямо про це говорить, а не засіває її даними, що мають правдоподібний вигляд. Те саме стосується живих джерел ідентичностей, як-от LDAP, IdP та менеджери секретів, і SCIM Groups: ще не підключені, показані чесно порожніми.
Дайте своїм агентам ідентичності, які можна атрибутувати
Розгорніть Olivares на власній інфраструктурі, створіть окрему NHI для кожного агента й перетворіть «приблизно» на «упевнено» на вашій карті доступу.