Secure enterprise retrieval augmented generation platform
Retrieval augmented generation lets a model answer from an organization's own documents rather than from its training alone. The promise is real, and so is the risk, because the moment a model can read private data, the platform has to make sure it only reads what the asking person is allowed to see, that nothing sensitive leaves the network, and that the answers are grounded and not invented. This reference architecture does that across two Canadian regions, on Amazon Bedrock, with access controls carried from ingestion through to retrieval, guardrails on both ends, and citations on every answer.
The simplest approach is easy to build and unsafe in practice. It points a model at a large document set, lets anyone ask anything, and relies on the answers being correct and on no one seeing what they should not. A careful design treats retrieval as a security boundary. The question of which passages may be returned to a given user is answered at retrieval time from access controls captured when the documents were ingested, the inference happens entirely on the private network, the input and the output are both inspected, and every answer carries the sources it was built from so a person can check it.
Requirements
The requirements the platform has to satisfy, the quality attributes it is judged on, the constraints it must respect, and the assumptions it rests on.
Functional requirements
| Number | Requirement |
|---|---|
| 1 | Ground answers in the organization's private documents. |
| 2 | Return only the passages that the asking user is permitted to see. |
| 3 | Inspect questions and answers for prompt attacks and for personal data. |
| 4 | Cite the sources used in every answer. |
| 5 | Keep all data and all inference on the private network. |
| 6 | Continuously evaluate the quality and grounding of answers. |
| 7 | Serve the same knowledge from two regions. |
Quality attributes
| Number | Attribute | Intent |
|---|---|---|
| 1 | Security | A private network path, access controlled retrieval, and guardrails on both ends. |
| 2 | Grounding | Answers traceable to sources, with fabrication kept low. |
| 3 | Auditability | Record the question, the sources retrieved, and the answer, retained for at least one year. |
| 4 | Reliability | Tolerate the loss of an availability zone, and a region within the recovery objective. |
| 5 | Freshness | New and changed documents reflected in retrieval quickly. |
| 6 | Cost efficiency | Retrieve and generate in proportion to use. |
Constraints and assumptions
| Number | Constraint |
|---|---|
| 1 | Data residency in Canada and the two approved regions. |
| 2 | The platform sits inside the landing zone production segment. |
| 3 | Personal and confidential data must never leave the private network. |
| 4 | Document level access controls must be honoured at retrieval time. |
| Number | Assumption |
|---|---|
| 1 | Source documents carry, or can be assigned, access metadata. |
| 2 | Users authenticate and their entitlements are known at query time. |
| 3 | Foundation and embedding models are consumed through Amazon Bedrock. |
Architecture decisions and rationale
The decisions that shaped the platform, each with the alternative that was set aside and the cost that was accepted.
1. Managed retrieval with Bedrock Knowledge Bases rather than a hand built pipeline
Decision. Use Amazon Bedrock Knowledge Bases to chunk, embed, and index the documents and to perform retrieval.
Alternatives. Building the chunking, embedding, indexing, and retrieval as custom code over a self managed vector store.
Rationale. The managed service handles the parts that are easy to get subtly wrong, including chunking strategy, embedding, and source attribution, which removes a large amount of code and lets the effort go into the security and the evaluation. This serves functional requirements 1 and 4.
Consequences. The design depends on a managed service, accepted because retrieval plumbing is not where the organization's value lies.
2. Access tags carried from ingestion to retrieval rather than filtering after the fact
Decision. Capture the access controls of each document at ingestion as metadata on every passage, and filter on them at retrieval time so only permitted passages are ever returned.
Alternatives. Retrieving freely and trying to filter the answer afterwards, or relying on the model not to reveal what it should not.
Rationale. The only safe place to enforce who can see what is at retrieval, before the passages reach the model, because once a passage is in the prompt it is effectively disclosed. This serves functional requirement 2 and constraint 4.
Consequences. Ingestion must record access metadata accurately, which is the foundation the whole control rests on.
3. Guardrails on input and output rather than trusting the model
Decision. Apply Bedrock Guardrails to the question on the way in and to the answer on the way out.
Alternatives. Relying on the model's own behavior to refuse attacks and to avoid leaking personal data.
Rationale. A guardrail catches prompt attacks before they reach the model and catches personal data before it reaches the user, consistently and independently of the model. This serves functional requirement 3 and the security attribute.
Consequences. Two inspection steps per query, a small and bounded cost.
4. Everything on the private network rather than over the internet
Decision. Run the application and reach Amazon Bedrock, the vector store, and the documents over private endpoints inside the production segment, with no internet path.
Alternatives. Calling the services over their public endpoints.
Rationale. Keeping the data on the private network removes a whole class of exposure and satisfies the residency and confidentiality constraints. This serves functional requirement 5 and constraint 3.
Consequences. Private endpoints must be provisioned, which the landing zone shared services already provide.
5. Grounded generation with citations rather than free generation
Decision. Instruct the model to answer only from the retrieved passages and to cite them, and return the citations with the answer.
Alternatives. Letting the model answer from its training and the context together without distinguishing them.
Rationale. Grounding the answer in retrieved sources and showing them lets a person verify it and keeps fabrication low, which is what makes the answers usable in a regulated setting. This serves functional requirement 4 and the grounding attribute.
Consequences. The model occasionally has to say it does not have enough to answer, which is the correct behavior.
6. Continuous evaluation rather than a one time test
Decision. Evaluate answer quality and grounding continuously on a sample of real traffic.
Alternatives. Testing quality once before launch and assuming it holds.
Rationale. The documents, the questions, and the models all change over time, so quality has to be watched continuously to catch regression. This serves functional requirement 6.
Consequences. An evaluation pipeline runs alongside the platform, a modest and worthwhile cost.
7. The same knowledge in two regions rather than one
Decision. Replicate the source documents to the second region, rebuild the index there, and serve from a warm standby.
Alternatives. Serving from a single region.
Rationale. The standby must answer from the same knowledge with the same guardrails and the same keys, so a failover does not change what the platform knows or how it is controlled. This serves functional requirement 7 and the reliability attribute.
Consequences. The index is maintained in both regions, kept current as documents change.
Ingestion
Everything starts with the documents, and the security of the platform is decided here. Source files arrive in encrypted object storage, their access controls are captured as metadata, and then Bedrock Knowledge Bases chunks them into passages, embeds the passages, and indexes them in a vector store, with the access tags travelling with each passage. Because the tags are recorded at ingestion, retrieval can later return only what a given user may see.
The query path
A question travels a fixed path inside the production network. The user's entitlements are checked so only permitted sources are searched, the question is inspected, the most relevant passages are retrieved and reranked, the model generates an answer grounded in them with citations, and the answer is inspected before it is returned. None of it touches the public internet.
The access control is enforced in the retrieval call itself, by filtering on the access metadata, so passages the user may not see are never even considered. A representative retrieval applies a hybrid search and a filter on the user's groups.
{
"knowledgeBaseId": "kb-payments-policies",
"retrievalQuery": { "text": "what is the chargeback window for a card present sale" },
"retrievalConfiguration": {
"vectorSearchConfiguration": {
"numberOfResults": 8,
"overrideSearchType": "HYBRID",
"filter": {
"in": { "key": "access_group", "value": ["payments-ops", "all-staff"] }
}
}
}
}
Across two regions
The platform serves from both regions. The source documents replicate between them, the index is rebuilt in each, the guardrail policy and the keys are the same in both, and Amazon Route 53 directs questions to the healthy region. A failover therefore changes neither what the platform knows nor how it is controlled.
The discipline that makes this safe is the same one that runs through the whole collection. The important property is not simply that a model can answer from private data. It is that the platform can prove the answer came from sources the person was allowed to see, that nothing sensitive left the network, and that the answer can be checked against its citations. That is what makes the platform suitable for a regulated organization to put in front of its people, rather than only a demonstration.
References
- Amazon Web Services, Amazon Bedrock Knowledge Bases.https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html
- Amazon Web Services, Amazon OpenSearch Serverless vector search.https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vector-search.html
- Amazon Web Services, Amazon Bedrock Guardrails.https://aws.amazon.com/bedrock/guardrails/
- Amazon Web Services, metadata filtering for Knowledge Bases.https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-config.html
- Amazon Web Services, evaluation for Amazon Bedrock.https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html
- Amazon Web Services, use Amazon Bedrock through a private network with AWS PrivateLink.https://docs.aws.amazon.com/bedrock/latest/userguide/usingVPC.html
- Amazon Web Services, Amazon Route 53 Application Recovery Controller.https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route-53-recovery.html