エージェントポリシーの実施

Agent/LLMの判断だけに禁止操作・許可条件を委ねると、prompt injection、誤推論、context loss、tool schema misuseで統制が崩れる。AI判断の外側に決定論的policy decision/enforcementを置き、subject/actor、resource、action、contextを評価してtool/API実行前に止める構造はEnterprise AIの安全境界として重要。

Enterprise AI Core / security / governance / authorization / agent runtime / interoperability / implementation

• Agentの行動許可をLLM自身とは独立したPDP/PEPで決定する標準・実装基盤は2026-09時点で存在するか。
• Gateway/tool boundaryでdeterministic policyを強制できるか。
• policy engineが見られるcontextと、LLM内部意図/意味理解のギャップをどう扱うべきか。

• [VERIFIED_SPEC | support] OpenID Foundation AuthZEN, “Authorization API 1.0”, Final, published 2026-01-11; final approval announced 2026-01-12; accessed 2026-09-13. Canonical: https://openid.net/specs/authorization-api-1_0-final.html . Locator: Abstract / Model / evaluation endpoints. PDPが提供するAPIをPEPが呼び、内部実装を知らずにauthorization request/decisionを交換する標準境界を定義。
• [VERIFIED_SPEC | context] OpenID Foundation, “Authorization API 1.0 Final Specification Approved”, 2026-01-12. Canonical: https://openid.net/authorization-api-1-0-final-specification-approved/ . Locator: approval statement. Final Specificationであることを確認。
• [OSS_PRACTICE / PRODUCT_VOLATILE | support] Envoy AI Gateway releases, v0.5/v0.6 lineage, accessed 2026-09-13. Canonical: https://github.com/envoyproxy/ai-gateway/releases . Locator: MCP Gateway / fine-grained authorization. CEL rules、JWT claims/scopes、tool targeting、external gRPC/HTTP authorizationをMCP route policyへ組み込む実装。
• [OSS_PRACTICE / SOURCE_REPORT | counter] Envoy AI Gateway advisory GHSA-4gph-2hhr-5mwg, 2026-05-13. Canonical: https://github.com/envoyproxy/ai-gateway/security/advisories/GHSA-4gph-2hhr-5mwg . Locator: Description. parser differentialで多層security control bypassが起こり得るため、PEP実装の正しさ自体がtrust assumption。

• Agent Policy EnforcementのCoreは既存authorization architectureで構成可能。AuthZEN 1.0によりPDP↔PEPの標準API境界がFinal化されており、AI固有policy engineを発明する必要はない。[VERIFIED_SPEC]
• AI/Agent固有差分は「decision point」よりもenforcement contextにある。tool名、tool arguments、delegated user/agent identity、target resource、tenant、risk tier、budget、time、data classification等をPEPからPDPへ渡し、実行前にallow/denyを確定させる。[INFERENCE]
• Envoy AI GatewayのMCP policyは、CEL/JWT/tool target/external authを組み合わせ、Agent tool trafficに決定論的policyを挿入できる実装例。[OSS_PRACTICE]
• 「LLMにpolicy文を読ませる」ことと「policy enforcement」は区別すべき。前者はmodel behavior guidance、後者は外部の実行可否決定と強制である。[INFERENCE]

• AuthZENはauthorization API interoperabilityを規定するが、AI Agent固有のpolicy vocabulary、risk ontology、tool semantics、delegation modelまで標準化するものではない。
• PDPが正しくdenyしても、PEPを通らないside channel、alternate credential、direct provider/tool endpointがあればbypass可能。全実行経路のchoke-point化が前提。
• Policy inputがLLM生成metadataだけなら、誤ったsubject/resource/action分類を信頼してしまう。identity、resource、tool schema等はtrusted runtimeから構成する必要がある。
• Parser/translation layerの差異でpolicy対象と実際にbackendへ届くmessageがずれるとTOCTOU/semantic mismatch型のbypass面になる。Envoy advisoryはこの種の実装リスクを裏づける。
• 高度な「意図」や自然言語意味の判定を決定論的policyだけで完全に閉じることはできない。semantic classifier/LLM guardは補助信号であり、hard authorizationと混同しない。

• AuthZEN 1.0はFinal specification。ただしPDP製品/PEP統合ごとのsupport/conformanceは別確認。
• Agent/MCP gatewayのfine-grained enforcementは製品・version固有。公開時はEnvoy等のsupported versionとpolicy featureを再確認。

• 標準Core: PEP（agent runtime/gateway/tool proxy）→ AuthZEN-compatible PDP → allow/deny（必要ならcontext）。
• 実装候補: external authorization service、policy engine、gateway-native CEL/ABAC/RBAC/ReBAC等。policy languageはCore要件に固定しない。
• Enforcement sequence: authenticated actor/delegator確定 → normalized action/resource/tool request生成 → PDP evaluation → PEP enforce → backend call → audit outcome。

• 性能よりcorrectnessが主。後続TEST_PROFILE: deny rule 100% enforcement、alternate route bypass、identity spoof、tool alias/rename、argument mutation、streaming/session reuse、policy outage fail-closed/fail-openをsandbox tool backendで検証。未実施。

• Security: hard denyはLLM外部で強制。default-deny、least privilege、PEP bypass inventory、PDP outage behaviorを明文化。
• Privacy: PDPへ送るcontextは必要最小限。prompt全文をauthorization inputへ無条件送信しない。
• Audit: decision ID、policy/version、subject/actor/delegator、resource/action/tool、decision、reason、PEP outcomeを相関可能にする。
• Operability: policy rollout/versioning、shadow evaluation、rollback、deny spike monitoring、emergency break-glassの統制が必要。

「Agentの禁止操作や許可条件は、LLMの自己判断だけでなく、実行経路上のPolicy Enforcement Pointで強制し、外部Policy Decision Pointにsubject・resource・action・contextを評価させる構成が取れる。OpenID AuthZEN Authorization API 1.0はPDP/PEP間の相互運用境界を標準化している。一方、AI固有のtool意味論やdelegation、bypass経路は別途設計・検証が必要である。」

• EA-044 Delegated Authorizationのactor/delegator chainをpolicy inputへ接続。
• EA-045 Credential Brokerはallow後に短命credentialを払い出す順序とし、deny前のcredential exposureを避ける。
• EA-046 AI GatewayをPEP/choke point候補として図示。ただしgateway単独依存を避け、runtime/tool backend側でもdefense-in-depth可能性を残す。

OPEN: AuthZEN conformance/certificationの2026-09 status、agent-specific authorization profile標準、MCP authorization interoperability、policy bypassに関する独立評価、production latency/availability trade-off。

Agent tool/API実行に対するPDP/PEP standard + 2実装系 + bypass/failure evidence + safe TEST_PROFILEが揃えば本文採用判断へ移せる。今回、standardと1主要OSS実装/既知failureを確保したため初回packetはbounded complete、実装比較は後続採集対象

---

OpenID AuthZEN Authorization API 1.0 is Final; certification and COAZ/obligations are separate developing/draft surfaces. Do not standardize agent-specific policy vocabulary/tool semantics by implication. Deterministic PDP/PEP authorization does not prove semantic intent correctness or bypass absence. Preserve all OPEN_UNKNOWN.