AIエージェントがコードを読み、APIを叩き、Slackに返信する時代になりました。一方で、ネットワーク・資格情報・ツール・記憶を持つエージェントは、チャット画面ではなく「自律的に動くワークロード」です。Grabはこのリスクに対し、Kubernetesネイティブの社内基盤「Palana」を構築し、数百のエージェントを運用しています。

本記事では、Palanaがどんな課題を解くのか、どんな仕組みで安全を担保するのかを整理します。

この記事でわかること

  • Palanaが生まれた背景と、Grabが狙う運用像
  • エージェント1体ごとの隔離や資格情報の扱い方
  • 外向き通信の監査、キルスイッチ、運用ツールの構成

https://engineering.grab.com/palana-part-1-secure-platform-for-ai-agents

AIエージェント運用で何が変わるか

これまでのAIコーディング支援は、IDEのプラグインやローカルPC上のCLIに近い形が主流でした。長時間動くエージェントには、再起動後も残る状態管理が必要です。チーム利用ではSlackやWeb UIからの共有アクセスが求められます。セキュリティ部門は、LLM・Git・HTTPの通信内容を後から追える仕組みを要します。

Grabのエンジニアリングブログは、こうした問いを挙げています。「社内でエージェントに有用な仕事をさせつつ、新しいエージェントごとにインフラを一から組む負担を避けるにはどうするか」。単にコンテナに載せるだけでは、代理ユーザー、資格情報の範囲、他ユーザーの状態へのアクセス、インターネット直結の可否、異常時の即時停止といった論点は解けません。

Palanaとは

Palanaは、Grabのサイバーセキュリティチームが開発した社内専用の実行基盤です。名前はサンスクリット語で保護や維持を意味する語根に由来し、エージェントの「頭脳」ではなく、動作を囲み、観測し、支える環境であると公式ブログは説明しています。

プラットフォームの主な構成は次のとおりです。

  • エージェント1体につきKubernetesの名前空間（namespace）を割り当て、RBAC（ロールベースアクセス制御）、リソース上限、ネットワークポリシー、ストレージを個別に設定
  • ポータルとCLIツール pcli による作成・停止・設定・監視
  • /data の永続ストレージで、記憶やリポジトリ、セッション状態を再起動後も保持
  • ブラウザやシェルからの対話型ワークロード（Claude Code UI、OpenCode、IDE、ttyd、SSH経由の開発環境など）
  • LiteLLMラッパー経由のLLMアクセス。GrabGPT用の資格情報はHashiCorp Vaultから注入
  • Envoyとext-authzプロキシを通るHTTP・HTTPSの外向き通信。Open Policy Agent（OPA）によるポリシー判定と構造化ログ
  • プロキシ専用シークレット。エージェントはプレースホルダのみ参照し、実トークンは直接保持しない
  • Git操作は踏み台経由で、誰の操作か追跡可能に
  • キルスイッチとアイドル時の自動停止

2026年6月時点で、リモート開発環境、Slack自動化、OpenClawワーカー、Hermesエージェントなど、数百のエージェントがこの基盤上で動いています。

なぜGrabはPalanaを作ったか

きっかけはセキュリティ研究でした。OpenClawなどのエージェントフレームワークを社内ネットワークに晒さず、生の資格情報もランタイムに置かずに検証する場が必要だったため、最初から封じ込めを前提に設計されています。

その後、リモートコーディングやSlack連携、長期実験、運用自動化など開発生産性の用途が広がりました。Grabのエンジニアは、数日から数週間コンテキストを保持し、社内インフラから動き、PCのスリープやローカル依存のずれに左右されないエージェントを求めていました。安全な経路が使いやすければ採用が進み、生産性の経路に監査とポリシーが最初から組み込まれていれば、後追いの統制が不要になる、という設計思想がブログに示されています。

安全設計の4つの柱

隔離を信頼の単位にする

各エージェントは専用の名前空間、サービスアカウント、ストレージ、ネットワークポリシー、Vaultスコープを持ちます。デフォルトでは他エージェントのPodやシークレット、ファイルには触れません。エージェント間通信は明示的なピアリング設定が必要で、単一ユーザー向けフレームワークでもユーザーごとにPalana境界を切ればマルチテナント運用が可能です。

資格情報はエージェントに渡さない

従来のアプリホスティングでは、環境変数やマウントファイルで資格情報をワークロードに渡すことが多いです。エージェントはツール実行、外部コード、パッケージ導入、Web UI公開まで行うため、この方式はリスクが高くなります。

Palanaはシークレットを2種類に分けます。エージェント読み取り可能なものは、そのエージェント専用のVaultパスに置き、対応するサービスアカウントだけが参照します。プロキシ専用シークレットは別パスに置き、プロキシ層だけが読み取ります。エージェントが見るのは TOKEN_GITHUB_PAT や TOKEN_GRABGPT_API_KEY のようなプレースホルダで、外向きリクエストがプロキシを通るときに実トークンへ置き換わります。リモート側は正しいトークンを受け取りますが、エージェントプロセス内には残りません。プロンプトインジェクションや依存パッケージの侵害で長期トークンが漏れる事態を抑える狙いです。

外向き通信を制御点にする

ツール連携のため通信は必要です。Palanaは通信を禁止するのではなく、観測可能でポリシー媒介型にします。エージェントPodにはプロキシ設定が自動注入され、外部HTTP・HTTPSはEnvoyを経由します。Envoyはext-authz-proxyに呼び出し元Podの特定、OPAによる許可判定、ログ記録、必要なら資格情報注入を依頼します。HTTPSはプロキシのMITM（中間者）リスナーで終端し、ヘッダ検査と置換を行い、生成したCA証明書をPodに配布します。どのエージェントが、どのユーザー所有で、どのホストへ、どのメソッドで、許可か拒否か、どのプレースホルダが置換されたか、社内サービスかLLMゲートウェイかGitLabか公衆インターネットか、といった問いに答えられる設計です。

制御プレーンはエージェントの外に置く

Palanaは、エージェントが混乱・侵害・非協力になった場合を前提にします。オペレーターが名前空間とポリシーを調整し、プロキシが外向き通信を制御し、ポータルと pcli がライフサイクルを管理します。キルスイッチはネットワークポリシーで経路を遮断し、アイドル停止は別のreaper CronJobが担います。エージェントに「止まって」と頼むのは機能であり、通信経路ごと切るのが安全装置、という位置づけです。

Kubernetesネイティブで運用する理由

エージェントはカスタムリソースとして表現され、オペレーターが名前空間、RBAC、ストレージ、サービス、Ingress、ネットワークポリシーを調整します。一般ユーザーは pcli やポータルから操作し、プラットフォームエンジニアはKubernetesオブジェクトを直接調べられます。インフラはコードで管理し、数百の同時エージェントをプログラム的に監査・更新できる点が、従来の手作り検証環境との違いです。

今後の公開予定と読み方

公式ブログはPart 1として背景と設計原則を公開済みで、Part 2ではライフサイクル管理、LLMルーティング、運用可視性の詳細を扱う予定としています。PalanaはGrab社内専用のプロプライエタリ製品で、一般向けの提供は示されていません。ただし、隔離単位の設計、プロキシ媒介のシークレット、外向き通信の監査、エージェント外のキルスイッチという構成は、自社でエージェント基盤を検討する際の実装参考になります。AIエージェントを本番に近い形で動かす組織は、モデル選定と並んで「どこまで自律させ、どこをインフラで縛るか」を先に決める必要があります。Grabの事例は、その境界をKubernetes上に落とし込んだ具体例と言えます。