Amazon Bedrock Guardrails is a feature that applies safety policies to content entering and exiting generative AI. Here, HIGH means different things depending on the context. HIGH in settings refers to a strict inspection strength, while HIGH in results refers to a high confidence that the content is classified as belonging to a harmful category.
Therefore, the answer to “If I set the filter to HIGH, will it only block content detected as HIGH?” is no. Assuming a blocking action is used, a HIGH strength targets harmful content classified with LOW, MEDIUM, and HIGH confidence. However, increasing the inspection strength does not mean all inputs are inspected or all detections lead to actual blocking. Strength, action, and scope of inspection must be read separately. Official Filter Strength Description
Reading Settings and Results as Different Questions
Filter strengths, inputStrength and outputStrength, are values set by the operator. Different strengths can be set for input and response. For example, if the input is configured as HIGH and the response as MEDIUM, even with the same LOW confidence, the policy decision may vary depending on the inspection direction. Settings API
On the other hand, the confidence in the execution result indicates the degree to which specific content is classified as harmful content in a particular category. Since the same sentence can have different confidence levels across multiple categories, summarizing the entire request with a single value like “the confidence of this request is HIGH” loses the basis for judgment. It must be viewed together with the category type. The table below summarizes the relationships from the official documentation. Classification and Strength
| Configured Filter Strength | Harmful Confidence Targeted for Filtering | Confidence Allowed in that Category |
| — | — | — |
| NONE | None | NONE, LOW, MEDIUM, HIGH |
| LOW | HIGH | NONE, LOW, MEDIUM |
| MEDIUM | MEDIUM, HIGH | NONE, LOW |
| HIGH | LOW, MEDIUM, HIGH | NONE |
Interpreting HIGH in this table as “conservative detection that only accepts higher confidence” reverses the direction. When the setting is raised to HIGH, even lower harmful confidence levels fall within the filtering scope. This is a choice to filter out dangerous content more broadly. Since normal business sentences may also be affected more frequently, it is better to examine synthetic examples that should be allowed, rather than simply setting it to the maximum value.
LOW, MEDIUM, and HIGH are classification values exposed by the API. One should not infer internal probabilities or exact numerical boundaries solely from these names. Numbers like “HIGH is 90% or more” cannot be confirmed from this document and API fields alone.
The Meaning of “Detected” vs. “Blocked”
After reading the strength, read the action. BLOCK or NONE can be used for inputAction and outputAction in the settings. NONE is a mode that returns detection information but does not block with that filter. It is also different from inputEnabled and outputEnabled, which turn off evaluation. Combining detection-only and evaluation disablement can lead to missing cases where no inspection occurred at all. action·enabled in Settings API
The GuardrailContentFilter in the execution result includes type, confidence, and action, while detected and filterStrength are optional fields. It’s also important to distinguish that BLOCK is used in settings, and BLOCKED is used in results. The following JSON is a newly created synthetic evaluation item to explain the role of the fields, and is not an actual AWS response or detection performance metric. Execution Result API
{
"type": "HATE",
"confidence": "LOW",
"filterStrength": "HIGH",
"detected": true,
"action": "BLOCKED"
}This item explains the relationship: “classification confidence is LOW, but it matched a HIGH strength blocking policy.” Under the same conditions, if the configured action is NONE, it should not be recorded as blocked solely because there is confidence. The actual processing must be confirmed by checking both the action returned by the service and the response from the calling API.
For example, in Converse, a response where Guardrails intervened might show a stopReason of guardrail_intervened. If tracing is enabled, the cause can be identified along with the relevant evaluation information. One should not conclude that the entire request was allowed just by seeing action: NONE for a single filter item, as other policies might have intervened. Converse Response Handling
Figure: Inspection Scope → Filter Judgment → Actual Processing Result · Reconstructed based on official documentation
Inspection Scope to Check Before HIGH
PROMPT_ATTACK is a filter that inspects inputs attempting to alter developer instructions or bypass safety mechanisms. Prompt attack settings are read based on inputStrength and inputAction. It should not be assumed to have the same scope as input/output inspection for general harmful content categories, nor should it be considered a substitute for general harmful content policies attached to responses.
Especially when using InvokeModel and InvokeModelWithResponseStream, user input must be marked with a Guardrail input tag for the prompt attack filter to inspect that part. If there is no tag in this path, PROMPT_ATTACK is not inspected. This is a mechanism to distinguish the scope so that developer instructions are not confused with user attack inputs. Furthermore, the official documentation explicitly states that the prompt attack filter does not evaluate toolResult and toolSpec. One cannot record that tool results were also inspected merely by the fact that “Guardrails were attached.” Prompt Attack Filter
The input tag looks like this. This is also a virtual input structure, not an actual request.
개발자 지시: 공개 문서의 내용을 설명한다.
<amazon-bedrock-guardrails-guardContent_demoA1>
가상 문서의 요점을 알려 주세요.
</amazon-bedrock-guardrails-guardContent_demoA1>In the actual request body, amazon-bedrock-guardrailConfig.tagSuffix must also match the tag’s suffix. The demoA1 in the example is a fixed value for explanation, and in production, it is recommended to use a new, unpredictable suffix for each request. If tags are used, content outside the tags is excluded from the inspection scope. If no tags are used at all, general Guardrails process the entire input, but PROMPT_ATTACK, as explained earlier, is an exception. Input Tag Usage Rules
These XML tags are not directly carried over to Converse. Guardrail connection is done via guardrailConfig, and when selecting parts of a message to inspect, the guardContent block is used. The inspection status of system messages must also be checked separately from the inspection status of the message body. The examples in this article do not cover qualifiers settings such as contextual grounding. If other policies that change the inspection scope are used together, their respective policy documents should also be consulted. Converse Inspection Scope
Fixing Policy Table with Local Regression Tests
By transferring the table from the document into code, errors where setting interpretations are reversed can be easily caught. The following example does not connect to AWS. It only checks the relationship between already classified synthetic confidence and settings, and is not a detector that determines the harmfulness of actual sentences.
import unittest
BLOCKED_CONFIDENCES = {
"NONE": set(),
"LOW": {"HIGH"},
"MEDIUM": {"MEDIUM", "HIGH"},
"HIGH": {"LOW", "MEDIUM", "HIGH"},
}
def policy_action(strength, confidence, configured_action="BLOCK"):
# Applies the policy table to already classified values. Does not reproduce the AWS detection model.
if strength not in BLOCKED_CONFIDENCES:
raise ValueError("알 수 없는 강도")
if confidence not in {"NONE", "LOW", "MEDIUM", "HIGH"}:
raise ValueError("알 수 없는 신뢰도")
if configured_action not in {"BLOCK", "NONE"}:
raise ValueError("알 수 없는 설정 동작")
if configured_action == "NONE":
return "NONE"
return "BLOCKED" if confidence in BLOCKED_CONFIDENCES[strength] else "NONE"
class FilterMatrixTests(unittest.TestCase):
def test_all_sixteen_pairs(self):
# Each row is in the order of confidence NONE, LOW, MEDIUM, HIGH.
expected = {
"NONE": ["NONE", "NONE", "NONE", "NONE"],
"LOW": ["NONE", "NONE", "NONE", "BLOCKED"],
"MEDIUM": ["NONE", "NONE", "BLOCKED", "BLOCKED"],
"HIGH": ["NONE", "BLOCKED", "BLOCKED", "BLOCKED"],
}
for strength, actions in expected.items():
for confidence, action in zip(("NONE", "LOW", "MEDIUM", "HIGH"), actions):
with self.subTest(strength=strength, confidence=confidence):
self.assertEqual(policy_action(strength, confidence), action)
def test_detect_only_does_not_block(self):
self.assertEqual(policy_action("HIGH", "HIGH", "NONE"), "NONE")
def test_invalid_value_is_not_silently_allowed(self):
with self.assertRaises(ValueError):
policy_action("HIGH", "UNKNOWN")
if __name__ == "__main__":
unittest.main()Save it as test_filter_matrix.py and run python3 test_filter_matrix.py. While preparing this article, I locally verified three tests and 16 strength-confidence combinations. The result was “Ran 3 tests” and “OK”. This does not imply successful AWS API calls, actual classification results, or paid evaluations.
If this test is integrated into an application, keep the service response interpretation code separate from the policy table in the documentation. Do not guess confidence levels not present in the response, or store local calculation results in place of the actual Guardrail’s action.
Order of Reading in Operations
When settings do not produce the desired results, check in the following order:
- Verify that the actual call is connected to the intended Guardrail and version.
- Check the strength, action, and enabled settings for the relevant category and input/response direction.
- Confirm the tags or guardContent scope appropriate for the calling API.
- Check the type, confidence, and action of the actual evaluation item, and the overall processing result of the call.
- Separate normal synthetic examples from policy-violating synthetic examples and compare before and after setting changes.
HIGH in strength settings means filtering a broader range of harmful confidence levels. The ultimate service safety cannot be determined by strength alone, but by verifying what was inspected, what action was taken, and how the application used the results.
Leave a Reply