{
  "format": "agent-article-v0",
  "article_id": "EA-047",
  "canonical_url": "/tools/ea-047-agent-policy-enforcement",
  "page_type": "reference",
  "claim_ids": [],
  "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"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "UNKNOWN",
  "observation_status": "SPEC_ONLY",
  "freshness": "UNKNOWN",
  "last_verified": null,
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "COMM-038-EA0047",
    "SRC-EA-047-URL-CC59C923304B",
    "SRC-EA-047-URL-DB986551C7EB",
    "SRC-EA-047-URL-970BEF30DFBA",
    "SRC-EA-047-URL-F34C58307B04",
    "WEBBODY-EA0047-R8-1FDE1F33"
  ],
  "article_sources": [
    {
      "id": "EVD-EA-047-URL-CC59C923304B",
      "evidence_class": "RESEARCH",
      "title": "[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:",
      "href": "https://openid.net/specs/authorization-api-1_0-final.html",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-047-URL-CC59C923304B"
      ],
      "supporting_locators": [
        "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"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-047-URL-DB986551C7EB",
      "evidence_class": "RESEARCH",
      "title": "[VERIFIED_SPEC | context] OpenID Foundation, “Authorization API 1.0 Final Specification Approved”, 2026-01-12. Canonical:",
      "href": "https://openid.net/authorization-api-1-0-final-specification-approved/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-047-URL-DB986551C7EB"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- [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/"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-047-URL-970BEF30DFBA",
      "evidence_class": "RESEARCH",
      "title": "[OSS_PRACTICE / PRODUCT_VOLATILE | support] Envoy AI Gateway releases, v0.5/v0.6 lineage, accessed 2026-09-13. Canonical:",
      "href": "https://github.com/envoyproxy/ai-gateway/releases",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-047-URL-970BEF30DFBA"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- [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"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-047-URL-F34C58307B04",
      "evidence_class": "RESEARCH",
      "title": "[OSS_PRACTICE / SOURCE_REPORT | counter] Envoy AI Gateway advisory GHSA-4gph-2hhr-5mwg, 2026-05-13. Canonical:",
      "href": "https://github.com/envoyproxy/ai-gateway/security/advisories/GHSA-4gph-2hhr-5mwg",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-047-URL-F34C58307B04"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "- [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"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EA-047-R11-RESEARCH",
      "evidence_class": "RESEARCH",
      "title": "EA-047 監査済みresearch / canonical revision binding",
      "supports": [
        "- Agent Policy EnforcementのCoreは既存authorization architectureで構成可能。AuthZEN 1.0によりPDP↔PEPの標準API境界がFinal化されており、AI固有policy engineを発明する必要はない。[VERIFIED_SPEC]\n- 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]\n- Envoy AI GatewayのMCP policyは、CEL/JWT/tool target/external authを組み合わせ、Agent tool trafficに決定論的policyを挿入できる実装例。[OSS_PRACTICE]\n- 「LLMにpolicy文を読ませる」ことと「policy enforcement」は区別すべき。前者はmodel behavior guidance、後者は外部の実行可否決定と強制である。[INFERENCE]"
      ],
      "limit": "canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "COMM-038-EA0047"
      ],
      "supporting_locators": [
        "COMM-038-EA0047",
        "EA-047-R5-LEGACY-MIGRATION-20261008-R1",
        "content/staging/EA-047.md"
      ],
      "scope": "監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。",
      "provenance_status": "AUDIT_PASS_CANONICAL_BINDING"
    },
    {
      "id": "EA-047-R11-WEB-READBACK",
      "evidence_class": "IMPL",
      "title": "EA-047 Web body identity / canonical readback",
      "supports": [
        "canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。"
      ],
      "limit": "body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。",
      "checked_at": null,
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "WEBBODY-EA0047-R8-1FDE1F33"
      ],
      "supporting_locators": [
        "WEBBODY-EA0047-R8-1FDE1F33",
        "content/staging/EA-047.md",
        "EA-047-R5-LEGACY-MIGRATION-20261008-R1"
      ],
      "scope": "R9/R10 canonical readback後のProduction生成時body identity。",
      "provenance_status": "CANONICAL_READBACK_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "WHY_THIS_MATTERS_TO_UPDATE",
      "text": "Agent/LLMの判断だけに禁止操作・許可条件を委ねると、prompt injection、誤推論、context loss、tool schema misuseで統制が崩れる。AI判断の外側に決定論的policy decision/enforcementを置き、subject/actor、resource、action、contextを評価してtool/API実行前に止める構造はEnterprise AIの安全境界として重要。"
    },
    {
      "heading": "SCOPE_ROUTING",
      "text": "Enterprise AI Core / security / governance / authorization / agent runtime / interoperability / implementation"
    },
    {
      "heading": "CLAIM_OR_RESEARCH_QUESTION",
      "text": "1. Agentの行動許可をLLM自身とは独立したPDP/PEPで決定する標準・実装基盤は2026-09時点で存在するか。\n2. Gateway/tool boundaryでdeterministic policyを強制できるか。\n3. policy engineが見られるcontextと、LLM内部意図/意味理解のギャップをどう扱うべきか。"
    },
    {
      "heading": "EVIDENCE TABLE",
      "text": "- [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を交換する標準境界を定義。\n- [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であることを確認。\n- [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へ組み込む実装。\n- [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。"
    },
    {
      "heading": "FINDINGS",
      "text": "- Agent Policy EnforcementのCoreは既存authorization architectureで構成可能。AuthZEN 1.0によりPDP↔PEPの標準API境界がFinal化されており、AI固有policy engineを発明する必要はない。[VERIFIED_SPEC]\n- 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]\n- Envoy AI GatewayのMCP policyは、CEL/JWT/tool target/external authを組み合わせ、Agent tool trafficに決定論的policyを挿入できる実装例。[OSS_PRACTICE]\n- 「LLMにpolicy文を読ませる」ことと「policy enforcement」は区別すべき。前者はmodel behavior guidance、後者は外部の実行可否決定と強制である。[INFERENCE]"
    },
    {
      "heading": "LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE",
      "text": "- AuthZENはauthorization API interoperabilityを規定するが、AI Agent固有のpolicy vocabulary、risk ontology、tool semantics、delegation modelまで標準化するものではない。\n- PDPが正しくdenyしても、PEPを通らないside channel、alternate credential、direct provider/tool endpointがあればbypass可能。全実行経路のchoke-point化が前提。\n- Policy inputがLLM生成metadataだけなら、誤ったsubject/resource/action分類を信頼してしまう。identity、resource、tool schema等はtrusted runtimeから構成する必要がある。\n- Parser/translation layerの差異でpolicy対象と実際にbackendへ届くmessageがずれるとTOCTOU/semantic mismatch型のbypass面になる。Envoy advisoryはこの種の実装リスクを裏づける。\n- 高度な「意図」や自然言語意味の判定を決定論的policyだけで完全に閉じることはできない。semantic classifier/LLM guardは補助信号であり、hard authorizationと混同しない。"
    },
    {
      "heading": "AVAILABILITY_GATES",
      "text": "- AuthZEN 1.0はFinal specification。ただしPDP製品/PEP統合ごとのsupport/conformanceは別確認。\n- Agent/MCP gatewayのfine-grained enforcementは製品・version固有。公開時はEnvoy等のsupported versionとpolicy featureを再確認。"
    },
    {
      "heading": "IMPLEMENTATION_STATE",
      "text": "- 標準Core: PEP（agent runtime/gateway/tool proxy）→ AuthZEN-compatible PDP → allow/deny（必要ならcontext）。\n- 実装候補: external authorization service、policy engine、gateway-native CEL/ABAC/RBAC/ReBAC等。policy languageはCore要件に固定しない。\n- Enforcement sequence: authenticated actor/delegator確定 → normalized action/resource/tool request生成 → PDP evaluation → PEP enforce → backend call → audit outcome。"
    },
    {
      "heading": "BENCHMARK_OR_EVAL",
      "text": "- 性能より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で検証。未実施。"
    },
    {
      "heading": "SECURITY / PRIVACY / AUDIT / OPERABILITY",
      "text": "- Security: hard denyはLLM外部で強制。default-deny、least privilege、PEP bypass inventory、PDP outage behaviorを明文化。\n- Privacy: PDPへ送るcontextは必要最小限。prompt全文をauthorization inputへ無条件送信しない。\n- Audit: decision ID、policy/version、subject/actor/delegator、resource/action/tool、decision、reason、PEP outcomeを相関可能にする。\n- Operability: policy rollout/versioning、shadow evaluation、rollback、deny spike monitoring、emergency break-glassの統制が必要。"
    },
    {
      "heading": "SAFE_WORDING_FOR_FUTURE_BOOK",
      "text": "「Agentの禁止操作や許可条件は、LLMの自己判断だけでなく、実行経路上のPolicy Enforcement Pointで強制し、外部Policy Decision Pointにsubject・resource・action・contextを評価させる構成が取れる。OpenID AuthZEN Authorization API 1.0はPDP/PEP間の相互運用境界を標準化している。一方、AI固有のtool意味論やdelegation、bypass経路は別途設計・検証が必要である。」"
    },
    {
      "heading": "UPDATE_WORK_HANDOFF",
      "text": "- EA-044 Delegated Authorizationのactor/delegator chainをpolicy inputへ接続。\n- EA-045 Credential Brokerはallow後に短命credentialを払い出す順序とし、deny前のcredential exposureを避ける。\n- EA-046 AI GatewayをPEP/choke point候補として図示。ただしgateway単独依存を避け、runtime/tool backend側でもdefense-in-depth可能性を残す。"
    },
    {
      "heading": "OPEN_UNKNOWN / STOP_CONDITION",
      "text": "OPEN: AuthZEN conformance/certificationの2026-09 status、agent-specific authorization profile標準、MCP authorization interoperability、policy bypassに関する独立評価、production latency/availability trade-off。"
    },
    {
      "heading": "STOP_CONDITION",
      "text": "Agent tool/API実行に対するPDP/PEP standard + 2実装系 + bypass/failure evidence + safe TEST_PROFILEが揃えば本文採用判断へ移せる。今回、standardと1主要OSS実装/既知failureを確保したため初回packetはbounded complete、実装比較は後続採集対象\n\n---"
    },
    {
      "heading": "AUDITED_BOUNDARY",
      "text": "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."
    }
  ],
  "human_url": "/tools/ea-047-agent-policy-enforcement",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-047-agent-policy-enforcement",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-047-agent-policy-enforcement"
}