Sean Blanchfield, Jenticの共同創設者兼CEO – インタビュー・シリーズ

Sean Blanchfield、Jenticの共同創設者兼CEOは、数十年の経験を持つシリアル・テクノロジー・エントレプレナーであり、大規模なソフトウェアおよびインフラストラクチャ・カンパニーを構築してきました。アイルランド・ダブリンを拠点として、現在はJenticを率いる傍ら、アイルランドのAIアドバイザリーカウンシルにも参加し、政府に対して人工知能政策に関するアドバイスを提供しています。彼のキャリアの初期には、メジャー・ビデオゲーム・パブリッシャーのための高スケール・オンライン・サービス・プラットフォームであるDemonWareを共同創設し、後にアクティビジョン・ブリザード(ATVI )に買収されました。また、Ad-blocking analyticsに焦点を当てたベンチャー・バックド・スタートアップであるPageFairも創設し、Blockthroughに買収されました。彼は複数のスタートアップを創設または率いてきましたが、アイルランドのスタートアップ・エコシステムをサポートする取り組みであるTechpreneursを通じて、アイルランドのスタートアップ・エコシステムを支援しています。

Jenticは、エンタープライズ・システムおよびAPIと安全にやり取りするためのユニバーサル・インテグレーション・レイヤーを開発しています。プラットフォームは、企業がAIモデルを内部ツール、外部サービス、および運用ワークフローと接続できるようにすることで、ガバナンス、認証、およびオーバーサイトを維持しながら、APIを構造化されたインターフェイスに変換します。Jenticは、エンタープライズが複雑なソフトウェア環境全体でAI駆動の自動化を大規模に展開することを支援することを目指しています。

あなたは、DemonWare（アクティビジョン・ブリザードに買収された）からPageFair、そして現在のJenticまで、複数のテクノロジー・カンパニーを創設し、率いてきました。また、アイルランドのAIアドバイザリーカウンシルにも参加しています。Jenticを創設する際に、インフラストラクチャ・レイヤーに戻ることを決めた理由と、他の人が見逃していたエージェント・エコシステムのギャップについて教えてください。

3回目にパターンに気付いたとき、それを真剣に考える必要があります。DemonWareでは、オンライン・マルチプレイヤーについて話されていましたが、ネットワーク・インフラストラクチャーの下に問題がありました。同じことがAIエージェントでも起こっています。モデルはすごいですが、ボトルネックはインテグレーション・レイヤーです。AIエージェントはAPIで動作し、APIは人間のために作成され、人間のためにドキュメント化され、人間のためにセキュア化され、人間のために構造化されています。自律エージェントをそのインフラストラクチャに指向すると、すぐに壊れてしまいます。エンタープライズAIパイロットは、モデルがタスクを誤解したことではなく、エージェントがシステムに接続できないことにより失敗します。ジェネレーティブAIは、インテグレーションをコーディングの問題ではなく、知識の問題として扱うことで、この問題を解決する新しい方法を提供します。その洞察が私を引き付けました。

2024年にJenticを創設したとき、エージェント・セキュリティが最初から主なテーマでしたか、または組織が実際に生産環境で自律エージェントを展開しているのを見て、焦点が絞られましたか。

最初に引いた糸は資格情報でした。エージェントが増え、それぞれが数十のシステムの資格情報が必要で、すべての秘密がLLMコンテキスト・ウィンドウに流れ込み、漏洩する – ひどい混乱です。答えは20年前に同じでした。認証と承認を集中化します。しかし、その糸を引くと、次の問題に直面しました。従来の統合ツールを使用して集中化すると、静的なコネクタに戻ってしまい、エージェントは静的ではありません。ビジョンを固めたのは、機能の発見がアクセス制御と密接に結びついている必要があることを認識したことです。エージェントは、実際に使用する権限がある場合にのみ機能を提供されるべきであり、機能を提供するシステムは、単一の施行および観測のポイントになるべきです。

最近、多くのインターネットに面するエージェント・インスタンスが公開され、オーケストレーションと資格情報が同じ信頼境界を共有していることが強調されました。モデルから見ると、そのアーキテクチャの欠陥は何ですか。

欠陥は単純です。エージェント（LLMのプロンプトを実行するシステム）も資格情報を保持し、API呼び出しを行うシステムです。エージェントを妥協すると、すべてのことが可能になります。それは、早期のWeb時代に犯した同じミスです。アプリケーション・サーバーがスーパーユーザー・データベース・アクセスを持っているのは、便利だからです。Jenticは、エージェントとAPIを呼び出す間にレイヤーを配置します。エージェントは資格情報を保持しません。マネージド・エグゼキューション・レイヤーを介して要求を発行し、資格情報をサーバー側で挿入し、ポリシーを施行し、すべての呼び出しをログに記録します。何かが間違ったときに、単一のキル・スイッチがあります – 1つのアクションで、エージェントのアクセスをすべての接続されたシステムで同時に停止します。

オーケストレーションとエグゼキューションの分離について話しました。実用的には、インスタンスが妥協された場合に、リスク・プロファイルがどのように変化するか説明してください。

フラットなモデルでは、LLMは何をするかを推論し、資格情報を使用して直接APIを呼び出します。推論レイヤーを妥協すると、エグゼキューション・レイヤーを制御できます。分離すると、LLMは意図（「ストライプの請求APIをこれらのパラメータで呼び出します」）を発行し、マネージド・エグゼキューション・レイヤーは、要求をポリシーに対して検証し、資格情報をサーバー側で挿入し、呼び出しを行います。LLMは資格情報に触れません。実践では、横方向の移動が難しくなり、爆発半径は、エグゼキューション・レイヤーが特定のエージェント・アイデンティティに対して許可するものによって制限され、キル・スイッチが得られます。1つのトグルで、エージェントのアクセスがすべての接続されたシステムで停止します。エージェントはまだ操作できますが、操作は自動的に資格情報の妥協を意味しなくなります。

実際のエンタープライズ・デプロイメントでは、集中化された資格情報管理と即時の取り消しがどのように見えますか。また、それは現在のチームがエージェントのAPIキーとトークンを扱っている方法とどのように異なりますか。

現在、ほとんどのチームは、開発者がAPIキーをプロビジョニングし、.envファイルに保存し、エージェントの起動時にロードする方法を使用しています。誰もが、どのエージェントがどの資格情報を持っているかという完全な絵を見ていません。誰かが去ったとき、プロビジョニングされたキーは回転しません。エージェントが奇妙に動作したとき、調査するための監査トレイルはありません。Jenticでは、開発者は生の資格情報を扱いません。エージェントが必要なアクセスを宣言し、プラットフォームはスコープ付きのアクセスをプロビジョニングし、エージェントはマネージド・エグゼキューション・レイヤーを介して呼び出しを行います。資格情報を見えません。つまり、エージェントごとの即時の取り消し、調査中にアクセスを一時停止する機能、およびタイムスタンプ付きのAPI呼び出しの監査トレイルが得られます。.envファイル内の「APIキー」という違いは大きいです。

多くのチームが、セールス、エンジニアリング、データ・サイエンスの分野でエージェント・フレームワークを実験しています。エージェントを安全に展開するために、組織が採用すべき最も一般的なセキュリティ原則について教えてください。

同じパターンが繰り返されます。プロトタイプ時に管理者資格情報で動作していた過剰に権限を持つエージェント。プロンプトまたはコンテキスト・ウィンドウで資格情報が渡され、ログ、テレメトリ、潜在的にトレーニング・データに表示される。複数のエージェント・インスタンスで共有される資格情報。エージェントを停止するキル・スイッチがない。価値のある監査トレイルがない。プロンプト・インジェクションが真剣に受け止められていない。エージェントがメールを読んだり、ドキュメントを処理したり、Webを閲覧したりする場合、敵対的なコンテンツに遭遇するからです。これらのチームは幸せな道を構築しましたが、今、生産では幸せな道がほとんどないことを発見しています。

Jenticは、エージェント・フレームワークと外部システムの間に配置されるマネージド・エグゼキューション・レイヤーです。開発者やエージェントの柔軟性を損なうことなく、ガバナンスをどのように施行しますか。

エージェントを50の異なるAPIに接続するのではなく、開発者は1つのエンドポイントに接続します。そのエンドポイントは、APIの機能を検索するツール、詳細を読み込むツール、および呼び出しを行うツールを公開します。これにより、単一の統一されたAPIへのインターフェイスを通じて、最大の柔軟性が実現しますが、ガバナンスも可能になります。どのエージェントがどのAPIにアクセスできるか、どのような条件で、どのような制限で、すべてがプラットフォームで管理され、クライアント・コードでは管理されません。エグゼキューション・レイヤーはパス・スルーです。エージェントは依然としてマルチ・ステップのワークフローを構成し、呼び出しを連結し、エラーを動的に処理できます。摩擦のないガバナンスは難しいです。ショートカットは、負担を開発者に押し付けることです。インフラストラクチャはその逆を吸収するべきです。開発者がそれに直面しないように、複雑さを吸収するべきです。

インフォ・スティーラー・マルウェアが現在エージェントの構成ファイルと保存された資格情報をターゲットにしている場合、攻撃者がAIインフラストラクチャに注目する新しい高価値のサーフェス・エリアにシフトすることを予想しますか。

絶対にそうです。論理は明らかです。エージェントの構成ファイルは、実質的にマルチ・サービス・スーパーキーです。電子メール・システム、CRM、請求プラットフォーム、内部API、およびGitHubアカウントの資格情報。1つのインフォ・スティーラー・ランが成功すると、会社の外部システム全体にわたる数ヶ月間のアクセスが得られます。それは、個別のサービスをターゲットにするよりもはるかに高いリターンです。他の次元は、生産環境で継続的に実行されているエージェントは、資格情報付きの恒久的な存在です。ユーザーがログインしてログアウトするのではなく、長期的な足掛けとして機能できます。攻撃サーフェスは、防御ツールよりも速く進化しています。Jenticは資格情報の攻撃サーフェスを大幅に削減できますが、エージェントが付与されたスコープを誤用するのを防ぐことはできません。そのより難しい問題は、モデル・レベルで解決する必要があり、ガードレールとプロンプト・インジェクション検出が必要です。

単一のフレームワークを超えて、エージェント・AIを安全に大規模に展開するために、組織が採用すべきより広範なセキュリティ原則について教えてください。

ほとんどの管理された組織は、非決定的なシステムを最も貴重なビジネス・プロセスに展開できません。銀行や保険会社は、請求システムに自律エージェントを指向し、「それを理解してください」と言うことはできません。イノベーションをどのように実現しますか。リスクの姿勢がブレーキになることなく。答えはサンドボックス化です。生産資格情報や結果がない同じ構造とワークフローを持つAPI・エステートのデジタル・ツインを作成します。エージェントをそこに展開し、発生することを観察します。成功したパスは、Arazzoを使用した構造化された決定的なワークフロー・オートメーションとしてキャプチャされます。Arazzoは、OpenAPIイニシアチブ内で開発されたオープン・ワークフロー・仕様です。監査可能、繰り返し可能、および任意のコンプライアンス・チームによってレビュー可能です。これにより、サンドボックスでAIの速度で移動し、エンタープライズの速度で生産環境で移動できます。両方のモードは共存します。他の原則も適用されます。最小権限、監査トレイル、キル・スイッチ、オーケストレーションとエグゼキューションの分離。しかし、サンドボックスは、エンタープライズ・チームが実際に詰まる質問への構造的な答えです。非決定的なAIを使用してイノベーションをどのように行うか。コンプライアンスの姿勢をベットしないで。非決定性を展開しない。制御された条件下で価値を抽出し、決定的な出力をのみ展開します。

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