Fix replicate to foreign server without PDPA

[Sameerlite]

Relevant issues

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have Added testing in the tests/litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Type

🆕 New Feature
🐛 Bug Fix
🧹 Refactoring
📖 Documentation
🚄 Infrastructure
✅ Test

Changes

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Building	Preview, Comment	Feb 24, 2026 4:55am

[greptile-apps]

Greptile Summary

This PR fixes two issues in Singapore PDPA guardrail policy YAML templates to resolve failing test test_sentence[dt_8] ("replicate to foreign server without PDPA"):

• sg_pdpa_data_transfer.yaml: Adds bare "PDPA" as an identifier_words entry so that sentences mentioning PDPA without a Singapore-specific data term (e.g., "replicate to foreign server without PDPA") can still trigger conditional blocking when paired with a block word like "replicate to" or "without PDPA".
• sg_pdpa_profiling_automated_decisions.yaml: Narrows the exception from "human oversight" to "with human oversight" to prevent the exception from incorrectly matching the block word "without human oversight" (since exceptions use substring matching, "human oversight" is a substring of "without human oversight").

Issues found:

• Adding bare "PDPA" as an identifier may introduce false positives for legitimate informational queries that mention PDPA alongside transfer-related terms.
• The narrowed "with human oversight" exception, while fixing the substring collision, may not cover all valid phrasings that indicate human oversight is present (e.g., "ensure human oversight", "human oversight required").
• No new tests were added with this PR, despite the PR template requiring at least 1 test in tests/litellm/. The existing test at tests/guardrails_tests/test_sg_pdpa_guardrails.py:285 ("replicate to foreign server without PDPA") was introduced in the prior commit and should now pass, but there are no new tests verifying the changes don't introduce regressions (e.g., false positive tests for bare "PDPA" matching).

Confidence Score: 3/5

• PR fixes test failures but may introduce false positives from overly broad identifier matching; no new tests validate the changes.
• Score of 3 reflects that the changes are logically sound fixes for known test failures, but (1) adding bare "PDPA" as an identifier broadens the matching scope and could cause false positives on legitimate queries, (2) the narrowed exception may miss valid phrasings, and (3) no new tests were added to validate these edge cases.
• Pay close attention to sg_pdpa_data_transfer.yaml — the bare "PDPA" identifier word broadens the trigger scope significantly and may cause unintended blocks on informational queries.

Important Files Changed

Filename	Overview
litellm/proxy/guardrails/guardrail_hooks/litellm_content_filter/policy_templates/sg_pdpa_data_transfer.yaml	Adds bare "PDPA" as an identifier_word to fix conditional matching for inputs like "replicate to foreign server without PDPA". The addition is functionally correct but broadens the trigger scope since "PDPA" alone will now match as an identifier in any sentence.
litellm/proxy/guardrails/guardrail_hooks/litellm_content_filter/policy_templates/sg_pdpa_profiling_automated_decisions.yaml	Changes exception from "human oversight" to "with human oversight" to prevent the exception from incorrectly matching the block word "without human oversight" (since exceptions use substring matching). This is a valid bug fix.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Input Text] --> B{Check Global Exceptions}
    B -->|Exception found| C[ALLOW]
    B -->|No exception| D{Check Category Exceptions}
    D -->|Exception found| C
    D -->|No exception| E{Split into Sentences}
    E --> F{Sentence contains identifier_word?}
    F -->|No| G[Next sentence]
    F -->|Yes e.g. 'PDPA'| H{Sentence also contains block_word?}
    H -->|No| G
    H -->|Yes e.g. 'replicate to'| I[BLOCK - Conditional Match]
    G -->|More sentences| F
    G -->|No more| J{Check always_block_keywords}
    J -->|Match| K[BLOCK - Always Block]
    J -->|No match| C

    style I fill:#ff6b6b,color:#fff
    style K fill:#ff6b6b,color:#fff
    style C fill:#51cf66,color:#fff

Loading

_{Last reviewed commit: 044639f}

[greptile-apps]

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Broad identifier may cause false positives

Adding bare "PDPA" as an identifier word means any sentence mentioning "PDPA" alongside any additional_block_words entry will trigger a block. Since identifier matching uses case-insensitive substring matching (if identifier in sentence_lower), this could block legitimate requests like:

• "How do I export data under PDPA?" (matches identifier "pdpa" + block word "export")
• "Is PDPA relevant when I copy to another department?" (matches "pdpa" + "copy to")

These seem like informational queries that should be allowed. The existing exceptions ("explain", "what is", "how to comply") won't cover all such cases.

Consider whether a more specific phrase like "PDPA data" (already present at line 17) or "under PDPA" would be sufficient, or add more exceptions to guard against false positives on informational queries.

[greptile-apps]

Narrowed exception may miss valid phrasing

Changing from "human oversight" to "with human oversight" correctly prevents the exception from unintentionally matching the block word "without human oversight" (since exceptions use substring matching). However, this also means phrases like "ensure human oversight is maintained" or "human oversight required" will no longer trigger the exception.

Consider additionally listing other common phrasings that convey the same intent, such as:

• "human oversight required"
• "ensure human oversight"
• "under human oversight"

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}