# Identity-aware／ACL-aware RAG

CURRENT_STATUS: UNKNOWN
OBSERVATION: SPEC_ONLY
FRESHNESS: UNKNOWN
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-066-identity-aware-acl-aware-rag
CLAIM_IDS: none
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
OPS_IDS: none

## Summary
「RAGで元データの権限を守るには、文書にACLを付けて保存するだけでは足りない。検索時の利用者を識別し、その時点で有効な権限と照合して、許可された文書・チャンクだけをLLMのコンテキストへ渡す必要がある。さらに、元データの権限変更が検索インデックスへ反映されるまでには遅延があり得るため、ACL同期の鮮度も認可状態の一部として監視する。『ログイン済み』『検索結果では非表示』『RAG対応』はいずれも、元データと同じアクセス境界が保たれている証明にはならない。」

## Current judgment
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.
2. 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]
3. 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.
4. 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]
5. 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]
6. 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]

## Scope
Enterprise AI Core: identity/authorization、least privilege、RAG security boundary、derived-artifact governance。
Provider mapping: Microsoft Azure AI Search、Google Gemini Enterprise / Agent Search。
Implementation / OSS practice: Elastic content connectors DLS。
Governance/security: NIST Zero Trust、OWASP GenAI。
Benchmark/research: ACL 2026 LeakDojoをfailure evidenceとして限定利用。

## Confirmed
- EA-066 is technically established as a distinct update topic. ACL-aware RAG should be defined as authorization-preserving retrieval, not merely metadata tagging.
- 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]
- 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.
- 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]
- 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]
- 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]

## UNKNOWN
- EA-066-UNKNOWN-01: / STOP_CONDITION
- EA-066-UNKNOWN-02: - 各provider/connectorでのnested group、dynamic group、guest/service principal、deny ACL、inherited ACLの完全な対応matrix。
- permission metadataの最大遅延・SLA/SLO。Azureは遅延存在を明記するが普遍的な上限はこのRUNでは確定していない。
- chunk/embedding/summary/cache/memory/logへ権限ラベルをどこまで自動伝播するかのprovider横断仕様。
- derived answerへ複数source ACLが混ざる場合の標準的なauthorization semantics。
- EA-066-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。

## Evidence
- EVD-EA-066-URL-9022F844329C (RESEARCH): author/org: NIST — https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
- EVD-EA-066-URL-E2833DCEB870 (RESEARCH): author/org: Microsoft — https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview
- EVD-EA-066-URL-75B5E41D9836 (RESEARCH): author/org: Google Cloud / Gemini Enterprise — https://docs.cloud.google.com/gemini/enterprise/docs/identity
- EVD-EA-066-URL-C720169B0C47 (RESEARCH): author/org: Google Cloud / Agent Search — https://docs.cloud.google.com/generative-ai-app-builder/docs/create-data-store-es
- EVD-EA-066-URL-D9CD908D7C71 (RESEARCH): author/org: OWASP GenAI Security Project — https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/
- EVD-EA-066-URL-786208E26886 (RESEARCH): author/org: Elastic — https://www.elastic.co/docs/reference/search-connectors/document-level-security
- EVD-EA-066-URL-8E5CA37DE913 (RESEARCH): author/org: Maosen Zhang et al.; Findings of ACL 2026 — https://aclanthology.org/2026.findings-acl.287/
- EA-066-R11-RESEARCH (RESEARCH): EA-066 監査済みresearch / canonical revision binding
- EA-066-R11-WEB-READBACK (IMPL): EA-066 Web body identity / canonical readback

## Failure / limits
Source ACL present ≠ ACL correctly copied to every chunk/index record.
## Failure / limits
ACL copied ≠ current ACL; revocation/group changes can lag index refresh.
## Failure / limits
User authenticated ≠ authorized for every retrieved resource; NIST explicitly rejects blanket trust after base authentication.
## Failure / limits
Search/index service authorization ≠ source-document authorization. The application/service account can have broad index access while end-user results require separate trimming.
## Failure / limits
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.
## Failure / limits
Generated answer/citation may combine facts across documents. Source-document ACLs do not automatically define a safe policy for derived artifacts.
## Failure / limits
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.
## Failure / limits
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.
## Failure / limits
source ACL ingestion/query enforcement、identity gate、permission-staleness failure、independent leakage evidence、future TEST_PROFILEまで確保したためEA-066の初回Evidence Packetとしてbounded complete。製品固有の全connector matrixは公開後更新時の再確認へ送る。

---
## Practice
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.
Google 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.
Elastic: connector support list; connector/server version; beta status; subscription tier; source-specific permission sync behavior.
## Practice
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.
PROPOSAL 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.
## Practice
Retrieval relevance/answer accuracy alone is not an authorization evaluation. Add security-specific measures:
## Practice
unauthorized_retrieval_rate / false-allow rate (target must be zero for protected fixture)
## Practice
false-deny rate
## Practice
ACL propagation correctness across parent/inherited/group permissions
## Practice
revocation-to-enforcement latency
## Practice
stale-cache/index hits after revoke
## Practice
unauthorized content presence in assembled LLM context, citations, summary/cache/memory/logs
## Practice
cross-principal isolation.
LeakDojo may be referenced as a leakage stress-testing precedent but not substituted for an ACL fixture.
## Practice
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.
Privacy: identity-aware search necessarily processes principal/group information; retain only what is necessary and separate identity telemetry from content logging.
Audit: 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.
Operability: 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.
Cost: 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.
## Practice
Coreへ`AUTHORIZATION-PRESERVING RAG CONTRACT`採用を検討し、EA-061 Data Classification、EA-064 Memory Lifecycle、EA-065 Records/eDiscovery、EA-067 Freshness Engineeringとcross-referenceする。
## Practice
Provider mapping更新時はAzureのpreview API/version、SharePoint inherited ACL refresh、Purview/ADLS/Blob対応を再確認する。
## Practice
GoogleはGemini Enterprise/Agent Searchの名称・connector別ACL behavior、identity provider prerequisites、federated vs ingested datastoreを再確認する。
## Practice
実機が必要な項目は下記TEST_PROFILEでのみ実施し、production tenant/private dataを使わない。
TEST_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として扱う。
## Practice
後続アップデートではpermission change event/CDCとEA-067のfreshness設計を統合し、content freshness SLOとauthorization freshness SLOを分離する。
## Practice
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.
## WHY_THIS_MATTERS_TO_UPDATE
企業RAGでは「検索できる」と「その利用者が読める」は別問題である。検索indexやvector storeへ複数権限帯のデータを集約すると、source側ACLがretrieval時に適用されなければ、LLMへ渡すcontextそのものが越権取得になる。したがって回答後のマスキングではなく、retrieval結果がLLM contextへ入る前にauthorizationを強制し、source ACL変更・group membership変更・index/cachesの同期遅延まで追跡する必要がある。

## SCOPE_ROUTING
Enterprise AI Core: identity/authorization、least privilege、RAG security boundary、derived-artifact governance。
Provider mapping: Microsoft Azure AI Search、Google Gemini Enterprise / Agent Search。
Implementation / OSS practice: Elastic content connectors DLS。
Governance/security: NIST Zero Trust、OWASP GenAI。
Benchmark/research: ACL 2026 LeakDojoをfailure evidenceとして限定利用。

## CLAIM_OR_RESEARCH_QUESTION
Q1. ACL-aware RAGは、source ACLをindex metadataへ写すだけでなく、caller identityに基づくquery-time enforcementまで必要か。
Q2. ACL／group membership変更とindex側permission metadataの同期遅延は、越権retrievalの独立したfailure envelopeになるか。
Q3. retrievalで許可された情報から生成されるsummary、cache、memory、logなどの派生物にも別途authorization/lifecycle設計が必要か。

## EVIDENCE TABLE
1) source class: official standard
exact title: NIST SP 800-207, Zero Trust Architecture
author/org: NIST
canonical URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
publication/update/access: August 2020 / accessed 2026-09-15
version/release: SP 800-207 Final
supporting locator: abstract access model; §2/§3, PDP/PEP and individual resource access requests
evidence label: VERIFIED_SPEC
relation: support / context
established: 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.


2) source class: official product documentation
exact title: Document-Level Access Control - Azure AI Search
author/org: Microsoft
canonical URL: https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview
publication/update/access: current page published/updated 2026-08 / accessed 2026-09-15
version/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
supporting locator: Retrieve ACL permissions metadata; Enforce document-level permissions at query time; permission synchronization notes
evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE
relation: support / limit
established: 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.


3) source class: official product documentation
exact title: Configure access controls for custom data sources
author/org: Google Cloud / Gemini Enterprise
canonical URL: https://docs.cloud.google.com/gemini/enterprise/docs/identity
publication/update/access: last updated 2026-09-03 UTC / accessed 2026-09-15
version/release: current Gemini Enterprise documentation
supporting locator: Overview; Cloud Storage and BigQuery acl_info / aclEnabled procedures
evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE
relation: support / availability gate
established: 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.


4) source class: official product documentation
exact title: Create a search data store
author/org: Google Cloud / Agent Search
canonical URL: https://docs.cloud.google.com/generative-ai-app-builder/docs/create-data-store-es
publication/update/access: current / accessed 2026-09-15
version/release: current Agent Search documentation
supporting locator: Google Drive connection prerequisites and security-control limitations
evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE
relation: support / limit
established: 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.


5) source class: industry security guidance
exact title: LLM08:2025 Vector and Embedding Weaknesses
author/org: OWASP GenAI Security Project
canonical URL: https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/
publication/update/access: 2025 edition / accessed 2026-09-15
version/release: OWASP GenAI LLM Top 10 2025, LLM08
evidence label: SOURCE_REPORT
relation: support / failure envelope
established: 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.


6) source class: author-maintained implementation documentation
exact title: Document level security for content connectors
author/org: Elastic
canonical URL: https://www.elastic.co/docs/reference/search-connectors/document-level-security
publication/update/access: accessed 2026-09-15
version/release: connector DLS introduced in 8.9.0; documented feature remains beta and subscription-dependent
supporting locator: Availability & prerequisites; supported connectors
 evidence label: OSS_PRACTICE + PRODUCT_VOLATILE
relation: implementation context / limit
established: 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.


7) source class: primary peer-reviewed research
exact title: LeakDojo: Decoding the Leakage Threats of RAG Systems
author/org: Maosen Zhang et al.; Findings of ACL 2026
canonical URL: https://aclanthology.org/2026.findings-acl.287/
publication/update/access: July 2026 / accessed 2026-09-15
version/release: ACL 2026 paper; DOI 10.18653/v1/2026.findings-acl.287
supporting locator: abstract and evaluation across 6 attacks, 14 LLMs, 4 datasets
 evidence label: RESEARCH
relation: counter / failure context
established: 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.

## FINDINGS
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.
2. 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]
3. 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.
4. 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]
5. 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]
6. 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]

## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
- Source ACL present ≠ ACL correctly copied to every chunk/index record.
- ACL copied ≠ current ACL; revocation/group changes can lag index refresh.
- User authenticated ≠ authorized for every retrieved resource; NIST explicitly rejects blanket trust after base authentication.
- Search/index service authorization ≠ source-document authorization. The application/service account can have broad index access while end-user results require separate trimming.
- 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.
- Generated answer/citation may combine facts across documents. Source-document ACLs do not automatically define a safe policy for derived artifacts.
- 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.
- 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.

## AVAILABILITY_GATES
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.
Google 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.
Elastic: connector support list; connector/server version; beta status; subscription tier; source-specific permission sync behavior.

## IMPLEMENTATION_STATE
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.
PROPOSAL 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.

## BENCHMARK_OR_EVAL
Retrieval relevance/answer accuracy alone is not an authorization evaluation. Add security-specific measures:
- unauthorized_retrieval_rate / false-allow rate (target must be zero for protected fixture)
- false-deny rate
- ACL propagation correctness across parent/inherited/group permissions
- revocation-to-enforcement latency
- stale-cache/index hits after revoke
- unauthorized content presence in assembled LLM context, citations, summary/cache/memory/logs
- cross-principal isolation.
LeakDojo may be referenced as a leakage stress-testing precedent but not substituted for an ACL fixture.

## SECURITY / PRIVACY / AUDIT / OPERABILITY
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.
Privacy: identity-aware search necessarily processes principal/group information; retain only what is necessary and separate identity telemetry from content logging.
Audit: 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.
Operability: 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.
Cost: 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.

## SAFE_WORDING_FOR_FUTURE_BOOK
「RAGで元データの権限を守るには、文書にACLを付けて保存するだけでは足りない。検索時の利用者を識別し、その時点で有効な権限と照合して、許可された文書・チャンクだけをLLMのコンテキストへ渡す必要がある。さらに、元データの権限変更が検索インデックスへ反映されるまでには遅延があり得るため、ACL同期の鮮度も認可状態の一部として監視する。『ログイン済み』『検索結果では非表示』『RAG対応』はいずれも、元データと同じアクセス境界が保たれている証明にはならない。」

## UPDATE_WORK_HANDOFF
1. Coreへ`AUTHORIZATION-PRESERVING RAG CONTRACT`採用を検討し、EA-061 Data Classification、EA-064 Memory Lifecycle、EA-065 Records/eDiscovery、EA-067 Freshness Engineeringとcross-referenceする。
2. Provider mapping更新時はAzureのpreview API/version、SharePoint inherited ACL refresh、Purview/ADLS/Blob対応を再確認する。
3. GoogleはGemini Enterprise/Agent Searchの名称・connector別ACL behavior、identity provider prerequisites、federated vs ingested datastoreを再確認する。
4. 実機が必要な項目は下記TEST_PROFILEでのみ実施し、production tenant/private dataを使わない。
TEST_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として扱う。
5. 後続アップデートではpermission change event/CDCとEA-067のfreshness設計を統合し、content freshness SLOとauthorization freshness SLOを分離する。

## OPEN_UNKNOWN
/ STOP_CONDITION

## OPEN_UNKNOWN
- 各provider/connectorでのnested group、dynamic group、guest/service principal、deny ACL、inherited ACLの完全な対応matrix。
- permission metadataの最大遅延・SLA/SLO。Azureは遅延存在を明記するが普遍的な上限はこのRUNでは確定していない。
- chunk/embedding/summary/cache/memory/logへ権限ラベルをどこまで自動伝播するかのprovider横断仕様。
- derived answerへ複数source ACLが混ざる場合の標準的なauthorization semantics。

## STOP_CONDITION
source ACL ingestion/query enforcement、identity gate、permission-staleness failure、independent leakage evidence、future TEST_PROFILEまで確保したためEA-066の初回Evidence Packetとしてbounded complete。製品固有の全connector matrixは公開後更新時の再確認へ送る。

---

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

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