产品内部
身份与访问
示例数据。人员登录所用的用户来源、每个用户及其组、角色和登录方式，以及映射到角色的组。多个用户来源以及组到角色的映射属于 Business（Identity & Scale）。
您所治理的对象
从共用账号到每个智能体的专属身份
身份是访问地图进行归因所依据的轴心。为每个智能体分配专属 NHI，可将“大致”变为“确凿”；以下各项都坦诚说明各自能做到何种程度。
绑定或铸造 NHI
将智能体绑定到现有的非人类身份，或为每个智能体铸造专属 NHI。专属 NHI 才能让访问地图把访问确凿归因到某一个智能体——而非大致归因到一个资源池。
共用身份发现项
当不止一个智能体共用同一账号时，逐智能体归因就确实存在歧义。Olivares 会将其作为一项发现呈现并如实说明——它不会折中处理、假装自己知道是哪个智能体在行动。
只读 WIF 关系图
诚实面对未知
Olivares 无法解析的身份会被绘制为未知并加以标记——绝不会被悄悄提升为某个具名 NHI。没有身份信号就意味着无法归因，这一点会被明确说明。
运作方式
身份记录与已声明的关系
创建 NHI 会在 Olivares 中添加每个智能体的身份记录。该记录本身不会签发 SPIFFE 凭据，也不会建立联合身份关系。图示说明已声明的关系；无法解析的身份仍标为未知。
哪些已成真
身份记录、可配置的额外验证和联合身份可见性
只读 WIF 图以配置的联合身份规则为基础。配置 Anthropic WIF 连接和 org:admin OAuth 令牌后，Olivares 会将这些规则与实时联合身份配置比较，并显示来源和差异。没有该令牌时只显示声明；实时查询失败时会标为不可用。这并不能证明与所有身份提供商建立了联合身份关系。智能体身份联合属于 Business（Identity & Scale）。
- 已作为只读摄取交付：名册连接器读取超大规模云厂商的智能体身份注册表——Microsoft Entra Agent ID、AWS Bedrock AgentCore 以及 Google 的智能体注册表。对照这些注册表在链路上经实时验证的联邦仍在路线图中，在其交付之前我们绝不声称已实现。
- Community 包含一个启用的 OIDC 或 SAML 身份提供商。Business: Identity & Scale 增加面向用户和组的入站 SCIM 2.0 服务器、多个身份提供商和强制 SSO 策略。
Business：目录与多个身份提供商
Community 通过一个 OIDC 或 SAML 提供商登录。Business 增加入站 SCIM 2.0 服务器、最多五个活跃身份提供商、从 Okta、Entra ID、Keycloak 等导入目录、部门、SCIM 出站预配和 PIV/CAC 升级验证。
身份与 NHI——常见问题
Olivares 如今能否与 Entra Agent ID、AWS AgentCore 或 Google Agent Identity 进行实时联邦？
两个智能体共用一个服务账号。Olivares 会说是哪一个在行动？
都不会确凿指认。共用身份会让逐智能体归因确实存在歧义，因此 Olivares 会提出一项共用身份发现项，并仅以大致方式归因访问——它不会凭空捏造关于哪个智能体在行动的确定性。为每个智能体铸造专属 NHI，访问地图便可对该智能体进行确凿归因。
你们是否支持针对特权登录的 WebAuthn AAL3 或 PIV-CAC 升级验证？
Olivares 支持 WebAuthn/FIDO2 和 PIV/CAC。管理员选择额外验证策略：none（默认，无额外验证仪式）、totp（验证器代码或受支持的身份提供商 MFA）或 passkey（近期的通行密钥或 PIV 验证）。紧急访问和关键审批遵循该策略。身份验证、权限和租户隔离仍然生效。AAL3 是保证等级目标，并非 NIST 或 FIPS 认证。PIV/CAC 和紧急访问属于 Business。
Community 和 Business 是否包含 SSO 和 SCIM 配置？
Community 包含一个启用的 OIDC 或 SAML 身份提供商。Business: Identity & Scale 增加面向用户和组的入站 SCIM 2.0 服务器、多个身份提供商和强制 SSO 策略。