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