fix(use_aws): gate and redact ssm parameter and kms responses

[yonib05]

Description

Extends the sensitive-operation handling added in #467 to cover two AWS response shapes that currently return sensitive values to the model context without a consent prompt or redaction: SSM Parameter Store reads and KMS key operations.

This reuses the existing SENSITIVE_OPERATIONS set, SENSITIVE_RESPONSE_KEYS set, and redact_sensitive_values pipeline introduced in #467 rather than adding a parallel mechanism.

Behavior change

• ssm get_parameter / get_parameters / get_parameters_by_path and kms decrypt / generate_data_key / generate_data_key_pair now prompt for consent and redact their values by default.
• Set BYPASS_TOOL_CONSENT=true to skip the consent prompt for these operations. Redaction of sensitive values in the response is independent of the prompt and always applies.

Changes

• Add to SENSITIVE_OPERATIONS (consent gate): ssm get_parameter / get_parameters / get_parameters_by_path, and kms decrypt / generate_data_key / generate_data_key_pair.
• Add "plaintext" and "privatekeyplaintext" to SENSITIVE_RESPONSE_KEYS so KMS plaintext output is redacted.
• Add redact_ssm_parameter_values, a narrowly scoped helper that redacts Parameter.Value and Parameters[].Value only for ssm responses. SSM SecureString values are returned under a generic Value key, which is too broad to add to the global key set without redacting unrelated fields, so this targets only the SSM response shapes.
• Keep response redaction unconditional: BYPASS_TOOL_CONSENT skips only the confirmation prompt, not redaction, so sensitive values never reach the model context.
• Add regression tests: consent gating for the new ssm/kms operations, SSM get_parameter / get_parameters value redaction, KMS decrypt plaintext redaction, KMS generate_data_key_pair private-key redaction, redacted values still returned under BYPASS_TOOL_CONSENT=true, and a non-ssm passthrough check.

Testing

• pytest tests/test_use_aws.py (60 passed)
• ruff format --check and ruff check pass.

Follow-up

Key-name based redaction is inherently incomplete for generically named fields. A possible follow-up is an opt-in STRANDS_USE_AWS_STRICT_CONSENT env var that prompts on every use_aws call, decoupling safety from the maintained allowlist. That is a larger behavior change and is left out of this PR. IAM least-privilege scoping remains the primary control, as documented in the module.

[yonib05]

/strands-ts review

[github-actions]

Review — LGTM ✅

Reviewed the changes locally. This is a focused, well-scoped extension of the #467 sensitive-operation handling.

Verification

• pytest tests/test_use_aws.py → 60 passed
• ruff check → clean
• ruff format --check → clean

Strengths

• Reuses the existing SENSITIVE_OPERATIONS / SENSITIVE_RESPONSE_KEYS / redact_sensitive_values pipeline instead of introducing a parallel mechanism.
• Redaction is applied unconditionally after the consent gate (use_aws.py:499-500), so BYPASS_TOOL_CONSENT only skips the human prompt and never authorizes returning secrets to model context. This is the right security posture and is explicitly regression-tested.
• redact_ssm_parameter_values is narrowly targeted (case-insensitive service check, immutable {**param} copies, only Parameter / Parameters[].Value) and the rationale for not adding a generic Value key to the global set is well justified.
• Good regression coverage: parametrized consent gating for the new ssm/kms ops, value redaction for get_parameter/get_parameters, KMS decrypt plaintext and generate_data_key_pair private-key redaction, bypass-still-redacts, and a non-ssm passthrough.

Minor observations (non-blocking)

1. plaintext is a somewhat generic key to add to the global SENSITIVE_RESPONSE_KEYS. The same collision concern used to justify keeping Value out of that set applies (weakly) here — it's much rarer than Value so this is acceptable, just worth noting.
2. ssm get_parameters_by_path and kms generate_data_key (Plaintext) redaction are covered only transitively (shared helper / global-key logic). A couple of explicit redaction assertions would round out coverage, but this is optional.

No blocking issues — approving. The follow-up note on an opt-in strict-consent env var is a reasonable future direction to keep out of this PR.