Non-Human Identity: AI エージェントに Non-Human Identity が必要な理由

人間以外のアイデンティティとは何ですか?

あ Non-Human Identity ソフトウェア、サービス、自動プロセス、デバイス、ワークロード、または AI エージェントによって、人間のユーザーとして機能せずにシステムを認証およびアクセスするために使用されるデジタル ID です。

例には、サービス アカウント、サービス プリンシパル、マネージド ID、ワークロード、デバイス、ボット、スクリプト、CI/CD パイプライン、API 統合、AI エージェントなどが含まれます。

Non-Human Identity は、自動的に API キー、パスワード、トークン、証明書、マシン、ボット、またはモデルになるわけではありません。これらは、資格情報、認証メカニズム、実行エンティティ、接続されたリソースなどです。

モデルには 3 つの質問があります。

• Identity: 誰が、あるいは何を演じているのでしょうか？
• Credential: その身元をどうやって証明するのでしょうか？
• Permission: 何をアクセスしたり変更したりできるのでしょうか?

ID、資格情報、および許可

資格情報はアイデンティティそのものではありません。これは、ID が認証するために使用される証拠です。

人間以外のアイデンティティの主なタイプ

サービスアカウント

これらのアカウントは、アプリケーション、スクリプト、スケジュール、統合をサポートします。リスクには、所有権の共有、静的パスワード、過剰なアクセス、退職日の未定などが含まれます。

アプリケーションとサービス プリンシパルの ID

これらは、API、クラウド サービス、または SaaS や内部自動化などのリソースにアクセスするアプリケーションを表します。

マネージド ID とワークロード ID

これらは、仮想マシン、コンテナ、サーバーレス機能、CI/CD ジョブ、クラウド アプリケーションなどのソフトウェア ワークロードを表します。サポートされているプラ​​ットフォームでは、永続的なシークレットをコードに直接保存せずにそれらを使用できます。

マシンとデバイスの ID

これらは、証明書、キー、またはデバイス レコードを通じてサーバー、ラップトップ、ネットワーク機器、産業用システム、IoT デバイスを検証します。

AI エージェントのアイデンティティ

これらは、目標を解釈し、ツールを選択し、リソースにアクセスし、アクションを実行するエージェントを表します。 AI エージェントは Non-Human Identity 内に収まりますが、その適応的な動作により、固定されたサービス アカウントよりも管理が難しくなります。

人間以外のアイデンティティ と マシン ID と ワークロード ID

Non-Human Identity 幅広の傘です。 Machine identity、ワークロード ID、サービス アカウント、およびエージェント ID は、より狭いカテゴリまたは実装パターンです。

人間以外のアイデンティティと関連するアイデンティティ タイプの比較

用語はプラットフォームによって異なります。ガバナンスは、アイデンティティが何を表すか、どこで実行されるか、何にアクセスできるか、誰が所有するかに重点を置く必要があります。すべての Non-Human Identity が物理マシンを表すわけではありません。

AI エージェントが人間以外のアイデンティティの問題を変える理由

エージェントは決まった指示だけでなく目標に従います

従来の自動化では、深夜にバックアップがコピーされる場合があります。異常なパフォーマンスを調査してレポートを作成するよう依頼されたエージェントは、発見した内容に応じて異なるアクションを選択する場合があります。

エージェントは複数のツールを使用する

1 つのエージェントが、API、ファイル、ブラウザ、スプレッドシート、データベース、コミュニケーション ツール、およびサブエージェント間を移動する場合があります。各接続は許可チェーンを拡張します。

権限はタスクによって異なります

調査、レポート、およびカスタマー サポートのワークフローは、単に同じプラットフォームを使用しているという理由だけで、同じ永続的なアクセス権を受け取るべきではありません。

エージェントは委任することができます

プライマリ エージェントは、専門ツールまたは別のエージェントに電話をかけることができます。アクセスは追跡可能であり、明確なルールに基づいて継承されるか、個別に承認される必要があります。

エージェントは人々に代わって行動します

システムは、人間のアクション、人間が要求したエージェントのアクション、承認されたタスク内でエージェントが選択したステップ、および委任されたアクションを区別する必要があります。 Agent identity は、要求者、実行者、資格情報、および結果の間のリンクを保持する必要があります。

AI エージェントが人間のアカウントの後ろに隠れてはいけない理由

エージェントは、従業員のブラウザ セッション、API トークン、電子メール アカウント、またはアプリケーション ログインを使用できます。ワークフローは機能するかもしれませんが、帰属が弱くなります。

ログには従業員アカウントのみが表示されますが、エージェントは従業員がアクセスできるすべてのものを継承します。セキュリティ チームは人間の行動を自動化から確実に分離することができず、意図したタスクを超えてアクセスが存続する可能性があります。

より優れたアトリビューション モデルは次のとおりです。

• Initiated by: アレックス
• Executed by: Weekly Reporting Agent
• Environment: 承認された企業デスクトップ
• Approved by: 財務マネージャー

スポンサーは引き続き目的に対して責任を負いますが、エージェントのアイデンティティは誰が作業を実行したかを示します。エージェントは、人間と区別できなくなることなく、人間のために行動する必要があります。

管理されていない非人間のアイデンティティの主なリスク

孤立したアイデンティティ

従業員が退職した後、プロジェクトが終了した後、統合が置き換えられた後、またはエージェントが放棄された後も、アクセスはアクティブなままになります。

過剰な権限

狭いポリシーは失敗の原因となり、一時的な利便性が永続的な特権となるため、幅広いアクセスが許可されます。

有効期間の長い認証情報

静的パスワード、API キー、証明書、トークンは、最初の必要性がなくなった後も長期間使用し続けることができます。

共有アイデンティティ

複数のアプリケーション、エージェント、または従業員が 1 つのアカウントを使用するため、帰属と所有権が弱められます。

アイデンティティの広がり

Service accounts、ボット、OAuth アプリ、トークン、スクリプト、子エージェントは、信頼できるインベントリなしで蓄積されます。

説明責任が弱い

インシデントが発生した後、要求者、ワークフロー所有者、アプリケーション所有者、承認者、およびテクノロジープロバイダーの間で責任が争われる可能性があります。

多くの場合、最大のリスクは、アイデンティティが存在することではなく、アイデンティティがなぜ存在するのか、何ができるのか、いつ消滅すべきなのかが誰も分からないことです。

8 段階の人間以外のアイデンティティのライフサイクル

Step 1: 発見する

サービス アカウント、アプリケーション ID、OAuth アプリ、クラウドおよびローカル エージェント、ボット、スクリプト、証明書、スケジュール、API 統合、および接続されたツールをインベントリします。

Step 2: 登録する

一意の名前、タイプ、目的、作成者、スポンサー、部門、ランタイム、接続されたツール、アクセス可能なデータ、認証情報のタイプ、有効期限を記録します。

Step 3: 人間のスポンサーを割り当てます

指定された担当者は、目的の承認、アクセスの確認、インシデントへの対応、所有権の譲渡、および退職の承認を行う必要があります。

ステップ 4: ID 境界を定義する

許可されたシステム、フォルダー、レコード、ツール、アクション、および明示的な禁止事項を文書化します。

Step 5: 最小権限を適用します

現在のワークフローに必要なものだけを付与します。障害を減らすためだけに追加された永続的な管理アクセスは避けてください。

Step 6: 有効期間の短い認証情報を優先する

サポートされている場合は、一時トークン、マネージド ID、ワークロード フェデレーション、タスク スコープの資格情報、有効期限、取り消しを使用します。

Step 7: 動作を監視する

認証イベント、アクセスされたリソース、呼び出されたツール、開かれたファイル、変更、転送、失敗、再試行、委任をキャプチャします。

Step 8: ローテーション、移転、および引退

ワークフローが変更または終了すると、資格情報のローテーション、所有権の譲渡、スケジュールの削除、権限の取り消し、ツールの切断、子 ID の廃止、監査記録の保持が行われます。

人間以外のアイデンティティのライフサイクル チェックリスト

AI エージェントに最小権限のアクセスを与える方法

エージェントの最大の能力ではなく、最小限の権限がワークフローに従う必要があります。

週次レポート エージェントには、レポート フォルダー 1 つ、ダッシュボード 2 つ、CSV ダウンロード、出力ディレクトリ 1 つ、およびドラフトを準備する権限が必要な場合があります。ハード ドライブ全体、すべてのブラウザ プロファイル、個人メール、請求管理、権限管理、ソース ファイルの削除、またはレポートを外部に送信する権限は必要ない場合があります。

4 つのレイヤーを定義します。

• Resource scope: どのシステム、フォルダー、アプリケーション、レコードですか?
• Action scope: 読み取り、書き込み、変更、削除、公開、または送信しますか?
• Time scope: 永続的、スケジュール済み、一時的、またはタスクベース?
• Approval scope: 明示的な確認が必要なアクションはどれですか?

最小権限は、エージェントが表示できる内容、実行できる内容、実行できる期間、および誰の承認の下に実行できるかを制限します。

デスクトップ AI エージェントに明確なアイデンティティ境界が必要な理由

デスクトップ エージェントは、ローカル ファイル、インストールされているアプリケーション、ブラウザ セッション、保存された資格情報、ダウンロード、スクリーンショット、クリップボードのコンテンツ、オペレーティング システム コントロール、および通信アプリと対話する場合があります。したがって、そのアイデンティティ境界は複数の API にまたがることがあります。

デスクトップ ワークフローには以下が含まれる場合があります。

人間の要求者 -> 通信チャネル -> デスクトップ エージェント -> 企業デバイス -> ブラウザ ID -> ビジネス アプリケーション -> 出力フォルダー

組織は、誰がタスクを送信したか、どのエージェントがそれを受け取ったか、どのデバイスとアカウントが使用されたか、どのようなアクションが発生したか、どのような出力が作成されたか、誰がレビューしたかを把握する必要があります。

ローカルで実行すると、構成によってはデータ送信が一部削減される場合があります。 ID リスクが除去されるわけではありませんし、エージェントが誰を代表しているのか、どの権限を使用しているのかを明らかにすることもできません。

EasyClaw は、デスクトップ エージェントがファイル、ブラウザ、アプリケーション、出力にわたって明示的な境界を必要とする理由を示しています。

EasyClaw がガバナンスエージェント Identity 戦略にどのように適合するか

EasyClaw は、ローカル ファイル、アプリケーション、ブラウザ インターフェイス、レポート、レビュー、プロジェクト フォルダーを含む作業のためのデスクトップ ネイティブ AI ワークフロー エージェントです。これは、ID 管理プラットフォームでも、IAM、特権アクセス、認証情報のローテーション、脅威制御の代替品でもありません。

その実際的な役割は、デスクトップ エージェントが名前付き、制限付き、可視、レビュー可能な ID 境界内で動作する必要がある理由を説明することです。

人間の要求者を特定する

EasyClaw タスクを発行できるユーザー、承認されるチャネル、要求者の認証方法、機密性の高いワークフローを開始できるユーザーを定義します。すべてのリクエストは特定の人につながる必要があります。

実行中の EasyClaw 環境を特定する

EasyClaw の展開、企業デバイス、オペレーティング システム アカウント、ブラウザ プロファイル、承認されたアプリケーション、およびワークフロー所有者を記録します。リクエスターと実行環境は接続されていますが、それらは同じアクターではありません。

ファイルとアプリケーションのスコープを制限する

レポート ワークフローには、フォルダー 1 つ、Excel ワークブック 1 つ、選択したダッシュボード、PDF テンプレート、および出力ディレクトリ 1 つが必要になる場合があります。すべてのローカル ファイル、ブラウザ アカウント、クラウド ドライブ、管理設定、または無関係なシステムに自動的にアクセスするべきではありません。スコープをクリアすると、間違ったファイルの選択や誤って上書きすることも減ります。

重要な行動は承認の後に控える

外部メッセージ、公開、ファイルの削除または上書き、財務情報の送信、顧客記録の変更、権限の変更、支払いの完了、契約の変更には人間の承認が必要です。

EasyClaw は、中間作業を整理し、レビュー パッケージを準備し、使用可能な成果物を返すことができます。取り消し不可能な、外部から見える、経済的に重要な、または法的に重大な決定は、責任ある人間が負うべきです。

ワークフローのライフサイクルを文書化する

各ワークフローには、名前、目的、スポンサー、承認された入力、アクション、出力先、レビュー日、停止条件、および終了手順が必要です。新しいアカウント、チャネル、または宛先はレビューをトリガーする必要があります。

EasyClaw は、人間のアカウントから無制限のアクセスを借用する目に見えないソフトウェアとしてではなく、承認されたワークフロー内で可視かつ範囲指定されたデスクトップ エージェントとして動作する必要があります。

例: EasyClaw レポートエージェントに明確な ID 境界を与える

運用マネージャーは次のように要求します。「今週のパフォーマンス レポートを作成し、先週と比較し、レビューのために草案を返してください。

承認された EasyClaw ワークフローは、選択したダッシュボードを開き、現在のエクスポートをダウンロードし、毎週の Excel トラッカーを読み取り、以前のレポートを比較し、ドラフトを準備し、パッケージを保存して返します。 EasyClaw は、大量のドキュメントの実行を処理しますが、ID とセキュリティの制御は、EasyClaw が使用できるものを定義します。

EasyClaw レポート ワークフローのアイデンティティ境界

アトリビューション チェーンは表示されたままにする必要があります。

• Initiated by: Operations manager
• Executed by: EasyClaw reporting workflow
• Data accessed: 承認されたダッシュボードとレポートフォルダー
• Reviewed by: Operations manager
• Distributed by: 承認後の人間の所有者

これにより、リクエスト、実行、アクセス、承認、配布が分離されます。数値が間違っていると思われる場合、チームは承認されたソース、使用されたファイル、生成された出力、およびレビュー担当者の決定を検査できます。 EasyClaw はワークフロー実行層です。既存の ID システムは、引き続き認証、資格情報、権限、およびポリシーを担当します。

結論: すべてのエージェントには Identity、所有者、有効期限が必要です

Non-Human Identity には、アプリケーション、サービス、マシン、ワークロード、スクリプト、ボット、自動プロセス、AI エージェントが含まれます。

AI エージェントは、その動作が適応性があり、委任され、ツール間で分散できるため、リスクが高まります。組織は、どのエージェントが動作するのか、誰がスポンサーなのか、どのような資格情報と権限を使用するのか、アクションがどのように記録されるのか、いつ承認が必要なのか、いつアクセスが期限切れになるのかを把握する必要があります。

EasyClaw はアイデンティティ管理プラットフォームではありません。そのデスクトップ実行モデルは、エージェントのワークフローに指名された所有者、制限されたファイルとアプリケーションへのアクセス、目に見える実行、レビュー可能な出力、および結果的なアクションに対する人間の承認が必要な理由を示しています。

すべての AI エージェントには、ID、人間のスポンサー、権限の境界、および有効期限が必要です。

よくある質問