Permit.io、AI agentのtool callをaction-time authorizationで制御する設計

問題を「誰が何をできるか」に戻す

Permit.ioの創業チームは、アプリケーションの認証後に残るauthorizationの複雑さを、開発者が再利用できるplatformへ切り出した。

Or Weisは公式サイトで「Agents are not users. They are attack magnets」と説明し、AI agentでは従来のstatic roleだけでは不十分だと示している。出典

Policyを開発者のworkflowへ

RBACだけでなくABAC、ReBAC、PBACを扱えるpolicy layerを、SDK、Terraform、GitOps、PDPへ展開した。

CLI発表ではpolicyをterminalから定義・test・deploy・enforceする流れを提示し、security設定を開発者の通常工程へ寄せた。出典

AI agent時代の転換

2026年にはMCP Gatewayを発表し、既存MCP serverを書き換えずにhuman identity、agent identity、consent、auditをtool callへ適用する設計を前面に出した。出典

これは認証を一度通すのではなく、各actionの文脈で判断する方向への転換である。

複雑なpermissionを自前実装する開発チームに、policy modelingとenforcementを外部化する選択肢を提供する。

公式docsはRBAC・ABAC・ReBACを横断し、MCP Gatewayではhuman/agent identityとtool call単位の認可を扱う。出典

規制産業やmulti-tenant SaaSほど、権限変更の監査可能性が痛点になる。

policy model、PDP、監査ログ、GitOps、MCP gatewayを一体で運用する実装知識と、既存アプリへ組み込むintegration面が蓄積される。

単なるpermission APIより移行コストが高い。

強いnetwork effectではない。

authorizationは顧客ごとの閉じたデータだが、SDK・docs・OSS ecosystemが導入事例と実装パターンを増やす間接効果はある。

multi-tenant SaaS、fintech、healthcare、enterprise platformのbackend・security・IAM担当。

特にユーザー、tenant、resource、agentの関係を細かく制御したいチーム。

RBACだけでなくABAC・ReBAC・PBACを同じplatformで扱い、SDK・Terraform・GitOps・管理UIを揃えた点が導入障壁を下げる。出典

既存MCP serverを変更せずgateway URLだけで接続できる設計も、AI導入時の摩擦を抑える。出典

authorization modelは組織固有で、初期のpolicy設計とresource mappingに学習コストがある。

無料枠からenterprise運用へ進むほど、MAU・tenant・環境数など料金と運用制約の確認が必要になる。出典

開発者向けdocs・CLI・OSSでself-serve導入を作り、Startup/Pro/Enterpriseへ拡張する。

MCP GatewayではAI agent governanceという新しい予算領域へ広げる一方、security製品として信頼と監査を優先する必要がある。

主要チャネル: content, developerCommunity, docs, caseStudies, enterpriseSales

authorizationを後付けのif文ではなく、policy model・decision point・auditの独立したcontrol planeとして扱うと、製品機能とsecurity運用を分離できる。

MCPではsession認証だけでなくaction単位の認可が必要になる。

日本のSaaSではtenant境界、代理操作、個人情報アクセスの説明責任が重い。

Permit.io型のpolicy-as-codeと監査を、社内承認フローや地域データ要件と接続すると価値が出る。

ただし日本語docsと導入支援は要強化。