プロダクト · アイデンティティと NHI
すべてのエージェントに固有のアイデンティティを — そして、それが無いときも把握できます
サービスアカウントを共有していると、「どのエージェントがこれを実行したのか」に答えられなくなります。Olivares はエージェントを非人間アイデンティティに紐づけ、エージェント専用の NHI を発行し、1つを共有しているエージェントを可視化します — これがアクセスを確実に帰属させるか、おおよそにとどまるかの違いです。解決できないアイデンティティが、本物のアイデンティティとして黙って扱われることは決してありません。アイデンティティのインベントリとエージェントのバインディングはCommunity、ディレクトリとロスターのコネクタ、エージェントアイデンティティのフェデレーション、PIV/CACはBusiness（Identity & Scale）です。エージェントの登録はBusiness（Identity & Scale）です。
プロダクト内
ID とアクセス
サンプルデータ。サインインに使うユーザーソース、グループ・ロール・サインイン方法付きの全ユーザー、ロールに対応付けたグループ。複数のユーザーソースと、グループからロールへの対応付けはBusiness（Identity & Scale）です。
ガバナンスの対象
共有アカウントから、エージェントごとのアイデンティティへ
アイデンティティは、アクセスマップが帰属の基準とする軸です。エージェントごとの専用 NHI は「おおよそ」を「確実」に変えます。以下に挙げるものはすべて、どこまで到達できるかについて正直です。
NHI を紐づける、または発行する
エージェントを既存の非人間アイデンティティに紐づけるか、エージェント専用の NHI を発行します。専用の NHI があってこそ、アクセスマップはアクセスを1つのエージェントに確実に帰属させられます — プールにおおよそ割り当てるのではなく。
アイデンティティ共有の検出
複数のエージェントが同じアカウントを使用している場合、エージェントごとの帰属は本質的に曖昧になります。Olivares はそれを検出事項として可視化し、その旨を明言します — 折衷案を取って、どのエージェントが動作したかを知っているふりはしません。
読み取り専用の WIF グラフ
正直な「不明」
Olivares が解決できないアイデンティティは「不明」として描画され、フラグが付けられます — 決して名前付きの NHI へ黙って昇格させることはありません。アイデンティティのシグナルが無ければ帰属も無い、とはっきり明言します。
仕組み
ID レコードと宣言された関係
NHI を作成すると、Olivares にエージェントごとの ID レコードが追加されます。そのレコードだけでは SPIFFE 認証情報を発行しません。また、それだけでフェデレーションが成立するわけではありません。図は宣言された関係を示し、解決できない ID は不明のままです。
実際に提供しているもの
ID レコード、設定可能な追加認証、フェデレーションの可視化
読み取り専用 WIF グラフは、設定されたフェデレーション規則を基にします。Anthropic WIF 接続と org:admin OAuth トークンが設定されている場合、Olivares は規則を現在のフェデレーション設定と比較し、情報の出所と差分を表示します。トークンがなければ宣言のみを表示し、ライブ照会に失敗した場合は利用不可と表示します。すべての ID プロバイダーとのフェデレーションを証明するものではありません。エージェントアイデンティティのフェデレーションはBusiness（Identity & Scale）です。
- 読み取り専用の取り込みとして提供中：ロスターコネクタが、ハイパースケーラーのエージェントアイデンティティレジストリ — Microsoft Entra Agent ID、AWS Bedrock AgentCore、Google のエージェントレジストリ — を読み取ります。これらに対する通信経路上のライブ検証付きフェデレーションはロードマップ上にあり、提供開始前に謳うことはありません。
- Communityには、有効なOIDCまたはSAMLのIDプロバイダーが1つ含まれます。Business: Identity & Scaleでは、ユーザー・グループ向けの受信SCIM 2.0サーバー、複数のIDプロバイダー、SSOポリシーの強制が加わります。
Business：ディレクトリと複数の IDプロバイダー
Community は 1 つの OIDC または SAML プロバイダーでサインインします。Business は、受信側の SCIM 2.0 サーバー、最大 5 つの有効な IDプロバイダー、Okta、Entra ID、Keycloak などからのディレクトリインポート、部門、送信側の SCIM プロビジョニング、PIV/CAC ステップアップ認証を追加します。
アイデンティティと NHI — よくある質問
Olivares は現在、Entra Agent ID、AWS AgentCore、Google Agent Identity とライブでフェデレーションしますか？
2つのエージェントが1つのサービスアカウントを共有しています。Olivares はどちらが動作したと判断しますか？
どちらでもありません、確実に。アイデンティティの共有はエージェントごとの帰属を本質的に曖昧にするため、Olivares はアイデンティティ共有の検出事項を提起し、アクセスをおおよそにとどめて帰属させます — どのエージェントが動作したかについて確実性を捏造することはありません。エージェント専用の NHI を発行すれば、アクセスマップはそのエージェントを確実に帰属させられるようになります。
特権ログインに対して WebAuthn AAL3 や PIV-CAC ステップアップをサポートしていますか？
Olivares は WebAuthn/FIDO2 と PIV/CAC に対応しています。管理者は追加認証ポリシーを選びます。none（既定、追加の認証操作なし）、totp（認証アプリのコードまたは対応する ID プロバイダーの MFA）、passkey（直近のパスキーまたは PIV 検証）です。緊急アクセスと重要な承認は、このポリシーに従います。認証、権限、テナント分離は引き続き適用されます。AAL3 は保証レベルの目標であり、NIST や FIPS の認証ではありません。PIV/CACとブレークグラスはBusinessです。
Community と Business には SSO と SCIM プロビジョニングが含まれますか？
Communityには、有効なOIDCまたはSAMLのIDプロバイダーが1つ含まれます。Business: Identity & Scaleでは、ユーザー・グループ向けの受信SCIM 2.0サーバー、複数のIDプロバイダー、SSOポリシーの強制が加わります。
帰属できるアイデンティティをエージェントに付与しましょう
Olivares をお客様自身のインフラにデプロイし、エージェントごとに専用の NHI を発行して、アクセスマップ上の「おおよそ」を「確実」に変えましょう。