Где Olivares AI встаёт рядом с вашим IdP

Частый первый вопрос архитектора безопасности: «Это ещё одна система идентичности, которую мне придётся эксплуатировать?» Нет. Olivares AI не является провайдером идентичности и не владеет идентичностями. Он потребляет идентичности, которые вы уже выпускаете — для людей из вашего IdP через SSO/SCIM; для агентов из реестров идентичности агентов, которые гиперскейлеры сделали общедоступными, — и использует их для атрибуции того, кто или что стоит за каждым ребром в карте доступа. Эта заметка объясняет точно, где проходит шов.

Слоистость

   Your IdP (Entra ID / Okta / Google)         ← humans: SSO + SCIM (unchanged)
   Agent-identity registries                    ← agents: Entra Agent ID,
     (Entra Agent ID / AgentCore / Google)        AgentCore Identity, Google Agent Identity
            │  read-only roster sync
            ▼
   Olivares AI  ── SPIFFE/WIF roster ──► R/RW access map (attributed edges)
            │                            └─ Permitted-vs-Observed drift
            └─ deny-closed gates (approvals, hooks PEP, MCP gating) — never an IdP

Люди аутентифицируются через ваш IdP. Olivares AI интегрируется со стандартными SSO и SCIM для учётных записей операторов и сопоставления групп с ролями; он не хранит учётные данные и не становится вторым каталогом. → Идентичность SSO и SCIM
Агенты получают свою идентичность из реестров, которые вы уже приняли. Olivares AI федерирует эти списки (rosters) только на чтение во внутренний список SPIFFE/WIF, так что каждый наблюдаемый доступ можно привязать к управляемой, именованной идентичности, а не к анонимному процессу.

Что на самом деле делает федерация идентичности агентов

Управляющий слой поставляет коннекторы списков только-на-чтение для общедоступных реестров идентичности агентов, каждый из которых проверен относительно своего первоисточника и deny-closed (нет учётных данных → пустой список, никогда не фантомная ошибка):

Microsoft Entra Agent ID — импортирует идентичности агентов, blueprints и связи владелец/спонсор через Microsoft Graph; обнажает осиротевшие записи (orphans), заявленные реестром. Blueprints, несущие долгоживущие парольные учётные данные, поднимают находку дрейфа долгоживущих учётных данных.
AWS AgentCore Identity — импортирует список агентов; агенты со служебной идентичностью отображаются на тип идентичности служебного аккаунта.
Google Agent Identity — импортирует идентичности reasoning-engine; ссылка представляет собой полный SPIFFE ID, так что она сходится со списком SPIFFE по внешнему id.

Эти сопоставления питают ось атрибуции карты доступа (firm / approximate / unknown) — они не переизобретают её. Федерация строго только-на-чтение: Olivares AI никогда не мутирует удалённый реестр. Сигналы владения и осиротелости пересылаются в жизненный цикл нечеловеческой идентичности (NHI), так что осиротевшая запись, заявленная реестром, проявляется через существующий механизм governance.

ID-JAG, XAA и клиентская аутентификация на основе SPIFFE

Корпоративные стандарты для делегированного, атрибутируемого доступа агентов сходятся, и управляющий слой построен так, чтобы оседлать их, а не изобретать собственные:

ID-JAG (Identity Assertion JWT Authorization Grant) и XAA (Cross-App Access) — это формирующийся шаблон для IdP, чтобы выпускать ограниченную по области (scoped), атрибутируемую авторизацию для агента, действующего поперёк приложений — расширение авторизации, управляемое предприятием, в работе по авторизации MCP. По мере их появления атрибутируемый токен становится ещё одним высокоточным сигналом, который карта доступа может привязать к управляемой идентичности.
Клиентская аутентификация OAuth на основе SPIFFE (draft-ietf-oauth-spiffe-client-auth) позволяет собственным потокам OAuth слоя аутентифицироваться с помощью SVID в тот момент, когда сервер авторизации опубликует поддержку — поверх существующего mTLS deny-by-default. Это движение-к, без заявления о соответствии, пока черновик и поддержка серверов не стабилизируются.
Короткоживущие по умолчанию. Долгоживущие статические учётные данные, обнаруженные во владении, помечаются как класс дрейфа, в соответствии с руководством Five Eyes (2026) о том, что учётные данные агентов должны быть короткоживущими.

Что это означает для вас

Вы сохраняете свой IdP, свой SSO, свой SCIM и тот реестр идентичности агентов, на котором вы стандартизировались. Ничего не мигрирует.
Olivares AI становится местом, где все эти идентичности встречаются с наблюдаемым поведением вашего владения — единственным слоем, который может сказать: «этот агент, из этого реестра, принадлежащий этому человеку, использует доступ, который политика никогда не предоставляла».
Поскольку федерация только-на-чтение и самостоятельно размещаема, эта корреляция не требует навязанной передачи данных. Обязательной телеметрии нет, а исходящий трафик управляющей плоскости по умолчанию отсутствует. За ваш периметр выходит только то, что вы настроили для передачи наружу: обращения к API ваших моделей, подключённые вами выходы SIEM/webhook и внешний поставщик эмбеддингов, если вы его настроили.

Связанное

Агент / Идентичность / NHI — определения из глоссария.
vs AI control towers — двунаправленная интеграция с административными слоями экосистемы.