6月25日、Patrick Farryが「Grab Builds Secure Agentic AI Workload Platform」と題した記事を公開した。東南アジア全域で配車・フードデリバリー・金融サービスを展開し、数億人規模のユーザーベースを持つスーパーアプリGrabが、自社開発したKubernetesネイティブのAIエージェント実行基盤「Palana」の設計と仕組みを詳しく紹介した内容だ。
「エージェントAIは信用できない」という前提から設計する
大規模な本番トラフィックを日常的に処理するGrabにとって、AIエージェントを既存インフラに組み込む際のセキュリティリスクは切実な課題だ。ツールを自律的に実行し、APIを呼び出し、コードを読み書きするエージェントは、プロンプトインジェクション、ロジックハイジャック、依存関係への侵害、過度な目標追求、ハルシネーションといった脅威に対して本質的に脆弱である。
Grabはエージェントフレームワーク「Claw」のプロトタイプを構築する中で、個別に手動で環境を用意する方式では限界があると判断し、インフラレベルでの体系的な対策としてPalanaを開発した。設計の根底にあるのは「エージェント自体を信頼しない」というゼロトラスト的な発想であり、この考え方は近年のクラウドセキュリティ業界全体で加速しているゼロトラストアーキテクチャの潮流とも合致している。
※編集部の考察：類似のアプローチとして、LangChainのエージェント実行環境やWeaviate等のOSSエコシステムでもエージェントの権限分離は議論されているが、Kubernetesオペレーターレベルでここまで体系化した事例は現時点で希少といえる。
Palanaの核心：「秘密情報をエージェントに渡さない」設計
Palanaの設計思想の中で最も注目すべきが、シークレット管理の完全な分離だ。
従来のアプリケーションでは、APIキーや認証情報を環境変数やマウントされたファイル経由でコンテナに渡すことが一般的だった。しかし自律型エージェントの場合、侵害されたランタイムが高価値なAPIキーを外部スクリプトに漏洩させるリスクがある。
Palanaはこの問題を以下の仕組みで解決している：
- エージェントコンテナにはダミーのプレースホルダートークンのみを渡す
- バージョン管理システムのPATやモデルゲートウェイのAPIキーなど、高感度の認証情報は**HashiCorp Vault**に保管する
- エージェントが外部APIを呼び出すと、中間に配置されたセキュアプロキシがリクエストを横取りし、宛先を検証したうえで本物のシークレットに動的に置換してから送信する
この仕組みにより、生のシークレットはエージェントコンテナの環境変数にも実行メモリにもログファイルにも一切書き込まれない。エージェントが侵害されても、シークレットは漏洩しない。
全アウトバウンド通信をEnvoy + OPAで検査する
エグレス（外向き通信）の経路は集中型のセキュリティ制御ポイントとして設計されている。すべてのHTTP/HTTPS通信は**Envoyプロキシを経由し、Open Policy Agent（OPA）**のルールを実装した外部認可サービスによって評価される。
プロキシはMan-in-the-Middleによる証明書終端を使ってトラフィックをリアルタイムで復号し、ヘッダーの評価、エンドポイントの検証、トークン置換を実施しながら、構造化された監査ログを生成する。EnvoyとOPAはともにCloud Native Computing Foundation（CNCF）のプロジェクトであり、本番規模での採用実績が豊富な点も選定理由として自然だ。
さらに、侵害されたエージェント自身に自己終了を期待することはできないという前提から、ネットワークレベルのキルスイッチはコントロールプレーンから直接ネットワークポリシーを無効化する設計になっている。アイドル状態のエージェントのシャットダウンも、エージェントコードを一切変更しない独立した外部リーパー（reaper）が担う。
Kubernetesネイティブで運用スケールを実現
Palanaの各エージェントはカスタムリソースとしてモデル化され、カスタムKubernetesオペレーターによってリコンサイルされる。オペレーターはネームスペース、ストレージ、ネットワークポリシー、イングレスパスを動的にプロビジョニングする。
各エージェントには専用のKubernetesネームスペースが割り当てられ、制限的なRBAC設定、カスタムネットワークポリシー、分離されたサービスアカウントが構成される。長時間稼働する非同期ワークフロー向けに、コンテナ再起動をまたいで状態とメモリを保持するための永続ローカルストレージも提供される。
開発者向けにはシンプルなUIとCLIツール、システムエンジニア向けには標準的なKubernetesレイヤーという形で運用体験が分離されており、プラットフォームチームは本番クラスター上で数百の並行エージェントワークロードのライフサイクルをInfrastructure as Codeの実践で管理できる。Kubernetesをエージェント実行環境として活用するこのアプローチは、既存のクラスター管理・監視・スケーリングのノウハウをそのまま転用できるという点で、運用組織への導入コストを抑えやすい。
まとめ
Palanaの設計が示すのは、「エージェントAIはアプリケーションレベルで制御するのではなく、インフラレベルで隔離する」というアプローチだ。ゼロトラストモデルを採用し、シークレットの分離、通信の完全な可視化、外部からのライフサイクル制御を組み合わせることで、エージェントが侵害されても被害が隣接ワークロードに波及しない設計を実現している。AIエージェントの本番運用を検討するエンジニアリング組織にとって、インフラ設計の参照事例として価値の高いケーススタディといえる。
詳細はGrab Builds Secure Agentic AI Workload Platformを参照していただきたい。
