(bedrock): Guardrails `piiFilters.inputEnabled` seems to not be working?

[athewsey]

Describe the bug

Bedrock Guardrail piiFilters seem to only be enabled on the output side by default (which I would argue is probably a wrong/counter-intuitive choice), and also setting inputEnabled: true doesn't seem to do anything?

Expected Behavior

1/ Given a Bedrock Guardrail is created with a PII filter which doesn't specify either inputEnabled or outputEnabled, I'd suggest (regardless of underlying CloudFormation behaviour) that enabling on both sides would be a sensible and maximally-secure default for the construct. For e.g:

new bedrock.Guardrail(this, "MyGuardrail", {
  piiFilters: [
    {
      action: bedrock.GuardrailAction.ANONYMIZE,
      type: bedrock.PIIType.General.EMAIL,
    },
  ]
});

2/ When I explicitly specify inputEnabled, I'd certainly expect the PII filter to be enabled on the input side:

new bedrock.Guardrail(this, "MyGuardrail", {
  piiFilters: [
    {
      action: bedrock.GuardrailAction.ANONYMIZE,
      inputEnabled: true,
      type: bedrock.PIIType.General.EMAIL,
    },
  ]
});

Current Behavior

In both the above cases, the above deployed guardrail's PII filter has output action Mask and input action disabled

Reproduction Steps

Code snippet above

Possible Solution

I don't see the construct doing anything particularly weird on CDK side here, so maybe the issue is that the underlying CloudFormation interface behaves weirdly and we should consider improving the abstraction the CDK provides?

Additional Information/Context

No response

CDK CLI Version

2.1007.0

Framework Version

0.1.309

Node.js Version

22.15.1

OS

macOS

Language

Typescript

Language Version

No response

Region experiencing the issue

us-west-2

Code modification

No

Other information

No response

Service quota

• I have reviewed the service quotas for this construct

[athewsey]

OK I've confirmed that this is a bug in the CDK: Guardrail.generateCfnPiiEntitiesConfig() does not actually pass through any of the optional CFnGuardrail PiiEntityConfigProperty props - just type and action.

From testing with the below CloudFormation snippet, I find that:

1. When neither inputAction nor inputEnabled are provided, the PII filter is disabled on input-side by default
2. Setting just inputEnabledtrue is sufficient to enable the filter, with the same action selected by action (which is a mandatory field anyway)
3. Setting just inputAction doesn't enable it

A simple pass-through implementation should be pretty easy, but do we want the construct to implement a more secure-by-default design than the underlying CFn API?

I suggest to default inputEnabled to true unless it's explicitly passed as false in the construct props, particularly because a lot of the asks I've heard for PII masking have been wanting to avoid exposing the PII to the AI model at all - rather than only masking out any data it returns back. However, this would change the current default behavior of the construct and I believe also increase consumption cost of the deployed guardrails.

{
  "Resources": {
    "GuardrailTest": {
      "Type": "AWS::Bedrock::Guardrail",
      "Properties": {
        "BlockedInputMessaging": "Sorry",
        "BlockedOutputsMessaging": "Sorry",
        "Description": "CFn Guardrails PII check",
        "Name": "tmp-guardrail-cfn-check",
        "SensitiveInformationPolicyConfig": {
          "PiiEntitiesConfig": [
            {
              "Action": "ANONYMIZE",
              "Type": "EMAIL"
            },
            {
              "Action": "ANONYMIZE",
              "InputEnabled": true,
              "Type": "PHONE"
            },
            {
              "Action": "ANONYMIZE",
              "InputAction": "ANONYMIZE",
              "Type": "CREDIT_DEBIT_CARD_CVV"
            },
            {
              "Action": "ANONYMIZE",
              "InputAction": "ANONYMIZE",
              "InputEnabled": true,
              "Type": "CREDIT_DEBIT_CARD_EXPIRY"
            }
          ]
        }
      }
    }
  }
}

[github-actions]

This issue is now marked as stale because it hasn't seen activity for a while. Add a comment or it will be closed soon. If you wish to exclude this issue from being marked as stale, add the "backlog" label.

[krokoko]

Thanks @athewsey , could you please try with https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/aws-bedrock-alpha#guardrails which has the fix ? Thank you