以前はどのような状況か
業務部門は AI エージェントに顧客対応と資料の一次審査を担わせたいと考えていましたが、コンプライアンス部門には明確なレッドラインがありました。エージェントが開発者の個人資格情報で本番データにアクセスしてはならないこと、そしてすべてのデータアクセスを「どのユーザーがどのエージェントを認可したか」まで遡れることです。以前の試行ではエージェントが 1 個のサービスアカウントを共有しており、事故が起きても責任を特定できませんでした。
私たちが納品したもの
UIAM の Agent IAM を土台としました。エージェントは MACHINE 主体として登録され、独立した資格情報とロールを持ちます。ユーザーの代理で行動する際は RFC 8693 の Token Exchange を経由し、権限は「アプリ権限 ∩ ユーザー権限」の積集合として計算します。ツール呼び出しはその都度、認可とクォータを検証します。Uniclaw をエージェントランタイムとし、WeCom と社内システムに接続しました。
- エージェントは MACHINE 主体であり、人間ユーザーになりすまさない。トークンには principal_type=machine が入る
- 委任チェーンは act claim で「誰が誰の代理か」を表現し、マルチホップでもネストでき、完全に再生可能
- ツール単位の認可はドキュメントではなくコードのアノテーションに書く
- コンプライアンス部門はいつでもエージェント単位で、どの権限が使われたかまで含む完全な呼び出し記録を取得できる
コンプライアンス審査を一発で通せたのは、私たちの説明が上手かったからではありません。監査記録のどの項目も照会できたからです。
—— プロジェクトのコンプライアンス責任者
More Stories
Get in touch
アイデンティティ・エージェント・プライベートドメインの複雑さを、統治可能なひとつのカーネルへ
既存の IAM の置き換え、エージェント基盤の構築、あるいはプライベートドメイン運用の本格化——まずは 30 分のアーキテクチャ相談から始めましょう。私たちが得意とする種類の問題かを先に判断し、適さない場合は率直にお伝えします。