AWS guardduty: Add sensitive information filter details to AI Protection finding
Summary
Documents a new `sensitiveInformationFilters` field in the AI Protection prompt injection finding, describing detected sensitive information types (e.g. AWS_SECRET_KEY, PASSWORD) and actions (BLOCKED/ANONYMIZED/NONE), noting only the type is recorded, never the content.
Security assessment
The change documents a security detection feature (sensitive information filters) and explicitly states only the type of sensitive data is recorded, not the content, which is a data-protection/privacy consideration. It documents a security capability rather than fixing a vulnerability.
Evidence
+`sensitiveInformationFilters` | Sensitive information filters that the guardrail applied when it evaluated the invocation. Each entry has a `type` that identifies the kind of sensitive information the guardrail detected, such as `AWS_SECRET_KEY` or `PASSWORD`, and an `action` of `BLOCKED` if the guardrail blocked the content, `ANONYMIZED` if the guardrail masked it, or `NONE` if the guardrail detected it but was configured only to report it. The finding records the type of information detected, never the content itself.
Diff
diff --git a/guardduty/latest/ug/findings-ai-protection.md b/guardduty/latest/ug/findings-ai-protection.md index 6830bf64f..909c7416c 100644 --- a//guardduty/latest/ug/findings-ai-protection.md +++ b//guardduty/latest/ug/findings-ai-protection.md @@ -140 +140 @@ This finding informs you that an Amazon Bedrock Guardrail configured for an Amaz -GuardDuty generates this finding when an Amazon Bedrock Guardrail intervenes on an invocation because it detected a prompt attack with high confidence. To enable GuardDuty to detect direct prompt injection, configure an Amazon Bedrock Guardrail with a [prompt attack content filter](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-prompt-attack.html). To ensure that the guardrail evaluates invocations across your environment, enforce it broadly instead of relying on individual applications to attach it to each request. You can enforce a guardrail for all Amazon Bedrock model invocations in an account, or across your organization by using Amazon Bedrock policies in AWS Organizations. For more information, see [Apply cross-account safeguards with Amazon Bedrock Guardrails enforcements](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-enforcements.html) in the _Amazon Bedrock User Guide_. When a guardrail evaluates an invocation, Amazon Bedrock records the evaluation in AWS CloudTrail data events, which GuardDuty analyzes to generate this finding. +GuardDuty generates this finding when an Amazon Bedrock Guardrail intervenes on an invocation because it detected a prompt attack with high confidence. To enable GuardDuty to detect direct prompt injection, configure an Amazon Bedrock Guardrail with a [prompt attack content filter](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-prompt-attack.html). To ensure that the guardrail evaluates invocations across your environment, enforce it broadly instead of relying on individual applications to attach it to each request. You can enforce a guardrail for all Amazon Bedrock model invocations in an account, or across your organization by using Amazon Bedrock policies in AWS Organizations. For more information, see [Apply cross-account safeguards with Amazon Bedrock Guardrails enforcements](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-enforcements.html) in the _Amazon Bedrock User Guide_. When a guardrail evaluates an invocation, Amazon Bedrock records the evaluation in AWS CloudTrail data events, which GuardDuty analyzes to generate this finding. If the guardrail also applied a [sensitive information filter](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-sensitive-filters.html) when it evaluated the invocation, the finding includes details about the type of sensitive information detected. @@ -149,0 +150 @@ Field | Description +`sensitiveInformationFilters` | Sensitive information filters that the guardrail applied when it evaluated the invocation. Each entry has a `type` that identifies the kind of sensitive information the guardrail detected, such as `AWS_SECRET_KEY` or `PASSWORD`, and an `action` of `BLOCKED` if the guardrail blocked the content, `ANONYMIZED` if the guardrail masked it, or `NONE` if the guardrail detected it but was configured only to report it. The finding records the type of information detected, never the content itself.