API ManagementをAgent ツール層に置く

Agentからtool APIへ到達する経路にAPI Management/API Gatewayを置くと、認証、公開route/tool、rate/quota、protocol/schema、監査を集中しやすくなります。

ただしgatewayを通過したことだけを、tool actionの安全性、backend authorization、hard cost capの証明にはしません。

gatewayでcaller/workload identityを検証し、backendでも実行可能なaction/resourceを最小権限にします。

API keyは必ずしもauthentication/authorization credentialではありません。project identificationやusage-plan用途とauthorizationを分離します。

gateway authenticationとbackend/tool authorizationの双方を通過しなければside effectを許可しない構成を採ります。

Agentへ公開するroute/toolをinventoryし、必要なoperationだけを明示的に公開します。

wildcard route、汎用proxy、過剰なMCP tool exposureを避け、tool追加・schema変更をpolicy changeとして扱います。

schema-valid requestであってもbusiness-safe actionとは限らないため、resource/action authorizationとapproval gateを別途維持します。

rate limit、burst、quota、concurrencyをretry amplificationとnoisy-neighbor対策に使用します。

ただしproviderのquota/throttlingがbest effortの場合、hard cost capとして扱いません。AWS API Gatewayはusage-plan quota/throttlingをhard limitやcost-controlとして依存しないよう明記しています。

budget alert、provider spending control、backend quota等は別controlとして確認します。

MCP trafficはgateway製品ごとの対応範囲を固定します。

Azure API ManagementはMCP toolsを管理できますが、現行documented scopeではMCP resources/promptsをサポートしません。

Kong AI GatewayではMCP trafficにAPI-level authentication、rate limiting、logging等を適用できますが、LLM prompt/response向けAI policyはMCP trafficへ同じようには適用されません。

「AI gateway対応」を全MCP primitive・全policyへの対応と読み替えません。

HTTP request-responseだけでなく、SSE、WebSocket、gRPC、MCP revision、長時間connectionを個別に確認します。

payload/header size、timeout、connection lifetime、retry、transcodingの制約はprotocolごとに異なり得ます。

request count中心のrate policyが長時間streaming connectionを同じ粒度で制御するとは仮定しません。

backendへgatewayを経由しないdirect public/private pathが残る場合、gatewayは完全なenforcement pointではありません。

DNS、private endpoint、service mesh、security group/firewall等を含め、Agent runtimeからbackend direct accessをnegative-testします。

break-glass bypassを設ける場合はowner、理由、expiry、監査を必須にします。

OpenAPI/gRPC/MCP tool definitionとgateway policyをversion管理し、active config間の互換性を確認します。

quota metric、route、auth、backend mappingの変更はavailability/security双方のchangeとして扱います。

config deploy成功だけでなく、realized route/auth/quota stateをreadbackします。

少なくともcaller identity、tool/route、status、latency、auth decision、rate/quota decision、backend errorを観測します。

Authorization header、API key、token、prompt、tool arguments、PIIはログからredactします。

direct-backend access、401/403/429増加、wildcard route追加、policy driftを監視します。

Agent runtimeから次を検証します。 - 許可されたtool/routeへのpositive test - 未許可tool/routeへのnegative test - direct backend pathへのnegative test - expired/revoked identity - rate/burst/quota超過 - backend action authorization denial - schema-invalid request - oversized request/header - streaming/WebSocket/gRPC/MCP経路 - policy/config readback - failover regionでのpolicy一致

許可経路の成功だけでgateway controlを検証完了としません。

direct bypass、wildcard exposure、stale JWT/JWKS、API keyとauthの混同、best-effort quota overshoot、retry storm、streaming/WebSocket差異、gRPC transcoding mismatch、MCP revision mismatch、resources/prompts非対応、LLM policyのMCP非適用、schema drift、config rollout incompatibility、backend credential overreach、auth-context mapping error、secret-bearing logs、gateway outage、multi-region drift、break-glass残置を想定します。

本項は2026-10-06時点のAzure API Management MCP/AI gateway、AWS API Gateway、Google Cloud API Gateway、Kong AI Gateway公開資料に基づきます。organization gateway、Agent runtime、MCP server、backend APIへのlive mutation/testは未実施です。

API ManagementをAgent Tool層の制御点に置く場合、認証、公開tool/route、rate/quota、protocol/schema、監査をgatewayで集中できます。ただしAPI keyやquotaをauthorization・hard cost capとみなさず、backend側の最小権限とdirect-path遮断を別途確認します。MCP/streaming等はgateway製品・versionごとの対応範囲を固定し、許可経路の成功と未許可経路の拒否をAgent runtimeからreadbackします。

organization gateway/provider/tier、actual Agent tools/MCP revision、direct backend paths、backend IAM/OAuth、hard-budget mechanism、quota scope、streaming/WebSocket/gRPC、schema lifecycle、multi-region failover、JWKS/revocation SLO、logging/redaction、pricing、tenant-specific policy behaviorは未確認です。