In a single-hop retrieval design the filter attaches in one place. Your code builds the query and appends the tenant predicate, and a reviewer can count the call sites. Agentic retrieval removes the count. The planner decides whether a question gets one lookup or a decomposition into sub-queries followed by several retrievals [8], so the number of places a filter must be present is chosen at runtime by something outside your codebase [1]. Every one of those hops has to carry it or isolation breaks [2].
AWS is precise about the other half of the requirement. The boundary must be enforced from a verified identity rather than a value sent by the client [1], and Cognito is the component that supplies that identity [10]. A tenant id in the request body is exactly what that sentence excludes, which is worth saying out loud, because it is also the cheapest thing to build.
The post states that built-in agentic retrieval honors access permissions on every hop [3]. It also lists per-user isolation among the responsibilities that stay with your application, next to authentication, the upload experience, and the chat UI [7]. Both readings can hold at once: the service enforces the attributes it is handed, and you own the correctness of the handoff [2]. The line I would want before signing this off is which component rejects a retrieval whose filter is missing, and the excerpt does not contain it.
For the every-hop guarantee to mean anything in your account, three properties have to hold. The identity-derived attribute travels in request context rather than in the question text. The planner cannot widen or drop it while rewriting sub-queries. A request that arrives without one fails instead of retrieving everything. None of those is something you can benchmark from outside; they are properties of a closed implementation, so you read the reference docs and then test behaviour with two tenants and a deliberately leaky question.
The write side has its own timing. Direct ingestion through the custom connector makes a document retrievable within seconds [5], with SQS between the upload endpoint and ingestion to absorb bursts and route repeatedly failing messages to a dead-letter queue [11], and DynamoDB holding per-document indexing status [12]. Seconds is quick enough that a document written with the wrong owner attribute is reachable by another user's next question well before anyone reads the status table.
What you stop operating is not trivial: a vector and full-text search engine, an ingestion pipeline that parses and embeds multiple modalities, and a synchronized index [13], with ingestion, storage, embedding and ranking managed and no capacity to monitor [4]. No capacity to monitor is a pleasant property right up to the moment you want a metric for how many hops actually ran. In my context the trade is worth making when the alternative is hand-building the index and the isolation logic around it, and worth making only once the binding between identity and filter is written down somewhere I can cite. That binding is an API-reference question, and this post is an architecture tour with a deployable repository attached [15].
