本番環境でエージェント向けきめ細かな認可を実装！Palletが直面した課題と解決策

皆さん、こんにちは。本日は、Palletの創設プロダクトエンジニアであるTiffany Lozenskiが、本番環境でエージェント向けにきめ細かな認可（Fine-Grained Authorization, FGA）を実装する中で得た教訓についてご紹介します。本記事では理論ではなく、実際に発生したエラーや直面した課題、そしてそれらをどのように解決したのか、具体的な経験に基づいて解説します。

Palletとは？

Palletは、エンジニアではないユーザー向けにAIコンテキストを構築するプラットフォームです。Gitやターミナルの知識がなくても利用できるPalletデスクトップアプリケーションを提供しており、UTM Ops、ファウンダーなど、コードベースに直接関わらない人々を主なターゲットとしています。内部ではMRAAが動作しており、Cloud Code、CodeX、Gemini、またはローカルモデルを選択して利用できます。また、Palletデスクトップアプリケーションと統合されたコンテキストレイヤーは、MCPサーバー経由でもアクセス可能です。

このようなマルチプレイヤーエージェント環境において、お客様のデータを安全に保ち、信頼を築く上で認可（Authorization）は非常に重要な要素です。お客様からは、データセキュリティに関する詳細な問い合わせが常に寄せられています。

きめ細かな認可（FGA）とロールベースアクセス制御（RBAC）の違い

認可システムには、皆さんにも馴染みのあるロールベースアクセス制御（Role-Based Access Control, RBAC）と、きめ細かな認可（Fine-Grained Authorization, FGA）があります。

ロールベースアクセス制御（RBAC）

RBACは「このロールはこのアクションを実行できるか？」という問いに答えます。例えば、「アリスは管理者か？はい。であれば、アリスはこれらのチームに対して特定のアクションを実行できる」というように、ユーザーに割り当てられたロール（役割）に基づいてアクセス権を判断します。

きめ細かな認可（FGA）

一方、FGAは異なる問いを投げかけます。それは「このユーザーはこれを実行するために適切なパーミッション（権限）を持っているか？」というものです。FGAでは、パーミッションをロールの範囲内で定義することもできますが、より粒度の高い制御が可能です。例えば、「アリスはチームAの管理者か？」や「アリスはチームAのこのワークフローを管理するパーミッションを持っているか？」といった具体的な問いに答えることができます。

エージェントの世界に移行する際、FGAの重要性はさらに増します。なぜなら、単に異なる種類のユーザーに対して異なるパーミッションセットを持たせるだけでなく、エージェントが人間とは全く異なる、あるいは一対一の関係ではない独自のパーミッションセットを持つ必要がある場合があるからです。FGAは、この点でより高いカスタマイズ性を提供します。そのため、PalletではFGAに焦点を当てて実装を進めています。

PalletにおけるFGAの実装戦略

Palletでは、アプリケーションのあらゆる側面で単一のFGAモデルを使用しています。

REST API: 最初にFGAレイヤーを実装したREST APIにはWorkOSを使用しています。
エージェントレイヤーとMCPサーバー: 本記事の主要な焦点であるエージェントレイヤーとMCPサーバーにもFGAを実装しています。

リソースとパーミッションの設計

Palletでは、次の3つのリソースタイプを定義しています。

Organization（組織）
Team（チーム）
User（ユーザー）

現在は6つのロールがありますが、将来的にはエージェントロールを追加する予定です。また、23種類のパーミッションがあり、これらはリソースごとに名前空間化されています。

WorkOS FGAを使用することで、必要に応じてパーミッションの継承（inheritance）を可能にし、同時に不要な場合には継承をブロックすることもできます。例えば、組織の管理者がプライベートチームの全てのパーミッションを持つ必要がない場合は、そのように設定できます。

以前は組織のメンバーシップIDに基づいていましたが、エージェントの世界では全てがユーザーに基づいているわけではないため、このアプローチは進化しました。全てのパーミッションは非常にスコープが限定されており、グローバルなパーミッションは存在しません。これは、非常に機密性の高いデータを扱う上で重要な設計です。

テナント隔離（Tenant Isolation）による多層防御

FGAの上の第二の防御層として、テナント隔離を導入しています。PostgreSQLの行レベルセキュリティ（Row Level Security, RLS）を使用しており、もしエージェントが異なる組織のデータをクエリしようとした場合、空のセットが返されます。これは「フェイルクローズ」の原則に基づき、徹底した多層防御（Defense in Depth）戦略の一部となっています。

エージェントへのFGAの組み込み（MRAA FGA WorkOSフレームワーク）

Palletは今年、MRAAと密接に連携し、MRAA FGA WorkOSフレームワークを開発しました。このフレームワークを活用することで、エージェントへのFGAの組み込みが容易になります。

アプリケーション側のセットアップ

アプリケーション側でのMRAA FGA WorkOSのセットアップは以下のようになります。

リソースのマッピング:
- エージェント、ワークフロー、ツール: チームスコープに設定
- スレッド、メモリ: ユーザースコープに設定
これはアプリケーションの要件に合わせて完全にカスタマイズ可能です。
認可の自動化: 既存の認証（これもWorkOSを使用）とFGAを連携させることで、エージェントツールやメモリへの全ての呼び出しに対して、認可が自動的に適用されるようになります。

実際に遭遇した課題と解決策

FGAの実装中にPalletが直面した主要な課題と、その解決策を説明します。

課題1: FGAが人間をアクターとして想定していた問題 -> システムアクターアプローチ

当初、FGAは認可の主体（アクター）として人間を想定していました。しかし、Palletのシステムでは、必ずしも人間が操作するとは限りません。

具体的なユースケース：コンテキストページワークフロー

Palletには、毎週土曜日に実行されるcronジョブである「コンテキストページワークフロー」があります。これは、組織、チーム、メンバーに対してコンテキストを生成するものです。組織レベルやチームレベルでのコンテキスト生成には、特定の人間が関与しません。

このワークフロー内では、例えばNotionエージェントやSlackエージェントといった複数のエージェントが連携して動作します。これらのエージェントは、それぞれ異なるパーミッションを持つ必要があります。

解決策：システムアクターアプローチ

我々が採用したのは、システムアクターアプローチです。これは、アクターの種類を「システムアクター」として指定し、その元となるワークフローの名前を付与するものです。これにより、ワークフロー名に基づいてパーミッションをマッピングできるようになります。また、ワークフロー内の各エージェントに対しても、個別のパーミッションセットを設定することが可能です。

このアプローチは、認可のバイパスを防ぎ、システム全体での安全性を確保するために非常に重要です。たとえメンバーシップバイパス（特定のユースケースで必要と判断された場合）を導入したとしても、全ての操作は完全に監査され、どこから、どのワークフローが、なぜそのアクションを実行したのかを追跡できます。これにより、403エラーが発生した場合や、意図しない認可が行われた場合のデバッグが容易になります。

課題2: テナントガードの維持

FGAの設定が完璧でなかったとしても、テナント隔離の仕組みは常に有効にしておくことが極めて重要です。WorkOSのロールレベルセキュリティによるテナント隔離は、データが意図せず露出することを防ぎ、常に保護されている状態を維持します。

まとめ

本記事では、Palletが本番環境でAIエージェント向けにきめ細かな認可（FGA）を実装する際の具体的な経験と教訓について詳しく解説しました。RBACとの違い、PalletのFGA実装戦略、そしてシステムアクターアプローチやテナント隔離といった重要な解決策をご紹介しました。

FGAは、特にエージェントや自動化されたシステムが絡む複雑な環境において、より柔軟でセキュアな認可を実現するための強力なツールです。本記事が、皆さんのFGA導入やセキュリティ設計の一助となれば幸いです。

参考動画

What I learned shipping fine grain authorization for agents in production

ポイント