A finance employee leaves their team at 9 a.m. on Monday. The system's synchronization runs at 2 a.m. the next day. For seventeen hours, that person can still extract finance documents from the retrieval index, and no component in the architecture recognizes the violation. This scenario, adapted from Truto, resonates with nearly every team working on enterprise AI systems.
The security review version of the same problem plays out differently. A retrieval pilot succeeds, the demonstration impresses leadership, the executive sponsor approves the project, and then someone in the room asks: how do you prevent this system from summarizing the CEO's compensation review for an intern who casually asks about salary bands? Most teams lack a clear answer. What they have instead is a filter applied after the fact.
The structural solution requires rethinking when permissions get enforced. Permissions should not be a filter applied to context after assembly is complete. Instead, they must be a fundamental property of how context gets assembled for a particular user at a particular moment. Assembly is the final opportunity to exclude sensitive material before the model encounters it.
Permissions are not a filter you apply to context after you have assembled it.
Major cloud platforms are converging on this architectural pattern, though terminology remains inconsistent. The company Modus, which operates in this space, refers to it as context composition; this discussion uses context assembly. This is the mechanism where a system determines which enterprise knowledge to provide to a model for a specific user, in a specific context, answering a specific question. Everything before assembly is storage; everything after is inference. Identity either exists at assembly or it does not exist at all.
Announcements outpace actual availability
The timing of this discussion matters. In June, platform vendors reached consensus on where this architectural step belongs, but the software running in most enterprises has not yet caught up.
AWS made the clearest statement in June when it announced AWS Context at its New York Summit. The underlying design choice is instructive. The graph inherits the same permissions that govern the data lake through Glue Data Catalog, SageMaker Unified Studio, and Lake Formation. Identity gets verified again when a query arrives. The teams already managing everything else will manage this layer too, using column-, row-, and cell-level policies that S3 object permissions alone cannot enforce.
Precision about timing matters because the narrative has already become blurred. AWS describes calls as designed to inherit the calling user's IAM and Lake Formation permissions, allowing an agent to see only relationships its identity permits. That language signals a roadmap. Nearly three months after the announcement, AWS Context remains listed as coming soon, with no general availability date, no regional availability, and no published pricing. Amazon Bedrock Managed Knowledge Base did reach general availability that same day, which explains why the two are frequently conflated.
Microsoft shipped identity-aware retrieval on June 16. AWS announced it on June 17, and you still cannot buy it.
One day before AWS announced Context, Microsoft's Work IQ API became generally available. It operates within the context of the signed-in user, respects Microsoft 365 permissions, bills through Copilot Credits, and administrators can enable it in production today. Two announcements separated by a single day, identical architectural thinking, yet only one is deployable right now.
Databricks approached the same architectural position from a different angle, extending Unity Catalog to support agents. Partners in that ecosystem note a limitation: the protection anchors to the Databricks Runtime rather than to the data itself, so enforcement stops when a BI tool or an MCP server accesses the same source directly.
Organizations did not wait for these solutions to mature. They deployed the flat-index approach while identity-aware versions remained on roadmaps.
The direction of development is clear, and so is the constraint. Each control system works most effectively within the boundaries of the system that created it. The real challenge emerges when an agent requires context spanning multiple systems simultaneously, and that is the problem context assembly must address.
The data lake does not contain the entire business
Lake Formation enforces granular permissions within its own boundaries effectively. Those permissions do not automatically become the sharing rules in Salesforce, Slack, Google Drive, or Confluence.
AWS documentation clarifies its own limits. August guidance on propagating user authorization context through AgentCore describes passing Salesforce a token scoped to the actual user, enabling Salesforce to apply its own sharing rules. According to AWS, the agent acts as an orchestrator, not a gatekeeper, and downstream services enforce authorization. This represents a reasonable architectural choice and an important product boundary. Lake Formation does not integrate with Salesforce, GitHub, Jira, Slack, Confluence, or Google Drive. Each system independently decides visibility, or none of them do.
The most revealing statement concerns the filter itself. In the same security guidance, AWS plainly states that metadata filtering is application-layer enforcement. The bedrock:Retrieve API doesn't expose metadata filter content as an IAM condition key. This sentence deserves repeated attention because it represents a vendor clearly marking where its guarantees end and yours begin.
The same principle applies to custom implementations. Tags attached to chunks are not an identity boundary. They are hints that application code is expected to respect.
What fails when authorization arrives late
The failure is structural, which is why the same patterns keep appearing.
To be precise: the argument is not that filters are inherently bad. The problem is sequence. A retrieval system can search a mixed index, retrieve opaque identifiers, authorize them, and hydrate only documents the user is permitted to read. This is a filter, and it works, because unauthorized material never crossed the retrieval boundary.
The more common version checks authorization after documents have already been retrieved. Once restricted content has been hydrated, reranked, summarized, or cached outside the retrieval boundary, authorization becomes reactive rather than preventive. AWS's own guidance identifies the broad-credential version as a single point of failure because a prompt injection or a filtering bug can expose the entire dataset. If the content reached a model, the model has already processed something the user was never authorized to access, and any bug or injected instruction in that window can act on it.
The defense teams typically deploy first can backfire. Researchers Jiale Liu, Jiahao Zhang, and Suhang Wang at Penn State red-teamed graph-based retrieval and discovered that summarization reduces leakage in untargeted attacks but increases it in targeted attacks. The likely explanation is that summarization preserves salient details, and salient details are usually sensitive ones. A separate 2026 preprint identified cross-tenant leakage in pipelines transitioning from vector search to a graph, and eliminated it by re-checking authorization at every transition. Two individually secure components can still compose an insecure system when authorization does not get re-verified at the boundary between them.
Two individually secure components can still compose an insecure system when no one re-checks authorization at the transition between them.
The seventeen-hour gap described earlier is the same failure playing out slowly. Direct shares, nested groups, and public links change independently, which is why Google built Zanzibar as a relationship model rather than a static list. A list of authorized users stamped on each chunk represents a snapshot of a graph that evolved without notification.
This is no longer a niche concern. The OWASP Top 10 for LLM Applications elevated sensitive information disclosure from sixth to second place in its 2025 revision and introduced LLM08, Vector and Embedding Weaknesses, which identifies the risk of context leaking between users sharing a vector database and recommends a permission-aware store as the solution.
The enterprise-scale example is Copilot. During the first year of its enterprise deployment, a 2024 Gartner survey of 132 IT leaders found that excessive sharing caused 40 percent to postpone Microsoft 365 Copilot rollouts by 3 months or longer. This example is instructive because Copilot is not the culprit. Microsoft verifies the user's permissions at query time, and its documentation states that results are filtered to content the signed-in user is authorized to access. Copilot shows what those users were already permitted to view.
A surprising amount of enterprise data stays private mainly because it is hard to find, and retrieval is very good at finding things.
The exposure existed all along. Much enterprise data remains confidential simply because discovery is difficult, and retrieval systems excel at finding things.
Where identity must be resolved
The Copilot lesson demonstrates that resolving identity at assembly is necessary but insufficient. Assembly inherits whatever the permission graph actually contains. If the graph is incorrect, stale, or overly permissive, the retrieval system will faithfully enforce the wrong answer. Custom-built retrieval systems can inherit the same problem, often with less governance infrastructure.
This does not undermine the case for assembly. It clarifies it. Assembly does not make permissions correct. It is the final moment where correct permissions still matter, because after that point the model has read the document.
This is not a novel observation. AWS argues a version by governing the graph with permissions the lake already enforces. OWASP reached the same conclusion from the security angle, and its recommended fix for LLM08 is a store that knows who is asking rather than a check that happens afterward.
The addition comes from observing enterprise products transition from pilot to production. Many architectural decisions can be deferred during a demonstration. This one cannot be postponed long. Eventually someone asks who can see what, who guarantees it, how quickly permission changes propagate, and who owns the answer when three systems disagree. That moment often transforms an impressive AI pilot into a security initiative, and it frequently begins with something like an intern's innocent question.
Four questions deserve consideration from any team building this capability.
- Whether identity gets resolved at assembly or after retrieval.
- How much context lives outside the lake, in chat, tickets, and documents, where IAM does not apply.
- What the worst-case staleness window looks like when someone changes teams.
- Whether authorization can be re-checked at every step along the way, or only once at the entry point.
If those answers are uncomfortable, that discomfort is valuable. Few of these conversations produce comfortable answers.
Source: The New Stack