{
  "format": "agent-article-v0",
  "article_id": "EA-066",
  "canonical_url": "/tools/ea-066-identity-aware-acl-aware-rag",
  "page_type": "reference",
  "claim_ids": [],
  "evidence_ids": [
    "EVD-EA-066-URL-9022F844329C",
    "EVD-EA-066-URL-E2833DCEB870",
    "EVD-EA-066-URL-75B5E41D9836",
    "EVD-EA-066-URL-C720169B0C47",
    "EVD-EA-066-URL-D9CD908D7C71",
    "EVD-EA-066-URL-786208E26886",
    "EVD-EA-066-URL-8E5CA37DE913",
    "EA-066-R11-RESEARCH",
    "EA-066-R11-WEB-READBACK"
  ],
  "unknown_ids": [
    "EA-066-UNKNOWN-01",
    "EA-066-UNKNOWN-02",
    "EA-066-UNKNOWN-CURRENTNESS"
  ],
  "operational_object_ids": [],
  "provider": [
    "Microsoft",
    "Google",
    "Gemini"
  ],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "UNKNOWN",
  "observation_status": "SPEC_ONLY",
  "freshness": "UNKNOWN",
  "last_verified": null,
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "COMM-062-EA0066",
    "SRC-EA-066-URL-9022F844329C",
    "SRC-EA-066-URL-E2833DCEB870",
    "SRC-EA-066-URL-75B5E41D9836",
    "SRC-EA-066-URL-C720169B0C47",
    "SRC-EA-066-URL-D9CD908D7C71",
    "SRC-EA-066-URL-786208E26886",
    "SRC-EA-066-URL-8E5CA37DE913",
    "WEBBODY-EA0066-R8-50DEAAEA"
  ],
  "article_sources": [
    {
      "id": "EVD-EA-066-URL-9022F844329C",
      "evidence_class": "RESEARCH",
      "title": "author/org: NIST",
      "href": "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-066-URL-9022F844329C"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "canonical URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-066-URL-E2833DCEB870",
      "evidence_class": "RESEARCH",
      "title": "author/org: Microsoft",
      "href": "https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-066-URL-E2833DCEB870"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "canonical URL: https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-066-URL-75B5E41D9836",
      "evidence_class": "RESEARCH",
      "title": "author/org: Google Cloud / Gemini Enterprise",
      "href": "https://docs.cloud.google.com/gemini/enterprise/docs/identity",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-066-URL-75B5E41D9836"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "canonical URL: https://docs.cloud.google.com/gemini/enterprise/docs/identity"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-066-URL-C720169B0C47",
      "evidence_class": "RESEARCH",
      "title": "author/org: Google Cloud / Agent Search",
      "href": "https://docs.cloud.google.com/generative-ai-app-builder/docs/create-data-store-es",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-066-URL-C720169B0C47"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "canonical URL: https://docs.cloud.google.com/generative-ai-app-builder/docs/create-data-store-es"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-066-URL-D9CD908D7C71",
      "evidence_class": "RESEARCH",
      "title": "author/org: OWASP GenAI Security Project",
      "href": "https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-066-URL-D9CD908D7C71"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "canonical URL: https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-066-URL-786208E26886",
      "evidence_class": "RESEARCH",
      "title": "author/org: Elastic",
      "href": "https://www.elastic.co/docs/reference/search-connectors/document-level-security",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-066-URL-786208E26886"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "canonical URL: https://www.elastic.co/docs/reference/search-connectors/document-level-security"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-066-URL-8E5CA37DE913",
      "evidence_class": "RESEARCH",
      "title": "author/org: Maosen Zhang et al.; Findings of ACL 2026",
      "href": "https://aclanthology.org/2026.findings-acl.287/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-066-URL-8E5CA37DE913"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "canonical URL: https://aclanthology.org/2026.findings-acl.287/"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EA-066-R11-RESEARCH",
      "evidence_class": "RESEARCH",
      "title": "EA-066 監査済みresearch / canonical revision binding",
      "supports": [
        "1. EA-066 is technically established as a distinct update topic. ACL-aware RAG should be defined as authorization-preserving retrieval, not merely metadata tagging.\n2. Safe end-to-end chain is: authoritative source permission → identity/principal mapping → permission metadata or federated source enforcement → query-time authorization → only authorized candidate/chunk retrieval → context assembly → generation/citation. Authorization after the LLM has already received an unauthorized passage is too late to preserve the source boundary. [INFERENCE from NIST + provider implementations]\n3. Native product mechanisms exist, but their maturity and scope differ. Azure's current native token-based ACL/RBAC mechanisms are partly preview/API-version gated; Google requires identity-provider plus acl_info/aclEnabled for custom sources. Therefore 'supports RAG' and 'supports source-equivalent authorization' are separate product claims.\n4. Permission freshness is security state. Azure explicitly documents that source permission changes are recognized only after permission metadata synchronization; stale ACL metadata can therefore create a window in which retrieval authorization no longer matches the source. [VERIFIED_SPEC + INFERENCE]\n5. Security filters using copied user/group strings are workable but create an additional authorization data plane that the operator must keep correct. Native identity-token enforcement reduces some custom logic but still depends on synchronized permission metadata. [VERIFIED_SPEC / INFERENCE]\n6. ACL-aware retrieval does not by itself prove that derived summaries, agent memory, caches, traces, logs, exports, or downstream tool state inherit the same restrictions. Those artifacts require explicit policy/provenance treatment. [INFERENCE; cross-reference EA-015/064/065]"
      ],
      "limit": "canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "COMM-062-EA0066"
      ],
      "supporting_locators": [
        "COMM-062-EA0066",
        "EA-066-R5-LEGACY-MIGRATION-20261008-R1",
        "content/staging/EA-066.md"
      ],
      "scope": "監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。",
      "provenance_status": "AUDIT_PASS_CANONICAL_BINDING"
    },
    {
      "id": "EA-066-R11-WEB-READBACK",
      "evidence_class": "IMPL",
      "title": "EA-066 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-EA0066-R8-50DEAAEA"
      ],
      "supporting_locators": [
        "WEBBODY-EA0066-R8-50DEAAEA",
        "content/staging/EA-066.md",
        "EA-066-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": "企業RAGでは「検索できる」と「その利用者が読める」は別問題である。検索indexやvector storeへ複数権限帯のデータを集約すると、source側ACLがretrieval時に適用されなければ、LLMへ渡すcontextそのものが越権取得になる。したがって回答後のマスキングではなく、retrieval結果がLLM contextへ入る前にauthorizationを強制し、source ACL変更・group membership変更・index/cachesの同期遅延まで追跡する必要がある。"
    },
    {
      "heading": "SCOPE_ROUTING",
      "text": "Enterprise AI Core: identity/authorization、least privilege、RAG security boundary、derived-artifact governance。\nProvider mapping: Microsoft Azure AI Search、Google Gemini Enterprise / Agent Search。\nImplementation / OSS practice: Elastic content connectors DLS。\nGovernance/security: NIST Zero Trust、OWASP GenAI。\nBenchmark/research: ACL 2026 LeakDojoをfailure evidenceとして限定利用。"
    },
    {
      "heading": "CLAIM_OR_RESEARCH_QUESTION",
      "text": "Q1. ACL-aware RAGは、source ACLをindex metadataへ写すだけでなく、caller identityに基づくquery-time enforcementまで必要か。\nQ2. ACL／group membership変更とindex側permission metadataの同期遅延は、越権retrievalの独立したfailure envelopeになるか。\nQ3. retrievalで許可された情報から生成されるsummary、cache、memory、logなどの派生物にも別途authorization/lifecycle設計が必要か。"
    },
    {
      "heading": "EVIDENCE TABLE",
      "text": "1) source class: official standard\nexact title: NIST SP 800-207, Zero Trust Architecture\nauthor/org: NIST\ncanonical URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf\npublication/update/access: August 2020 / accessed 2026-09-15\nversion/release: SP 800-207 Final\nsupporting locator: abstract access model; §2/§3, PDP/PEP and individual resource access requests\nevidence label: VERIFIED_SPEC\nrelation: support / context\nestablished: access is decided through policy decision/enforcement points; enterprises should explicitly authenticate/authorize subjects and enforce dynamic policy for individual resource requests rather than infer continuing trust from an earlier login. This is the architectural basis for placing authorization at or before the RAG retrieval boundary.\n\n\n2) source class: official product documentation\nexact title: Document-Level Access Control - Azure AI Search\nauthor/org: Microsoft\ncanonical URL: https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview\npublication/update/access: current page published/updated 2026-08 / accessed 2026-09-15\nversion/release/API: native ACL/RBAC ingestion and token enforcement are preview; 2026-08-01-preview is documented for current permission-restricted scenarios; SharePoint ACL ingestion includes 2026-05-01-preview behavior\nsupporting locator: Retrieve ACL permissions metadata; Enforce document-level permissions at query time; permission synchronization notes\nevidence label: VERIFIED_SPEC + PRODUCT_VOLATILE\nrelation: support / limit\nestablished: Azure AI Search can store source permission metadata and, with x-ms-query-source-authorization, compare caller Entra claims against indexed ACL/RBAC/Purview/SharePoint permission metadata. Microsoft explicitly states that source permission changes affect results only after the relevant metadata is synchronized to the index. SharePoint inherited-permission changes can require explicit refresh. Preview timing lag is documented.\n\n\n3) source class: official product documentation\nexact title: Configure access controls for custom data sources\nauthor/org: Google Cloud / Gemini Enterprise\ncanonical URL: https://docs.cloud.google.com/gemini/enterprise/docs/identity\npublication/update/access: last updated 2026-09-03 UTC / accessed 2026-09-15\nversion/release: current Gemini Enterprise documentation\nsupporting locator: Overview; Cloud Storage and BigQuery acl_info / aclEnabled procedures\nevidence label: VERIFIED_SPEC + PRODUCT_VOLATILE\nrelation: support / availability gate\nestablished: Gemini Enterprise identifies the end user through the configured identity provider and limits search results to accessible documents. Custom data sources require ACL metadata (acl_info with user/group principals) and access-controlled datastore configuration (aclEnabled=true). Product existence therefore does not imply secure ACL propagation unless identity and ACL ingestion are actually configured.\n\n\n4) source class: official product documentation\nexact title: Create a search data store\nauthor/org: Google Cloud / Agent Search\ncanonical URL: https://docs.cloud.google.com/generative-ai-app-builder/docs/create-data-store-es\npublication/update/access: current / accessed 2026-09-15\nversion/release: current Agent Search documentation\nsupporting locator: Google Drive connection prerequisites and security-control limitations\nevidence label: VERIFIED_SPEC + PRODUCT_VOLATILE\nrelation: support / limit\nestablished: Google Drive federation requires identity-provider configuration to enforce data-source access control and imposes managed-account/domain constraints. Federation avoids copying source data into the search index, but this does not eliminate identity/configuration gates or downstream handling considerations.\n\n\n5) source class: industry security guidance\nexact title: LLM08:2025 Vector and Embedding Weaknesses\nauthor/org: OWASP GenAI Security Project\ncanonical URL: https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/\npublication/update/access: 2025 edition / accessed 2026-09-15\nversion/release: OWASP GenAI LLM Top 10 2025, LLM08\nevidence label: SOURCE_REPORT\nrelation: support / failure envelope\nestablished: OWASP identifies unauthorized access/data leakage where data with different access restrictions share a vector/RAG environment and recommends permission-aware vector databases. This is security guidance, not a guarantee for any specific implementation.\n\n\n6) source class: author-maintained implementation documentation\nexact title: Document level security for content connectors\nauthor/org: Elastic\ncanonical URL: https://www.elastic.co/docs/reference/search-connectors/document-level-security\npublication/update/access: accessed 2026-09-15\nversion/release: connector DLS introduced in 8.9.0; documented feature remains beta and subscription-dependent\nsupporting locator: Availability & prerequisites; supported connectors\n evidence label: OSS_PRACTICE + PRODUCT_VOLATILE\nrelation: implementation context / limit\nestablished: Elastic connectors can preserve user/group-based document-level security for multiple enterprise sources, but connector DLS is explicitly beta and not available at all subscription levels. It demonstrates a practical ACL-preserving ingestion/retrieval pattern without establishing universal behavior.\n\n\n7) source class: primary peer-reviewed research\nexact title: LeakDojo: Decoding the Leakage Threats of RAG Systems\nauthor/org: Maosen Zhang et al.; Findings of ACL 2026\ncanonical URL: https://aclanthology.org/2026.findings-acl.287/\npublication/update/access: July 2026 / accessed 2026-09-15\nversion/release: ACL 2026 paper; DOI 10.18653/v1/2026.findings-acl.287\nsupporting locator: abstract and evaluation across 6 attacks, 14 LLMs, 4 datasets\n evidence label: RESEARCH\nrelation: counter / failure context\nestablished: controlled evaluations show that RAG databases can be susceptible to leakage attacks and that stronger instruction-following / higher RAG faithfulness can correlate with greater leakage in the tested settings. This supports testing retrieval leakage independently of normal quality, but does NOT establish ACL bypass in every product or deployment."
    },
    {
      "heading": "FINDINGS",
      "text": "1. EA-066 is technically established as a distinct update topic. ACL-aware RAG should be defined as authorization-preserving retrieval, not merely metadata tagging.\n2. Safe end-to-end chain is: authoritative source permission → identity/principal mapping → permission metadata or federated source enforcement → query-time authorization → only authorized candidate/chunk retrieval → context assembly → generation/citation. Authorization after the LLM has already received an unauthorized passage is too late to preserve the source boundary. [INFERENCE from NIST + provider implementations]\n3. Native product mechanisms exist, but their maturity and scope differ. Azure's current native token-based ACL/RBAC mechanisms are partly preview/API-version gated; Google requires identity-provider plus acl_info/aclEnabled for custom sources. Therefore 'supports RAG' and 'supports source-equivalent authorization' are separate product claims.\n4. Permission freshness is security state. Azure explicitly documents that source permission changes are recognized only after permission metadata synchronization; stale ACL metadata can therefore create a window in which retrieval authorization no longer matches the source. [VERIFIED_SPEC + INFERENCE]\n5. Security filters using copied user/group strings are workable but create an additional authorization data plane that the operator must keep correct. Native identity-token enforcement reduces some custom logic but still depends on synchronized permission metadata. [VERIFIED_SPEC / INFERENCE]\n6. ACL-aware retrieval does not by itself prove that derived summaries, agent memory, caches, traces, logs, exports, or downstream tool state inherit the same restrictions. Those artifacts require explicit policy/provenance treatment. [INFERENCE; cross-reference EA-015/064/065]"
    },
    {
      "heading": "LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE",
      "text": "- Source ACL present ≠ ACL correctly copied to every chunk/index record.\n- ACL copied ≠ current ACL; revocation/group changes can lag index refresh.\n- User authenticated ≠ authorized for every retrieved resource; NIST explicitly rejects blanket trust after base authentication.\n- Search/index service authorization ≠ source-document authorization. The application/service account can have broad index access while end-user results require separate trimming.\n- Result trimming after retrieval but before display is weaker than enforcement before context assembly if unauthorized content is already exposed to the LLM/tool pipeline.\n- Generated answer/citation may combine facts across documents. Source-document ACLs do not automatically define a safe policy for derived artifacts.\n- Federated retrieval can reduce copied-data persistence, but queries/identity/context can cross service boundaries and the source connector's authorization semantics remain provider-specific.\n- LeakDojo measures RAG leakage attacks in controlled systems; it is counterevidence against assuming retrieval databases are intrinsically private, not proof of an ACL defect in Azure/Google/Elastic."
    },
    {
      "heading": "AVAILABILITY_GATES",
      "text": "Azure AI Search: REST/API revision and preview status; source type (ADLS/Blob/SharePoint/OneLake etc.); Microsoft Entra identity; indexed permission metadata freshness; Purview policy where used; SDK preview package where relevant.\nGoogle Gemini Enterprise / Agent Search: configured identity provider/workforce identity; managed organization identity; data-source type; acl_info presence; aclEnabled datastore setting; connector-specific domain/ownership/admin prerequisites.\nElastic: connector support list; connector/server version; beta status; subscription tier; source-specific permission sync behavior."
    },
    {
      "heading": "IMPLEMENTATION_STATE",
      "text": "VERIFIED_SPEC: provider implementations exist for identity/ACL-aware retrieval. Azure and Google both document query-result restriction based on caller identity and source/document permission metadata or federation. OSS_PRACTICE: Elastic provides connector DLS patterns.\nPROPOSAL for future Core: define `AUTHORIZATION-PRESERVING RAG CONTRACT` with fields: source_object_id, source_acl_revision/time, principal/user/group IDs, identity_provider, ingestion_time, permission_sync_time, index/chunk IDs, authorization_mode (native token / metadata filter / federation), query principal, policy decision, retrieved authorized chunk IDs, context assembly IDs, citation IDs, derived-artifact policy, cache/memory/log policy, and revocation convergence evidence."
    },
    {
      "heading": "BENCHMARK_OR_EVAL",
      "text": "Retrieval relevance/answer accuracy alone is not an authorization evaluation. Add security-specific measures:\n- unauthorized_retrieval_rate / false-allow rate (target must be zero for protected fixture)\n- false-deny rate\n- ACL propagation correctness across parent/inherited/group permissions\n- revocation-to-enforcement latency\n- stale-cache/index hits after revoke\n- unauthorized content presence in assembled LLM context, citations, summary/cache/memory/logs\n- cross-principal isolation.\nLeakDojo may be referenced as a leakage stress-testing precedent but not substituted for an ACL fixture."
    },
    {
      "heading": "SECURITY / PRIVACY / AUDIT / OPERABILITY",
      "text": "Security: authorization should be enforced before protected chunks enter model context; deny by policy when identity/ACL state required for a protected source is unresolved.\nPrivacy: identity-aware search necessarily processes principal/group information; retain only what is necessary and separate identity telemetry from content logging.\nAudit: log source ACL revision/sync time, query principal, authorization mechanism, policy outcome, retrieved document/chunk IDs, and config/API revision sufficient for replay without logging sensitive content unnecessarily.\nOperability: treat ACL refresh and group-membership propagation as measurable SLOs. Alert when permission sync is stale or fails rather than silently continuing with old authorization metadata.\nCost: native ACL/federated mechanisms can reduce custom authorization code but may impose product tier, index refresh, identity integration, and query overhead; no universal cost claim is established in this RUN."
    },
    {
      "heading": "SAFE_WORDING_FOR_FUTURE_BOOK",
      "text": "「RAGで元データの権限を守るには、文書にACLを付けて保存するだけでは足りない。検索時の利用者を識別し、その時点で有効な権限と照合して、許可された文書・チャンクだけをLLMのコンテキストへ渡す必要がある。さらに、元データの権限変更が検索インデックスへ反映されるまでには遅延があり得るため、ACL同期の鮮度も認可状態の一部として監視する。『ログイン済み』『検索結果では非表示』『RAG対応』はいずれも、元データと同じアクセス境界が保たれている証明にはならない。」"
    },
    {
      "heading": "UPDATE_WORK_HANDOFF",
      "text": "1. Coreへ`AUTHORIZATION-PRESERVING RAG CONTRACT`採用を検討し、EA-061 Data Classification、EA-064 Memory Lifecycle、EA-065 Records/eDiscovery、EA-067 Freshness Engineeringとcross-referenceする。\n2. Provider mapping更新時はAzureのpreview API/version、SharePoint inherited ACL refresh、Purview/ADLS/Blob対応を再確認する。\n3. GoogleはGemini Enterprise/Agent Searchの名称・connector別ACL behavior、identity provider prerequisites、federated vs ingested datastoreを再確認する。\n4. 実機が必要な項目は下記TEST_PROFILEでのみ実施し、production tenant/private dataを使わない。\nTEST_PROFILE (UNPERFORMED): synthetic principals A/B/C、documents A-only/B-only/shared/publicを作る。AでB-onlyがretrieval candidate/context/citation/cache/memory/logのいずれにも現れないことを確認。次にA-only文書のA権限を撤回し、source change時刻から検索/index/context全層で不可視になるまでの時間を計測。group membership追加/削除、nested/inherited permissions、chunking後のACL propagation、cache hit時も同じfixtureで検証。false allowはcritical failureとして扱う。\n5. 後続アップデートではpermission change event/CDCとEA-067のfreshness設計を統合し、content freshness SLOとauthorization freshness SLOを分離する。"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "/ STOP_CONDITION"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "- 各provider/connectorでのnested group、dynamic group、guest/service principal、deny ACL、inherited ACLの完全な対応matrix。\n- permission metadataの最大遅延・SLA/SLO。Azureは遅延存在を明記するが普遍的な上限はこのRUNでは確定していない。\n- chunk/embedding/summary/cache/memory/logへ権限ラベルをどこまで自動伝播するかのprovider横断仕様。\n- derived answerへ複数source ACLが混ざる場合の標準的なauthorization semantics。"
    },
    {
      "heading": "STOP_CONDITION",
      "text": "source ACL ingestion/query enforcement、identity gate、permission-staleness failure、independent leakage evidence、future TEST_PROFILEまで確保したためEA-066の初回Evidence Packetとしてbounded complete。製品固有の全connector matrixは公開後更新時の再確認へ送る。\n\n---"
    },
    {
      "heading": "AUDITED_BOUNDARY",
      "text": "Authorization must happen before protected chunks enter model context. Search-service authentication is not document authorization. Azure, Google, Elastic and Databricks authorization modes are not interchangeable. Databricks source-table ABAC does not propagate to AI Search indexes; generic source-ACL-propagation wording is prohibited. Derived summaries/caches/memory/logs/exports do not automatically inherit source authorization."
    }
  ],
  "human_url": "/tools/ea-066-identity-aware-acl-aware-rag",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-066-identity-aware-acl-aware-rag",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-066-identity-aware-acl-aware-rag"
}