Retrieved documents are passed to a model.
Malicious instructions inside a document must not execute.
Choose two controls.
Mark retrieved text as untrusted evidence separate from system constraints, validate output, and authorize tools independently.
Detailed explanation
Retrieval does not grant trust or permission.
Document text cannot redefine policy.
External data can override constraints.
Model interpretation is not access control.
Check official documentation
Compare the following points with the official documentation.
Review Task 5.1, trust boundaries, and the documented prompt-attack filter scope. For a hypothetical instruction arriving in a search document or tool result, identify where trusted policy, permitted tools, and target-resource permissions are checked.
Official references
What to confirm
Keep retrieved or tool-returned text out of authorization decisions, and explain independent runtime checks and filter coverage.
Key points
- Document injection
- Trust boundary
- Authorization
Notes
- Environment: Reference review of official documentation and hypothetical examples; no AWS API calls, business data access, or downstream execution are required.
- The Bedrock documentation states that the prompt-attack filter does not evaluate toolResult content or toolSpec definitions. Enabling Guardrails does not mean every tool path is inspected.
- Even for an allowed tool, check the resource and action specified by its arguments. A valid schema or model-generated permission flag is not sufficient authorization.
Foundation review
Independent runtime authorization
The execution layer checks a trusted principal, action, and target rather than accepting the model's explanation or a retrieved permission claim.
Tool-result trust boundary
Treat returned content according to its external-data role. Text returned by a tool does not automatically gain authority to change policy or permissions.