AI AgentがMCPやA2Aを通じて外部システムを操作するケースが増えています。
しかし、AI AgentからAPIを呼び出せるようにするだけで、安全なシステムになるわけではありません。
この記事では、Railsアプリケーションを例に、AI Agentに必要な認証・認可・代理権限の考え方を整理します。
1. AI Agent特有のセキュリティリスク
従来のWebアプリケーションでは、ユーザーが画面上で操作を実行することが一般的でした。
AI Agentの場合、ユーザーに代わってAgentが操作を実行します。
例えば、以下のような構成です。
User
|
| 購入を依頼
v
AI Agent
|
| MCP / A2A
v
Rails Application
|
| purchase_product
v
Database / 外部決済API
この構成には、いくつかのリスクがあります。
| リスク | 例 |
|---|---|
| 権限の過剰付与 | Agentが本来不要な削除APIまで使える |
| 不正な操作指示 | 外部文書のPrompt Injectionで操作が変わる |
| 代理権限の不備 | ユーザーが許可していない購入を実行する |
| 情報漏洩 | Agentが取得した秘密情報を外部へ送る |
| 操作の追跡不足 | 誰の代理で操作したのか分からない |
OWASPの「Top 10 for Agentic Applications 2026」でも、こうしたAgent特有のリスクが扱われています。
2. 認証と認可は別の問題
まず、次の2つを区別する必要があります。
Authentication（認証）
「誰がアクセスしているのか？」を確認すること。
Authorization（認可）
「その相手は何を実行してよいのか？」を判断すること。
例えば、MCP ServerがBearer Tokenを検証できたとします。
Agent
|
| Authorization: Bearer ...
v
MCP Server
|
| Token検証 OK
v
Authenticated
しかし、これだけでは購入操作を許可してよいとは限りません。
追加で確認すべきことがあります。
このAgentは誰の代理か？
購入操作を委任されているか？
購入金額は許可範囲内か？
委任の有効期限は切れていないか？
委任は取り消されていないか？
人間による承認が必要か？
つまり、接続できる権限と、業務操作を実行できる権限は分ける必要があります。
3. MCPとA2Aのセキュリティ責務
MCPとA2Aには、それぞれセキュリティの仕様があります。
MCPの2026-07-28仕様では、OAuth関連の認可フローの安全性を強化する変更が導入されています。
A2A v1.0でも、認証方式の通知、TLSの利用、各操作に対する認可チェックなどが規定されています。
ただし、これらがあるからといって、アプリケーション独自の業務ルールまで自動で判定されるわけではありません。
Rails側では、次のような責務分担が必要になります。
| レイヤー | 主な役割 |
|---|---|
| MCP / A2A | 通信・能力公開・プロトコル上の認証情報 |
| Rails Host | 呼び出し元の認証・本人特定 |
| Delegated Authorization | Agentの代理権限・制約の判定 |
| Business Logic | 業務処理・整合性・実行制御 |
| Audit / Monitoring | 記録・監視・追跡 |
特に、業務処理を実行する直前の認可が重要です。
4. Railsで代理認可を実装する例
代理認可の例として、OSS Gem ActingForを使ってみます。
ActingForは、AgentがPrincipal（本人）の代理として操作できるかを判定するRails向けGemです。
例えば、ユーザーがShopping Agentに対して、1万円以内の購入を許可するケースです。
委任を登録する
ActingFor.delegate(
agent: shopping_agent,
principal: user,
action: :purchase,
resource: Product,
constraints: [
{
field: "amount",
operator: "lte",
value: 10_000
}
],
effect: :allow
)
これにより、購入金額が1万円以下という制約を持つDelegationを登録します。
購入前に認可を判定する
decision = ActingFor.authorize(
agent: shopping_agent,
principal: user,
action: :purchase,
resource: product,
context: {
amount: product.price
}
)
decision.status
# => :allow / :deny / :require_approval
ここで重要なのは、amountにAgentが申告した値をそのまま使わないことです。
例えば、リクエストで渡された金額を信用すると、実際の商品価格と異なる金額で認可判定してしまう可能性があります。
そのため、上記の例ではRails側で取得したproduct.priceを使用しています。
また、agentとuserも、認証済みの呼び出し元情報や信頼できる委任関係から確定する必要があります。
リクエストのuser_idを無条件に信用してはいけません。
判定結果に応じて処理する
概念的には次のようになります。
case decision.status
when :allow
# 業務処理を実行
when :require_approval
# 実行せず、人間の承認フローへ
when :deny
# 実行を拒否
end
※上記は処理分岐を説明するコードです。実際の購入処理では、別途トランザクション、冪等性、価格の再検証、競合対策、決済APIの安全性なども必要です。
また、ActingForはAgentの認証や業務処理の実行、人間の承認フローそのものを提供するものではありません。それらはRails Hostの責務です。
5. A2Aで外部Agentを利用する場合
A2Aで外部Agentと連携する場合も、同様の考え方が必要になります。
External A2A Agent
|
| A2A Request
v
Rails A2A Endpoint
|
| 認証・呼び出し元特定
v
Business Authorization
|
| 許可された操作のみ
v
Rails Business Logic
外部AgentにTaskの参照権限があっても、商品購入の権限があるとは限りません。
また、Agent Cardに記載された能力だけを根拠に、相手Agentを無条件で信頼することも避けるべきです。
私が開発しているa2a-railsでも、通信プロトコルの実装とアプリケーション側の認可責務を分離することを重視しています。
なお、公開Gem a2a-rails v0.2.0が提供するセキュリティ機能だけでは、公開インターネット環境への安全なデプロイは保証されません。実際の運用にはHost側の認証設定や追加のセキュリティ対策が必要です。
6. 本番運用前に確認したいチェック項目
AI Agentに業務操作を実行させる場合、少なくとも次の点を確認したいと考えています。
- AgentのIdentityを信頼できる方法で検証している
- ユーザーとAgentの委任関係を確認している
- 操作ごとに権限を判定している
- 金額や対象リソースなどの条件を検証している
- 危険な操作では人間の承認を要求している
- Taskやデータへのアクセスをユーザー・テナントごとに制限している
- Prompt Injectionや外部Toolの悪用への対策を行っている
- 実行ログと認可判断の監査記録を残している
- リトライ・重複実行・タイムアウト・API利用上限に対応している
これらは基本的な確認項目であり、すべてを満たせば安全性が保証されるという意味ではありません。
7. まとめ
MCPやA2Aによって、AI Agentが外部システムと連携しやすくなっています。
しかし、AI AgentにAPIを公開することと、安全に操作させることは別問題です。
重要なのは、
- 誰が操作しているのか（Authentication）
- 何をしてよいのか（Authorization）
- 誰の代理として実行するのか（Delegation）
- なぜ許可・拒否されたのか（Audit）
を明確にすることです。
AI Agentの能力が高まるほど、実行権限の適切な制御が重要になっていくと思います。
Railsでも、既存の認証・認可設計を土台にしながら、Agent特有の代理実行に対応する仕組みを考えていく必要がありそうです。