Why Permissions Must Be Built Into How AI Systems Assemble Context
As enterprises deploy retrieval-augmented generation at scale, the timing of permission checks has become critical—and most teams are doing it wrong, leaving sensitive data exposed to models that should never see it.
A finance employee leaves their team at 9 a.m. on a Monday morning. The system's synchronization job runs at 2 a.m. the following day. During those seventeen hours, that person can still extract finance documents from the retrieval system, and no component in the architecture recognizes the problem. This scenario comes from Truto, but variations of it appear in conversations with nearly every organization building retrieval systems. The version with a time component is straightforward. The version that surfaces in security reviews takes a different form: a retrieval pilot succeeds, the demonstration impresses stakeholders, an executive sponsor approves it, and then someone raises the question of whether the system could inadvertently summarize the chief executive's compensation package for an intern asking a general question about salary ranges.
Most organizations lack a clear answer. What they typically have instead is a filter applied after the fact.
The solution must be architectural rather than procedural. Permissions should not function as a layer applied to context once it has been gathered. Instead, they should define the mechanism through which context gets assembled for a particular user, at a particular time, in response to a particular request. Assembly represents the final moment when excluding information still prevents the model from ever encountering it.
Permissions are not a filter you apply to context after you have assembled it.
The leading platform providers are implementing versions of this same architectural layer, though consensus on terminology has not yet emerged. Modus, a company in this space, refers to it as context composition. For this discussion, the term context assembly describes the moment when a system determines which pieces of organizational knowledge to provide to a model for a specific individual, at a specific time, addressing a specific question. Everything before this point is storage; everything after is inference. Assembly is where identity either functions or fails.
Announced is not the same as shipped
The timing of this discussion in September rather than June matters because platform vendors have reached consensus on where this architectural step belongs, yet the software running in most enterprises has not caught up.
AWS presented the clearest articulation in June, unveiling AWS Context at its New York Summit. The underlying design choice is what merits attention. The knowledge graph operates under the same permissions that govern the data lake through Glue Data Catalog, SageMaker Unified Studio, and Lake Formation, with identity verification occurring again when a user submits a query. The administrators who would manage this are the same ones already managing everything else, using the column-level, row-level, and cell-level policies that S3 object permissions alone cannot enforce.
Precision about timing matters here, as the narrative has already become muddled. Every description states the system is "designed to inherit the calling user's IAM and Lake Formation permissions, so an agent can only see and traverse the relationships its identity is authorized to access." Designed to. This language indicates a future roadmap, and nearly three months after the announcement, AWS Context remains listed as coming soon, with no general availability date, no list of supported regions, and no published pricing. Amazon Bedrock Managed Knowledge Base did achieve general availability on that same day, which explains why the two offerings have become 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 released Work IQ API to general availability. The API operates within the context of the authenticated user, respects Microsoft 365 permissions, is charged through Copilot Credits, and an administrator can activate it immediately. Two announcements separated by a single day, identical architectural approaches, and only one is deployable in production environments today.
Databricks approached the same architectural position from a different angle, adding identity-aware capabilities to Unity Catalog for agents. However, ecosystem partners note that the protection depends on the Databricks Runtime rather than on the data itself, which means the protection disappears when a business intelligence tool or an MCP server accesses the same source independently.
Organizations did not wait for these solutions to mature. They deployed the simplified flat-index approach while the identity-aware version remained on presentation slides.
The direction across vendors is consistent, as is the limitation. Each of these permission systems operates most effectively within the environment that created it. The genuine challenge emerges when an agent requires context spanning multiple systems simultaneously, and that is the problem context assembly must address.
The lake is not the business
Lake Formation enforces granular permissions within the data lake it manages, and it performs this function effectively. However, those permissions do not automatically become the sharing mechanisms in Salesforce, Slack, Google Drive, or Confluence.
AWS has documented where its own responsibilities end. Its August guidance on passing user authorization context through AgentCore describes providing Salesforce with a token scoped to the actual user, allowing Salesforce to apply its own sharing rules. According to AWS's explanation, "the agent acts as an orchestrator, not a gatekeeper," and "downstream services enforce authorization."
This represents a sensible architectural decision and a significant product boundary. Lake Formation is not integrating with Salesforce, GitHub, Jira, Slack, Confluence, or Google Drive. Each system independently determines access rules, or none of them do.
The most important statement concerns the filter itself. In that same security guidance, AWS explicitly 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 warrants repeated attention because it represents a vendor clearly delineating where its guarantees conclude and where yours begin.
The same principle applies to custom implementations. The labels attached to your data chunks are not an identity boundary. They represent a suggestion that your application code is expected to respect.
What breaks when authorization arrives too late
The failure stems from architecture, which is why the same patterns appear repeatedly.
Clarity is important here. The argument is not that "filters are bad." The issue is sequence. A retrieval system can search across a combined index, retrieve opaque identifiers, verify authorization, and load only documents the user is permitted to access. This is a filter, and it functions correctly because unauthorized material never crosses the retrieval boundary.
The more common pattern performs the authorization check after documents have already been retrieved. Once restricted content has been loaded, reranked, summarized, or stored outside that boundary, authorization becomes reactive rather than preventive. AWS's own guidance identifies the broad-credential version of this as a single point of failure because a prompt injection attack or a bug in the filtering code could expose the entire dataset. And if the content reached a model, the model has already processed something the user was never authorized to access, with any bug or injected instruction in that window able to exploit it.
The most common defensive approach can actually worsen the situation. Researchers at Penn State—Jiale Liu, Jiahao Zhang, and Suhang Wang—tested graph-based retrieval systems and discovered that summarization reduces leakage in random attacks but can increase it in targeted attacks. The likely explanation is that summarization preserves the most important details, and the most important details are typically the most sensitive ones. A separate 2026 preprint identified cross-tenant leakage in systems that transition from vector search to graph traversal, and resolved it by re-verifying authorization at every transition. Two components that are individually secure can still form an insecure system when authorization is not re-checked 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 window described at the beginning represents the same failure operating at a slower pace. Direct shares, nested groups, and public links all change independently, which is why Google designed Zanzibar as a relationship model rather than a static list. A list of permitted users attached to each chunk represents a snapshot of a graph that has shifted without notification.
This is no longer a niche concern. The OWASP Top 10 for LLM Applications moved sensitive information disclosure from position six to position two in its 2025 update 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 storage system as the solution.
The large-scale enterprise example is Copilot. During the first year of enterprise deployment, a 2024 Gartner survey of 132 IT leaders found that excessive sharing caused 40 percent to postpone Microsoft 365 Copilot rollouts by three months or longer. This example is instructive because Copilot is not the source of the problem. Microsoft verifies the user's permissions at query time, and its documentation states that results are restricted to content the authenticated user has permission to access. Copilot displays what those users were already authorized 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. A substantial portion of organizational data remains protected primarily because it is difficult to locate, and retrieval systems excel at locating things.
Where identity has to arrive
The Copilot example demonstrates that resolving identity at assembly is necessary but insufficient. Assembly inherits whatever the permission graph actually contains. If the graph is incorrect, outdated, or overly permissive, the retrieval system will faithfully enforce the incorrect answer. Custom-built retrieval systems can inherit the same issue, frequently with less governance infrastructure.
This observation does not undermine the case for assembly. It clarifies it. Assembly is not what ensures your permissions are correct. It is the final point where correct permissions still have effect, because after that moment the model has read the document.
This concept is not original. AWS is making a version of this argument by governing the graph using the permissions the lake already enforces. OWASP reached the same conclusion from a security perspective, and its recommended solution for LLM08 is a storage system that understands who is requesting information rather than a check that occurs afterward.
The contribution comes from observing how enterprise products transition from pilot to production. Many architectural decisions can be deferred during a demonstration. This one cannot be postponed for long. Eventually someone asks who can access what, who provides the guarantee, how quickly permission changes take effect, and who is responsible when three different systems provide conflicting answers. This is frequently the moment when a successful AI pilot becomes a security initiative, and it typically begins with something resembling an intern's question.
Four questions should be posed to any team constructing this system.
- Whether identity gets resolved at assembly or following retrieval.
- How much of your context exists outside the lake, in messaging platforms, ticketing systems, and documentation, where IAM cannot reach.
- What your maximum acceptable staleness window is when someone changes teams.
- And whether you can re-verify authorization at every step in the process, or only once at the entry point.
If those answers provoke discomfort, that is valuable information. Few of these conversations have produced comfortable answers.
Source: The New Stack