# Agent Policy Enforcement

CURRENT_STATUS: UNKNOWN
OBSERVATION: SPEC_ONLY
FRESHNESS: UNKNOWN
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-047-agent-policy-enforcement
CLAIM_IDS: none
EVIDENCE_IDS: EVD-EA-047-URL-CC59C923304B, EVD-EA-047-URL-DB986551C7EB, EVD-EA-047-URL-970BEF30DFBA, EVD-EA-047-URL-F34C58307B04, EA-047-R11-RESEARCH, EA-047-R11-WEB-READBACK
UNKNOWN_IDS: EA-047-UNKNOWN-01, EA-047-UNKNOWN-CURRENTNESS
OPS_IDS: none

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

## Current judgment
- 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]

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

## Confirmed
- 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]

## UNKNOWN
- EA-047-UNKNOWN-01: OPEN: AuthZEN conformance/certificationの2026-09 status、agent-specific authorization profile標準、MCP authorization interoperability、policy bypassに関する独立評価、production latency/availability trade-off。
- EA-047-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。

## Evidence
- EVD-EA-047-URL-CC59C923304B (RESEARCH): [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
- EVD-EA-047-URL-DB986551C7EB (RESEARCH): [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/
- EVD-EA-047-URL-970BEF30DFBA (RESEARCH): [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
- EVD-EA-047-URL-F34C58307B04 (RESEARCH): [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
- EA-047-R11-RESEARCH (RESEARCH): EA-047 監査済みresearch / canonical revision binding
- EA-047-R11-WEB-READBACK (IMPL): EA-047 Web body identity / canonical readback

## Failure / limits
AuthZENはauthorization API interoperabilityを規定するが、AI Agent固有のpolicy vocabulary、risk ontology、tool semantics、delegation modelまで標準化するものではない。
## Failure / limits
PDPが正しくdenyしても、PEPを通らないside channel、alternate credential、direct provider/tool endpointがあればbypass可能。全実行経路のchoke-point化が前提。
## Failure / limits
Policy inputがLLM生成metadataだけなら、誤ったsubject/resource/action分類を信頼してしまう。identity、resource、tool schema等はtrusted runtimeから構成する必要がある。
## Failure / limits
Parser/translation layerの差異でpolicy対象と実際にbackendへ届くmessageがずれるとTOCTOU/semantic mismatch型のbypass面になる。Envoy advisoryはこの種の実装リスクを裏づける。
## Failure / limits
高度な「意図」や自然言語意味の判定を決定論的policyだけで完全に閉じることはできない。semantic classifier/LLM guardは補助信号であり、hard authorizationと混同しない。
## Failure / limits
OPEN: AuthZEN conformance/certificationの2026-09 status、agent-specific authorization profile標準、MCP authorization interoperability、policy bypassに関する独立評価、production latency/availability trade-off。
## Failure / limits
Agent tool/API実行に対するPDP/PEP standard + 2実装系 + bypass/failure evidence + safe TEST_PROFILEが揃えば本文採用判断へ移せる。今回、standardと1主要OSS実装/既知failureを確保したため初回packetはbounded complete、実装比較は後続採集対象

---
## Practice
AuthZEN 1.0はFinal specification。ただしPDP製品/PEP統合ごとのsupport/conformanceは別確認。
## Practice
Agent/MCP gatewayのfine-grained enforcementは製品・version固有。公開時はEnvoy等のsupported versionとpolicy featureを再確認。
## Practice
標準Core: PEP（agent runtime/gateway/tool proxy）→ AuthZEN-compatible PDP → allow/deny（必要ならcontext）。
## Practice
実装候補: external authorization service、policy engine、gateway-native CEL/ABAC/RBAC/ReBAC等。policy languageはCore要件に固定しない。
## Practice
Enforcement sequence: authenticated actor/delegator確定 → normalized action/resource/tool request生成 → PDP evaluation → PEP enforce → backend call → audit outcome。
## Practice
性能より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で検証。未実施。
## Practice
Security: hard denyはLLM外部で強制。default-deny、least privilege、PEP bypass inventory、PDP outage behaviorを明文化。
## Practice
Privacy: PDPへ送るcontextは必要最小限。prompt全文をauthorization inputへ無条件送信しない。
## Practice
Audit: decision ID、policy/version、subject/actor/delegator、resource/action/tool、decision、reason、PEP outcomeを相関可能にする。
## Practice
Operability: policy rollout/versioning、shadow evaluation、rollback、deny spike monitoring、emergency break-glassの統制が必要。
## Practice
EA-044 Delegated Authorizationのactor/delegator chainをpolicy inputへ接続。
## Practice
EA-045 Credential Brokerはallow後に短命credentialを払い出す順序とし、deny前のcredential exposureを避ける。
## Practice
EA-046 AI GatewayをPEP/choke point候補として図示。ただしgateway単独依存を避け、runtime/tool backend側でもdefense-in-depth可能性を残す。
## Practice
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.
## WHY_THIS_MATTERS_TO_UPDATE
Agent/LLMの判断だけに禁止操作・許可条件を委ねると、prompt injection、誤推論、context loss、tool schema misuseで統制が崩れる。AI判断の外側に決定論的policy decision/enforcementを置き、subject/actor、resource、action、contextを評価してtool/API実行前に止める構造はEnterprise AIの安全境界として重要。

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

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

## EVIDENCE TABLE
- [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。

## FINDINGS
- 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]

## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
- 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と混同しない。

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

## IMPLEMENTATION_STATE
- 標準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。

## BENCHMARK_OR_EVAL
- 性能より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 / PRIVACY / AUDIT / OPERABILITY
- 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の統制が必要。

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

## UPDATE_WORK_HANDOFF
- 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_UNKNOWN / STOP_CONDITION
OPEN: AuthZEN conformance/certificationの2026-09 status、agent-specific authorization profile標準、MCP authorization interoperability、policy bypassに関する独立評価、production latency/availability trade-off。

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

---

## AUDITED_BOUNDARY
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.

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.