Skip to content

feat(ai-aws-content-moderation): add request_check_roles and request_check_mode - #13773

Open
shreemaan-abhishek wants to merge 1 commit into
apache:masterfrom
shreemaan-abhishek:feat/aws-cm-request-check-roles
Open

feat(ai-aws-content-moderation): add request_check_roles and request_check_mode#13773
shreemaan-abhishek wants to merge 1 commit into
apache:masterfrom
shreemaan-abhishek:feat/aws-cm-request-check-roles

Conversation

@shreemaan-abhishek

Copy link
Copy Markdown
Contributor

Description

ai-aws-content-moderation moderates the request side by calling extract_request_content, which takes every message of every role and scores the whole conversation on every turn. ai-aliyun-content-moderation has had role and turn selectivity since #13646; this brings the same options to the AWS plugin.

  • request_check_roles (array, default ["user","tool","system"]) selects which message roles are moderated. user/tool follow request_check_mode; system is moderated on every request because it can be poisoned by malicious ToolCall arguments overwriting the system prompt.
  • request_check_mode (last / all, default all) limits user/tool moderation to the latest consecutive block of selected-role messages, so history is not re-scored (and re-billed to Comprehend) each turn.

All selected roles' text is collected and scored in a single Comprehend call: DetectToxicContent takes a flat list of text segments with no role field, so per-role calls would only cost extra requests.

No new extraction code is needed — extract_turn_content(body, mode, roles) and extract_system_content(body) already exist on every protocol adapter from #13646.

Defaults preserve current coverage rather than mirroring the aliyun plugin's ["user"] + last: this plugin moderates everything today, and a narrower default would silently moderate less after an upgrade. Selectivity is opt-in. Assistant content is the one thing that drops out, since no extractor collects it (it is the LLM's own prior output, echoed back by the client).

One behavior change beyond the new options: when the active protocol cannot extract a configured role (passthrough implements neither extractor), the request goes through binding.on_unsupported so fail_mode decides, instead of silently passing the content unmoderated. With the default fail_mode: skip nothing changes.

Checklist

  • I have explained the need for this PR and the problem it solves
  • I have explained the changes or the new features added to this PR
  • I have added tests corresponding to this change (t/plugin/ai-aws-content-moderation.t TEST 36-49: default role/mode coverage, last vs all, role selection, schema validation, and the unsupported-protocol fail_mode path)
  • I have updated the documentation (docs/en/latest/plugins/ai-aws-content-moderation.md and the zh translation)
  • I have verified locally: prove -I. t/plugin/ai-aws-content-moderation.t — all 49 tests pass; make lint clean

…check_mode

Bring the request-side selectivity of ai-aliyun-content-moderation to the
AWS plugin: `request_check_roles` picks which message roles are moderated
(user/tool/system) and `request_check_mode` limits user/tool moderation to
the newest turn instead of re-scoring the whole conversation on every
request. system is always moderated when enabled, since it can be poisoned
by malicious ToolCall arguments.

Defaults keep today's coverage: all roles, every message. A protocol that
cannot extract a configured role now goes through fail_mode instead of
silently passing the content unmoderated.
@dosubot dosubot Bot added size:L This PR changes 100-499 lines, ignoring generated files. enhancement New feature or request plugin labels Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request plugin size:L This PR changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant