AI
Identity checks must happen during context assembly, not after retrieval
Enterprise teams building AI systems are shipping permission filters too late in the retrieval pipeline, leaving sensitive data exposed even after platform vendors announced identity-aware solutions.
The New Stack
A common enterprise scenario illustrates the problem: an employee leaves the finance team at 9 a.m., but the permissions sync runs nightly at 2 a.m. For seventeen hours, that departing worker can still extract confidential financial documents from the retrieval system. By then, the system has no way to recognize the access violation.
This gap between announcement and implementation matters. Major cloud platforms have converged on where permissions must live—during the moment of context assembly, when a system decides which enterprise knowledge to provide to a specific user for a specific question. Yet most teams still deploy outdated approaches that check permissions after sensitive documents have already been retrieved and processed.
The Vendor Consensus and the Implementation Gap#
Platform vendors now agree on the architecture. Microsoft shipped identity-aware retrieval through its Work IQ API in June, embedding permissions checks directly into the system that honors Microsoft 365 access controls. AWS announced its vision with AWS Context on June 17, describing how permissions should flow through its Lake Formation and Glue Data Catalog—yet it remains unavailable for purchase months later, listed only as "coming soon." Databricks extended Unity Catalog to agents by applying permissions at the runtime level.
The consensus is clear: permissions belong in the assembly context, the architectural layer where identity gets resolved before data ever reaches a model. But the software most companies are actually running has not caught up with this thinking.
Why Late Filtering Fails#
The distinction matters because once sensitive text has been hydrated, reranked, summarized, or cached outside the retrieval boundary, enforcing permissions becomes a chase rather than prevention. Security reviews frequently surface this risk: a model that has already read content the user was never authorized to retrieve has already violated the boundary, regardless of what happens next.
Research underscores the danger. Researchers at Penn State tested graph-based retrieval systems and found that summarization—a common defense—can actually amplify leakage in targeted attacks by preserving salient details, which are typically the most sensitive ones. A separate study found that two individually secure components can compose an insecure system when authorization is not rechecked at every handoff, such as the transition between vector search and graph traversal.

