Bedrock Guardrails: A Grounding Reference Is Not Automatically Filtered

Conceptual, untested design note. Official AWS documentation reviewed October 5, 2026. No guardrail was created, API request sent, or detection rate measured for this article.

A document can help establish whether an answer follows its source without having been checked by the other safeguards you configured. That distinction deserves its own review in a document-based question-answering application.

1. Name the two questions

“Is the answer supported by this reference?” and “Should this reference pass our content policy?” are different questions. A faithfully repeated sentence can still be unsuitable to show. Conversely, a harmless answer can introduce an unsupported fact.

AWS contextual grounding checks evaluate grounding against reference material and relevance to a query. The current documentation lists summarization, paraphrasing and question answering as supported use cases, and excludes conversational QA/chatbots. This note considers one independent question and answer, not a multi-turn chat workflow.

2. Make coverage explicit

For ApplyGuardrail, a text block qualified only as grounding_source or query supplies contextual information; it is excluded from the other guardrail policies. Adding guard_content alongside that qualifier requests both roles. An unqualified block, or one marked guard_content, is evaluated as the response and by the other configured policies.

The qualifiers array is part of GuardrailTextBlock. This is not the XML-tag syntax used with Invoke APIs. Do not move an example between API surfaces without checking the corresponding request structure.

Here is an illustrative ApplyGuardrail request body, not an executed request:

{
"source": "OUTPUT",
"content": [
{
"text": {
"text": "The museum opens at 09:00 on weekdays.",
"qualifiers": ["grounding_source", "guard_content"]
}
},
{
"text": {
"text": "When does the museum open on weekdays?",
"qualifiers": ["query", "guard_content"]
}
},
{
"text": {
"text": "It opens at 09:00 on weekdays.",
"qualifiers": ["guard_content"]
}
}
]
}

This body alone is not a runnable configuration. The API also requires a guardrail identifier and version in the request path, an authorized caller, and the desired policies configured in that guardrail. ApplyGuardrail assesses supplied content without invoking a foundation model.

3. Review the application path, not just the final answer

Consider a hypothetical museum FAQ service. The application retrieves an approved opening-hours document, generates a candidate answer, and evaluates the candidate with its source and query before displaying anything.

A proposed review checklist would identify which component chooses the document, which text reaches the model, and which blocks reach each guardrail check. Explicit qualifiers make that map easier to audit; they do not establish that the retrieved document is correct, current or authorized for the requester.

Checking the reference during an OUTPUT assessment also does not undo its earlier exposure to a model. If the application requires pre-generation screening, design a separate checkpoint before generation. Decide how that checkpoint handles blocked or modified source material, and preserve the intended question-answering semantics. This is an architectural proposal, not a claim that the example implements that checkpoint.

4. Test coverage before tuning thresholds

A proposed test set should vary one boundary at a time:

• Hold the candidate answer constant and change only the reference qualifiers. Confirm the intended policies actually assess the reference.
• Repeat that comparison for the query.
• Supply a harmless but unsupported answer, then a supported answer to the wrong question. Keep grounding and relevance failures separate.
• Use synthetic policy-triggering reference material and a harmless answer. Check whether the reference is blocked or transformed as intended; never use real personal data for this exercise.
• Exercise an API error or timeout. Specify whether the application withholds the unassessed candidate instead of displaying it accidentally.

Record the selected guardrail version, enabled policies, exact block roles, assessments and application decision. ApplyGuardrail returns action, assessments and coverage information; these are evidence for investigation, not proof that every risk was detected. Avoid logging raw sensitive material while collecting that evidence.

The practical takeaway is to review reference roles and safeguard coverage as separate design decisions. A grounding check is useful only within its documented scope, and an apparently clean answer does not demonstrate that every upstream block was inspected.

Official references

Contextual grounding checks and qualifier coverage:
https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-contextual-grounding-check.html

GuardrailTextBlock schema:
https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_GuardrailTextBlock.html

ApplyGuardrail API request and response:
https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ApplyGuardrail.html

Independent ApplyGuardrail integration:
https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-use-independent-api.html