AWS と LiteLLM で実現する、セキュアで柔軟な AI エージェント基盤のアーキテクチャ

AI エージェントの導入にあたり、私たちはプロキシ基盤に大きく 3 つの要件を設定しました。

• セキュリティとガバナンス : 開発者がツールを安全に利用できるよう、意図しない情報流出を防ぎ、誰がどのように利用しているかを把握できること。
• オブザーバビリティ : 単なるコスト監視に留まらず、利用動向を詳細に分析し、開発組織全体の生産性向上に繋げるためのインサイトを得られること。
• プロバイダーの柔軟な選択肢 : 特定の LLM プロバイダーだけでなく、将来にわたって用途に応じた最適なモデルを迅速かつ容易に使い分けられる拡張性を持つこと。

これらの要件を満たすため、私たちはオープンソースの LiteLLM と AWS の各種サービスを組み合わせたアーキテクチャを設計しました。

クライアントからのリクエストは、まずAWS WAFによるセキュリティチェックを経たのち、Application Load Balancer へと到達します。その後、リクエストは Amazon EKS クラスター上で稼働するプロキシーアプリケーションに転送されます。このアプリケーションで認証やガードレール、コンテキスト識別といった処理が行われ、最終的に LiteLLM を通じて Amazon Bedrock などの LLM プロバイダーへとルーティングされます。LLM プロバイダーには様々なサービスがありますが、Amazon Bedrock となった決め手は、利用できるモデルの数やデータ利用ポリシーの明快さでした。

セキュリティとガバナンスを徹底するため、私たちはプロキシのアプリケーションレイヤーに多層的なガードレールを実装しました。

• 監査ログ : ガバナンスとトレーサビリティの担保のために、プロキシへの入出力をすべてロギングします。すべての入出力の監査ログは Amazon S3 に記録されます。
  
• 入力ガードレール: ユーザーからのプロンプトに、意図せず AWS のアクセスキーや個人情報などの機微な情報が含まれていないかを正規表現でチェックし、該当した場合は自動でマスキング処理を施します。これにより、機密情報が LLM プロバイダーに送信されるリスクを低減します。
  
• 出力ガードレール : LLM からの応答も同様にチェックします。特に AI エージェントが生成する実行コマンドを多角的に検査します。まず、正規表現を用いて sudo や chmod といった権限昇格に繋がるコマンドや、curl wget による意図しない外部通信など、危険と想定されるコマンドパターンを静的に検出します。さらに、それだけでは判断が難しいコマンドについては、別の LLM にそのコマンドのリスク評価を問い合わせます。 LLM がリスクレベルを「高」と判定したコマンドは実行をブロックすることで、静的チェックをすり抜けるような未知の脅威にも対応できる仕組みを構築しています。
  

私たちのプロキシは、単にリクエストを中継するだけではありません。すべてのリクエストに対して「誰が、どのツールから、何のために」使っているかを識別し、そのコンテキスト情報をログや制御に活用しています。