Bedrock + Verified Permissions: Two-Layer Authorization for Multi-Tenant RAG

Every enterprise RAG deployment eventually hits the same wall: how do you keep the finance team from seeing HR documents, and HR from seeing legal documents, without standing up a separate knowledge base — and a separate infrastructure bill — for every department?

The Multi-Tenant RAG Problem

The naive implementation of enterprise RAG puts all documents in one knowledge base and trusts the application layer to filter results by department. This is the multi-tenant RAG equivalent of a row-level security problem — and like database row-level security, application-layer filtering alone is fragile. A bug in the application tier, a misconfigured query, or an unanticipated edge case can expose data across tenant boundaries.

The alternative — separate knowledge bases per department — solves the isolation problem but creates an operational one. Vector embedding costs, knowledge base management, and retrieval infrastructure all multiply with headcount. For organizations with dozens of departments, this becomes unworkable.

How the Two-Layer Pattern Works

The AWS architecture solves this with filter-level logical isolation: a single Bedrock Knowledge Base holds all department documents, but authorization controls which subset of documents each query can touch.

Layer 1 — API access: A Lambda Authorizer on API Gateway calls Amazon Verified Permissions to determine whether the requesting user is allowed to invoke the API at all. Denied requests return a 403 before anything reaches the knowledge base.

Layer 2 — Document access: A middleware Lambda independently evaluates which Knowledge Base resources the department can query. It constructs a metadata filter — derived from the user’s department attributes in their Cognito JWT — and passes that filter to the RetrieveAndGenerate API. Bedrock applies the filter during vector similarity search, which means unauthorized documents never reach the foundation model. They’re excluded before retrieval, not after.

Each layer operates independently. A misconfiguration in Layer 1 doesn’t affect Layer 2’s enforcement, and vice versa. The defense-in-depth principle holds: a single point of failure cannot expose cross-department data.

Cedar and Policy-as-Code

Amazon Verified Permissions uses Cedar, a purpose-built policy language designed for fine-grained authorization. Cedar policies are evaluated at runtime — a policy change (say, adding a new department, or granting an executive cross-department visibility) takes effect on the next API call without Lambda redeployment.

This matters for organizational agility. Restructurings, new hire onboarding, and incident response scenarios that require rapid access revocation all become policy changes rather than infrastructure changes.

The ingestion pipeline includes an important safeguard: before triggering knowledge base sync jobs, the system verifies every document has a metadata sidecar (a .metadata.json file containing department attributes). Documents without sidecars don’t enter the knowledge base. This prevents untagged content from bypassing the filter entirely.

What This Doesn’t Solve

The pattern provides logical isolation, not infrastructure-level isolation. If your threat model requires hard tenant boundaries between separate organizations — different customers, not different departments within one enterprise — you still need dedicated knowledge bases with IAM-enforced separation. The Verified Permissions pattern is correct for intra-organizational multi-tenancy, not inter-organizational.

Source: AWS Architecture Blog

Content created with AI assistance and reviewed for accuracy.