AWSAWS Certified Generative AI Developer - Professional2026-101.4 Design and implement vector store solutions
Enforce tenant access before model context
Completed by the knowledge check
Learning objective
Apply permission-aware metadata filtering and enforce tenant isolation outside the FM.
Core idea
Authorization must decide which evidence the application can retrieve and use before an FM receives it. A prompt asking the model to ignore another tenant’s documents does not create a security boundary. Once unauthorized text enters model context, the retrieval boundary has already failed, even if the final answer happens to omit it.
Build mandatory scope from authenticated application context and authoritative permissions. Apply that scope to retrieval, then verify returned candidates before constructing the generation request. Metadata filtering narrows candidates; service permissions restrict who can call retrieval; the application connects those mechanisms to an end user’s entitlement.
AWS warns that all data you sync from a data source becomes available to anyone with bedrock:Retrieve permissions, including data whose source permissions were controlled. Do not assume an S3 document’s original access policy automatically follows its chunks into the vector store.
How it works
Bind retrieval scope to a trusted caller
The application authenticates the request and resolves its tenant and document-access policy from trusted state. Never accept a client-supplied tenant identifier as the complete authorization decision. If the caller selects a tenant, verify that the authenticated principal is entitled to that tenant before using it.
Keep the retrieval role behind the server-side application. A caller with direct access to a shared knowledge base can omit the application’s filter, so merely teaching the browser to send tenant_id is insufficient. Restrict direct retrieval access to the controlled path that constructs and enforces the mandatory scope.
Distinguish the knowledge-base service role from the application caller. The service role enables ingestion and storage access. The caller’s retrieval permissions enable a runtime request. Neither role, by itself, maps an individual application’s user to document-level business entitlements.
Use explicit application fields such as tenant_id, acl_policy_id, and acl_revision from the validated ingestion contract; see 1.4.5. A record missing a mandatory access field should not enter an accepted publication set. A query must fail closed if the caller’s authorized scope cannot be established.
Construct a mandatory metadata filter
For a vector knowledge base, Retrieve accepts the filter under retrievalConfiguration.vectorSearchConfiguration.filter. RetrievalFilter is a union: each filter object contains one member. Compose conditions through andAll or orAll; both require at least two members.
For an OpenSearch Serverless-backed knowledge base, a server that resolves one allowed tenant and several allowed policy identifiers can construct this request fragment:
{
"retrievalConfiguration": {
"vectorSearchConfiguration": {
"filter": {
"andAll": [
{ "equals": { "key": "tenant_id", "value": "tenant-a" } },
{
"in": {
"key": "acl_policy_id",
"value": ["policy-team", "policy-public"]
}
}
]
}
}
}
}The tenant and policy values are illustrative server-resolved values, not values to trust from query text. equals matches the scalar tenant attribute; in matches a scalar policy attribute against the permitted alternatives. A policy named policy-public still sits inside the tenant constraint in this example.
Keep optional relevance filters subordinate to mandatory access scope. A domain or date preference can further narrow allowed evidence through conjunction. It must not replace the tenant filter or broaden access through an incorrectly placed orAll. For genuinely shared documents, define an explicit shared-access branch whose entire predicate is reviewed as an authorization rule.
Use positive inclusion conditions. AWS documents that notEquals also returns documents where the key is absent. Therefore, “tenant is not tenant-b” is not equivalent to “tenant equals tenant-a” and can admit unclassified records. Missing metadata is especially dangerous when exclusion logic is treated as isolation.
Scope operators to the selected backend. For example, the Bedrock RetrievalFilter reference restricts startsWith to OpenSearch Serverless. Do not turn tenant prefixes into an implicit hierarchy when exact tenant identifiers will work. Verify operator support and metadata types against your configured destination before publishing the filter contract.
Verify authority before generation
Retrieve returns content, location, metadata, and score in retrievalResults. Use document and revision identifiers to check the authoritative access record. Compare tenant, content state, and permission revision before passing any chunk to the generation request. The index’s ACL projection can be stale after an access change; see 1.4.4.
Check revocation against the authoritative table read, not an eventually consistent projection; see 1.4.4.
This extra validation is an application decision when your access semantics require it. A separate Retrieve step gives the application a point to examine evidence before generation. A combined retrieval-and-generation call does not provide that same intervening application check; use it only when the pre-retrieval controls already satisfy the required boundary.
Reject unauthorized or unresolvable candidates without forwarding them to generation. If filtering leaves no usable evidence, return a safe no-evidence outcome. Do not retry with a weaker tenant filter to improve answer coverage. Also scope conversation state and application caches to the access context so a result from a broader permission set is not reused after revocation.
Every path to the generation request passes the authorized scope, the mandatory filter and the authoritative check.
Add store-level controls where appropriate
For an application-managed OpenSearch Service domain, fine-grained access control supports index-, document-, and field-level permissions with role mappings. It acts after the domain’s network and access-policy checks. These layers protect different boundaries and need a consistent review.
A role shared by all application requests still represents that shared service identity to the store. It does not automatically carry the end user’s per-document entitlement. Apply the application’s mandatory tenant and permission predicates even when store-level controls provide defense in depth.
OpenSearch Dashboards multi-tenancy is another distinct capability. Do not treat separation of dashboard workspaces as proof that your application’s document retrieval is isolated. Select physical separation, index-level permissions, or shared-index filtering from the boundary your application actually needs.
Key distinctions and trade-offs
Service authorization versus document authorization: Permission to invoke retrieval is broader than permission to use each returned document. Bind the latter to trusted business policy.
Relevance versus eligibility: Similarity ranks candidates within the allowed set. It cannot make an otherwise forbidden chunk eligible.
Explicit versus inferred filters: vectorSearchConfiguration.implicitFilterConfiguration uses metadataAttributes schemas and modelArn to generate a filter from the query. It can add relevance filters; the mandatory tenant and permission predicate stays in the explicit filter, independent of the model’s interpretation.
A shared index can reduce duplicated ingestion but requires reliable predicates and revocation handling. Separate tenant resources can make some boundaries easier to enforce, while increasing provisioning and operations. Neither choice removes the need to verify the caller and the evidence policy.
Architecture / decision scenario
A support assistant serves tenant A and tenant B from a shared knowledge base. Each has public support material and restricted escalation notes. The application resolves the caller’s tenant and allowed policy identifiers, then sends an andAll filter requiring that tenant and one allowed policy.
A malicious question asks for tenant B’s escalation notes. The request text cannot change the filter. Returned candidates still undergo a document-policy lookup before generation. When a support engineer loses access to escalation notes, the authoritative revision check excludes stale indexed chunks while metadata synchronization catches up.
The team tests an absent tenant attribute, a forged client tenant, a missing filter, an access revocation, and a cache entry created under broader permissions. A test passes only if unauthorized content never enters the generation request, not merely when the final answer avoids quoting it.
Common exam traps
- Asking the FM to enforce tenant isolation after retrieval.
- Assuming source permissions are inherited by synchronized knowledge-base chunks.
- Trusting a client-provided tenant filter or exposing direct shared retrieval access.
- Using
notEqualsas though it required the attribute to exist. - Placing an optional
orAllbranch outside mandatory access scope. - Weakening filters when authorized retrieval returns no evidence.
What to remember
- Resolve access scope from trusted caller and policy state.
- Enforce mandatory positive predicates before retrieval.
- Validate candidate authority before constructing model context when required.
- Treat revocation, caches, and conversation state as part of isolation.
- Test the evidence boundary as well as the final answer.
Knowledge check
A multi-tenant support assistant sends each question to its server, which calls Retrieve on a shared knowledge base. The browser includes a tenant_id in every request. Where should the server take the tenant for the mandatory filter from?
tenant_id the browser sends, because the user has already signed inA shared knowledge base isolates tenant A with the filter notEquals tenant_id "tenant-b". Some records were ingested without a tenant_id. What filter should replace it?
equals tenant_id "tenant-a" , for the tenant resolved for the callernotEquals conditions for every other known tenant, joined by andAllnotEquals tenant_id "tenant-b" , with unlabeled records treated as publicstartsWith tenant_id "tenant" , so that every labeled record is includednotEquals also returns documents where the key is absent, so exclusion logic admits unclassified records — and a list of exclusions still does. A positive equality on the authorized tenant never turns missing metadata into access.A developer adds a preference for FAQ content to the retrieval filter. The new filter is orAll of equals tenant_id "tenant-a" and equals domain "faq". What is wrong, and what is the fix?
orAll keeps the tenant condition in the filterorAll needs three members, so a policy condition should be added to itandAllorAll , any FAQ chunk matches, whatever its tenant, so a relevance preference has broadened access. Optional relevance conditions narrow the allowed set through conjunction with the mandatory tenant predicate; they never sit beside it as an alternative.A user’s access to escalation notes was revoked a minute ago, and the index still holds the older ACL revision. The application requires a current-authority check before any chunk reaches the model. Which design meets that requirement?
RetrieveAndGenerate with the tenant filter, then a scan of the answer for leaked textRetrieve with the tenant filter, an authority check per chunk, then generationRetrieveAndGenerate with the tenant filter, until the next sync updates the ACLRetrieve with the tenant filter, and an instruction telling the model to skip notesRetrieve call gives the application a point to compare each candidate’s document and ACL revision with the authoritative record before building the request. Once unauthorized text enters model context the boundary has failed, whatever the answer says, and a combined call leaves no step in between.Analysts are given bedrock:Retrieve on a shared knowledge base synced from S3, so they can query it directly. The team assumes the S3 bucket policies still limit which documents each analyst sees. What is the actual exposure?
bedrock:Retrieve , including data whose source permissions were controlled. Direct callers can also omit the application’s filter, so retrieval access belongs to the server-side path that builds and enforces the mandatory scope.