ヤコブ・イデスコグ、CurityのCTO – インタビュー・シリーズ

ヤコブ・イデスコグは、アイデンティティ・スペシャリストであり、CurityのCTOです。彼のほとんどの時間は、APIとWebのセキュリティ・ソリューションに取り組むことに費やされています。彼は、OAuthとOpenID Connectの設計と実装に携わり、企業やスタートアップの両方で大規模な展開を行ってきました。

Curityは、Curity Identity Serverを中心としたモダンなアイデンティティ・および・アクセス・マネジメント（IAM）プラットフォームです。標準ベースのソリューションとして設計されており、認証と承認をアプリケーション、API、デジタル・サービスに対して安全に行えます。OAuth 2.0やOpenID Connectなどのプロトコルをサポートしており、ログイン・フローを集中管理し、ファイングレイン・アクセス・ポリシーを適用し、人間のユーザーとマシン・クライアントの両方に対してセキュアなトークンを発行します。クラウド、ハイブリッド、オンプレミス・環境に展開可能であり、既存のシステムと統合し、カスタム・セキュリティ・インフラストラクチャに依存せずにセキュアなユーザー・エクスペリエンスを提供します。

あなたは、キャリアのほとんどをアイデンティティとAPIセキュリティ・システムの構築に費やしてきました。Curityの共同創設者からCTOとしての役割を経て、クラウドとAIの台頭を見てきました。この経験が、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エージェントと従来の非人間アイデンティティ（NHIs）の主な違いは、自律性です。従来のサービス・アカウントは、コードによって厳密に定義されたタスクのみを実行します。一方、AIエージェントは指示を解釈し、動作を適応させ、明示的にスクリプト化されていないアクションを実行します。これにより、適切なガイドレールがなければ、危険性が高まります。

小さなアイデンティティまたはアクセス・エラーは、すぐに大惨事になる可能性があります。エージェントは高速で複数のシステムで動作するため、セキュリティの観点から重大なリスクを生み出します。

規制された業界では、AIエージェントのガバナンスとリスクを管理する上で、監査トレイルとアイデンティティ・ベースのログはどれほど重要ですか。

監査トレイルは「望ましい」ものではなく、最初から組み込まれる必要があります。規制環境では、組織は次のような質問に答えることが求められます。エージェントは何にアクセスしましたか。いつ起こりましたか。誰が承認しましたか。

アイデンティティ・ベースのログは、説明責任を確保する唯一の信頼できる方法です。また、インシデント・レスポンスにも重要な役割を果たします。アイデンティティのコンテキストが明確でないと、問題がエージェントの不正行為、コンプロマイズされたアイデンティティ、または単純に悪いプロンプトによるものかどうかを判断することはほぼ不可能です。

実際の展開で、過剰に特権化されたり、不十分に監視されたりしたAIエージェントを展開すると、どのようなリスクが生じますか。

1つの一般的なリスクは、サイレント・データ・アグリゲーションです。過剰に特権化されたエージェントは、複数のシステムから機密情報を抽出し、プロンプト、サマリー、または外部統合を介してそのデータを公開する可能性があります。

別のリスクは、管理者アクセス権を持つエージェントが、人間が短時間で行うことができないほどの重大な変更を高速で行う可能性があります。これには、クラウド・リソースの変更、セキュリティ・コントロールの無効化、またはオーバーサイトなしで自動ワークフローをトリガーすることが含まれます。

これらのインシデントは、悪意のあるものである必要はありません。過剰に特権化されたまたは不十分に監視されたエージェントは、古いまたは不正確な仮定に基づいて動作し、複数のシステムで間違いを拡大させる可能性があります。

しかし、攻撃者の観点から見ると、コンプロマイズされたエージェント・アイデンティティは非常に貴重です。APIやサービスを横断してアクセスできるようになり、人間のユーザーが持つことのできないレベルのアクセス権を得ることができます。強力なアイデンティティ・コントロールと監視がなければ、組織は実際の被害が発生した後で初めてこれらの失敗に気づくことになります。

パイロットから実際のAIエージェントの展開に移行する企業にとって、アイデンティティとアクセスの決定を早期に下すことが重要です。そうしないと、後に高額なリデザインを余儀なくされる可能性があります。どのような決定が必要ですか。

組織は、エージェントにアイデンティティを発行する方法、パーミッションを承認する方法、アクセスを時間の経過とともにレビューする方法を、早期に決定する必要があります。アイデンティティの境界を最初から定義する必要があります。

アイデンティティ・コントロールを後から導入することは、ほぼ常に問題があります。エージェントは、共有資格情報または広範なロールを使用してワークフローに深く埋め込まれているため、後にアクセスを絞ることは、システムが依存する仮定を破壊し、ワークフローを壊し、テクノロジーに対する信頼を損なうことになります。最初から適切なアイデンティティ、スコープ、そしてアクセス境界を設計することは、はるかに安価で、安全です。

AIエージェントの展開時に、アイデンティティの統合がボトルネックになることがあります。アイデンティティの統合がボトルネックになる最も一般的なポイントはどこですか。フリクションを軽減するためのベスト・プラクティスは何ですか。

アイデンティティ・マネジメントは、後に考慮される場合にのみボトルネックになる可能性があります。チームは、まず印象的なエージェントの機能を構築し、後にそれらをIAMシステム、APIゲートウェイ、ログ・プラットフォームと統合してセキュリティを確保する必要があると考えます。

ベスト・アプローチは、アイデンティティ・プラットフォームとその理解を最初から持つことです。エージェントは、既存の標準とインフラストラクチャを再利用するように設計する必要があります。コーナーを切ることは、必ず将来の問題を引き起こします。アイデンティティが最初から組み込まれている場合、展開を加速するのではなく、遅くするのです。

ガバナンスとリスクについて心配しているセキュリティとエンジニアリングのリーダーが、AIエージェントのロードマップを計画する際に、どのようなアドバイスをしますか。

基盤を正しく構築するために、十分な時間を取ります。AIエージェントは、アイデンティティとして扱われ、最初からガバナンスと視認性を適用する必要があります。組織がそうする場合、AIエージェントのスケーリングは、盲目的な信念ではなく、セキュリティの実践になります。

素晴らしいインタビュー、詳しく知りたい読者はCurityを訪問してください。