Curity のCTO、Jacob Ideskog – インタビューシリーズ

Jacob Ideskog は、アイデンティティスペシャリストであり、Curity のCTOです。彼の時間のほとんどは、APIおよびWeb空間におけるセキュリティソリューションの作業に費やされています。大規模なエンタープライズ導入から小規模なスタートアップまで、OAuthおよびOpenID Connectソリューションの設計と実装の両方に携わってきました。

Curity は、Curity Identity Serverを中心に構築された現代的なアイデンティティおよびアクセス管理（IAM）プラットフォームです。これは、標準ベースのソリューションとして設計され、アプリケーション、API、デジタルサービスに対する認証と認可を大規模に保護します。OAuth 2.0やOpenID Connectなどのプロトコルをサポートし、ログインフローを一元化し、きめ細かいアクセスポリシーを適用し、人間のユーザーとAPIやサービスを含むマシンクライアントの両方に対して安全なトークンを発行します。このプラットフォームは柔軟性と拡張性を考慮して設計されており、組織はクラウド、ハイブリッド、オンプレミス環境全体に展開し、既存システムと統合し、カスタム構築のセキュリティインフラに依存することなく、安全でシームレスなユーザーエクスペリエンスを提供できます。

クラウドの台頭から現在のAIに至るまで、Curityの共同創業からCTOとしてのリーダーシップまで、あなたはキャリアの多くをアイデンティティとAPIセキュリティシステムの構築に費やしてきました。その旅は、AIエージェントを単なるソフトウェアの一部ではなく、第一級のデジタルアイデンティティとして扱うべきだというあなたの見解をどのように形作ってきましたか？

私が携わってきた技術のあらゆる分野で、一つの問題が繰り返し浮上しています。クラウドコンピューティングであれ、現在のAIであれ、ソフトウェアが人や他のシステムに代わって行動する場合、アイデンティティの問題が生じます。

エージェント型AIの大規模な採用により、この問題はさらに複雑化しています。それらの動作はもはや厳密にスクリプト化されておらず、企業がこれまで経験したことのないレベルの自律性を持って動作します。AIエージェントは、多くの場合、直接的な人間の監視なしに、意思決定を行い、APIを呼び出し、システム間でアクションを連鎖させます。このような動作は、従来のソフトウェアとは根本的に異なるアイデンティティとアクセスの課題を生み出します。

AIエージェントを第一級のデジタルアイデンティティとして扱うことが、この問題に適切に対処する唯一の方法です。組織がそれらを単なる別のプロセスやサービスアカウントとして扱うと、可視性と制御を非常に迅速に失うことになり、それはセキュリティ危機の原因となります。

多くの企業はエージェント型AIに期待を寄せていますが、実験段階から抜け出せずにいます。実際の導入現場でご覧になっていることから、組織がエージェントを安全にスケールすることを妨げている、最も一般的なアイデンティティとガバナンスのギャップは何ですか？

ほとんどの実験は、スケール時に何が起こるかを無視した孤立したサンドボックスで行われます。初期のパイロット期間中、チームはしばしば、物事を軌道に乗せるためだけに、エージェントに広範なAPIキー、共有資格情報、または包括的なクラウド権限を与えます。

そのアプローチは、エージェントがパイロットを超えて展開される瞬間に破綻します。これは、セキュリティチームが、エージェントがどのデータにアクセスしたか、その行動、意図された範囲を超える可能性があるか、または既に超えてしまったか（偶発的または悪意による）を把握できないためです。これらの盲点により、エージェントを安全に統治することが不可能になり、多くの組織がパイロットを超えて進めない理由となっています。

あなたは、厳格なガードレールがエージェント型AIにとって不可欠であると主張してきました。実際の現場において、AIエージェントに対する「優れた」アイデンティティ設計とはどのようなものであり、企業は通常どこでそれを誤るのでしょうか？

優れたアイデンティティ設計は、最小権限の原則と明示的な意図に結びついた権限から始まります。各AIエージェントは、独自のアイデンティティ、狭くスコープされた権限、明確に定義された信頼関係（どのシステムとの相互作用が許可されるかの明示的なルール）を持つべきです。基本的に、アクセスは目的に縛られ、時間制限があり、取り消しやすいものであるべきです。

企業がこれを誤るのは、既存のサービスアカウントを再利用したり、内部エージェントはデフォルトで安全であると想定したりする場合です。その想定は、現実世界の脅威には当てはまりません。悪意のある行為者は、まさにこうした弱点を積極的に探しており、アイデンティティ設計がずさんな場合、AIエージェントは潜在的な被害範囲を劇的に増大させます。

Curityは長年、OAuthやOpenID Connectのような標準規格と共に活動してきました。複雑なエンタープライズ環境全体でエージェント型AIを相互運用可能かつ安全にするために、オープンなアイデンティティ標準はどれほど重要ですか？

オープン標準は絶対に重要です。企業は既に、クラウドプラットフォーム、SaaSサービス、内部APIにまたがる複雑なアイデンティティファブリックを運用しています。エージェント型AIは、さらに複雑さを加えるだけです。

標準がなければ、すべてのエージェントが独自の統合となり、恒久的なセキュリティ例外となります。OAuthやOpenID Connectのような標準があれば、エージェントは他のワークロードと同様に、認証、認可、監査を受けることができます。これは、実際のエンタープライズ環境全体で安全なスケーリングを促進できる唯一のアプローチです。

サービスアカウントからマシンアイデンティティまで、非人間アイデンティティがますます一般的になっています。セキュリティの観点から、AIエージェントは以前の非人間アイデンティティとどのように根本的に異なるのですか？

現代のAIエージェントと従来の非人間アイデンティティ（NHI）の主な違いは自律性です。従来のサービスアカウントは、そのコードが指示することを厳密にタスクに縛られて実行します。AIエージェントは、指示を解釈し、その行動を適応させ、明示的にスクリプト化されなかったアクションを実行します。これらはすべて、適切なガードレールがない場合の潜在的な危険性を高めます。

小さなアイデンティティやアクセスの誤りは、エージェントが高速で、かつ複数のシステムにわたって行動できるため、迅速に大惨事に変わる可能性があります。セキュリティの観点から、これは重大なリスクをもたらします。

監査証跡とアイデンティティベースのロギングは、特に規制産業において、エージェント型AIを統治する上でどれほど重要ですか？

監査証跡は「あれば良いもの」であってはなりません。それらは最初から組み込まれている必要があります。規制環境では、組織は単純だが重要な質問に答えることが期待されます：このエージェントは何にアクセスしたのか、いつ起こったのか、誰がそれを承認したのか？

アイデンティティベースのロギングは、そのレベルの説明責任を得る唯一の信頼できる方法です。それはまた、インシデント対応において重要な役割を果たします。明確なアイデンティティコンテキストがなければ、問題が不正動作するエージェント、侵害されたアイデンティティ、あるいは単に悪いプロンプトから生じたのかを知ることはほとんど不可能です。

組織が過剰な権限を持つ、または不十分に監視されたAIエージェントを本番環境に展開する場合、どのような現実世界のリスクが発生するとお考えですか？

一般的なリスクの一つは、サイレントなデータ集約です。過剰な権限を持つエージェントは、複数のシステム（顧客記録、内部文書、ログ）から機密情報を引き出し、その後、プロンプト、要約、または外部統合を通じてそのデータを暴露する可能性があります。

もう一つのリスクは、管理アクセス権を持つエージェントが、マシンスピードで大きな変更を行い、人間が短時間で行えるよりもはるかに大きな損害を引き起こすことです。これには、クラウドリソースの変更、セキュリティコントロールの無効化、監視なしでの自動化ワークフローのトリガーなどが含まれます。

これらのインシデントは悪意によるものかもしれませんが、必ずしもそうである必要はありません。過剰な権限を持つ、または不十分に監視されたエージェントは、単に古くなった、または誤った想定に基づいて動作し、誰も気付く前に複数のシステムにわたってミスを増幅させる可能性があります。

しかし、攻撃者の視点から見ると、侵害されたエージェントのアイデンティティは極めて価値があります。それは、人間のユーザーには決して与えられないレベルのアクセス権で、APIやサービスを横断的に移動することを可能にします。強力なアイデンティティ制御と監視がなければ、組織はしばしば、実際の損害が発生した後で初めてこれらの失敗を発見します。

パイロットから実際のエージェント型導入に移行する企業にとって、後でコストのかかる再設計を避けるために、早期にどのようなアイデンティティとアクセスの決定をすべきですか？

組織は、エージェントにどのようにアイデンティティが発行されるか、権限がどのように承認されるか、時間の経過とともにアクセスがどのようにレビューされるかを早期に決定し、アイデンティティの境界を事前に定義すべきです。

アイデンティティ制御を後から導入することは、ほとんど常に問題があります。エージェントは、共有資格情報や広範なロールを使用して、ワークフローに深く組み込まれていることが多いため、事後にアクセスを厳格化すると、システムが依存している想定が崩れます。これは最終的にワークフローを失敗させ、技術に対する信頼を損なうことになります。適切なアイデンティティ、スコープ、アクセス境界を最初から設計する方が、はるかにコストがかからず、言うまでもなくはるかに安全です。

エージェント型AIを展開する際、アイデンティティ統合はどこで最も頻繁にボトルネックとなり、摩擦を軽減するためのベストプラクティスは何ですか？

アイデンティティ管理は、後回しにされた場合にのみボトルネックになる可能性があります。チームはまず印象的なエージェント機能の構築に集中し、後になって、真に安全であるためにはIAMシステム、APIゲートウェイ、ロギングプラットフォームと統合する必要があることに気づきます。

最善のアプローチは、アイデンティティプラットフォームを明確に理解し、適切に実装することから始め、次にエージェントをそれらに適合するように設計することです。組織は、既存の標準とインフラをバイパスするのではなく、再利用すべきです。この手順を省くことは、必然的に後々問題を引き起こします。アイデンティティが最初から組み込まれている場合、それは展開を遅らせるのではなく、加速させます。

エージェント型AIを受け入れたいが、ガバナンスとリスクを懸念しているセキュリティおよびエンジニアリングリーダーに対して、彼らがロードマップを計画する際に、どのようなアドバイスをされますか？

基盤を正しく構築するために、十分に速度を落としてください。AIエージェントはアイデンティティとして扱われなければならず、したがって、人間に期待するのと同じガバナンスを適用し、最初から可視性を堅持する必要があります。組織がそれを行うならば、エージェント型AIのスケーリングは、盲目的で危険な信仰の飛躍ではなく、セキュリティの実践となります。

素晴らしいインタビューをありがとうございました。さらに詳しく知りたい読者は、Curity を訪れてください。