Recent vendor announcements have shifted the way AI agents retrieve enterprise data. Instead of pulling a broad set of documents and then applying a permission filter, the emerging pattern builds the permission check into the very step that assembles context for the model. This “context assembly” approach ensures that an LLM never sees data the caller is not authorized to access.
What Changed: From Post‑Retrieval Filters to Permission‑Aware Assembly
Historically, retrieval pipelines would first gather candidate chunks, then run an authorization filter before passing the allowed pieces to the model. The source points out that this ordering leaves a window where the model can be exposed to disallowed content. The new model treats identity as a first‑class input to the assembly process, selecting only those pieces that the caller’s permissions allow. Vendors are naming this step variously – AWS calls it “Context”, Microsoft refers to “identity‑aware retrieval”, and Databricks extends Unity Catalog to agents – but the core idea is the same: permissions are a property of the assembly, not a downstream filter.
Why It Matters for AI, Cloud, DevOps, and Security Engineers
For AI engineers, the change eliminates a class of data‑leakage bugs that arise when a model ingests unauthorized text. Cloud and platform engineers must now provision services that can propagate identity (IAM, Lake Formation, Microsoft 365 permissions) into the retrieval layer. DevOps and SRE teams will see new operational metrics around context‑assembly latency and failure modes tied to permission mismatches. Security engineers gain a clearer boundary – the data source, not the application code, enforces the rule – but also a new responsibility to verify that the assembly step truly respects the source policies.
Architectural and Operational Implications
Implementing permission‑aware assembly requires several concrete adjustments:
- Identity propagation. The retrieval request must carry the caller’s security context (e.g., IAM role, Microsoft 365 token) so downstream services can evaluate fine‑grained policies such as column‑, row‑, or cell‑level controls.
- Policy‑driven data catalogs. Services like AWS Glue Data Catalog, SageMaker Unified Studio, and Lake Formation are used to map permissions to data assets. The same catalog is consulted during assembly, not after.
- Cross‑service orchestration. When an agent needs data from multiple SaaS platforms (Salesforce, Slack, Confluence, etc.), the orchestrator must hand each service a token scoped to the original user, letting each system enforce its own sharing rules.
- Boundary awareness. AWS explicitly states that its Bedrock :Retrieve API performs only application‑layer metadata filtering; the guarantee ends at the orchestrator. Similarly, Databricks’ protection is tied to the runtime, not the underlying data store, so direct BI queries can bypass it.
- Operational monitoring. Teams should instrument both the assembly step (to detect permission denials) and downstream inference (to ensure no fallback to unfiltered data).
From a deployment perspective, note that Microsoft’s identity‑aware retrieval is already GA and can be enabled today, while AWS’s Context remains “coming soon” with no GA date. Databricks offers a partial solution that may not cover all access paths. Practitioners must therefore evaluate the readiness of each platform against their compliance timelines.
Related CloudNinjas coverage: AI engineering.
What This Means For Practitioners
Adopt a “permission‑first” mindset when designing retrieval pipelines. Verify that the service you choose can ingest the caller’s identity and enforce fine‑grained policies before any text reaches the model. If you are on AWS, treat the Context feature as a roadmap item and continue to rely on explicit token hand‑off to downstream SaaS services. On Microsoft 365, enable the Work IQ API now to get production‑grade identity awareness. For multi‑cloud or hybrid environments, map each data source’s native sharing model and ensure your orchestrator forwards the appropriate credentials.
In short, the shift to context assembly reduces the attack surface of LLM‑driven assistants, but it also introduces new integration points that must be built, tested, and monitored.
