[Bug]: Guardrail policy findings

[Thenujan-Nagaratnam]

Please select the area the issue is related to

Gateway

Please select the aspect the issue is related to

Aspect/API (API backends, definitions, contracts, interfaces, OpenAPI)

Description

• No upstream status-code check before response-body validation
  • word-count-guardrail, sentence-count-guardrail, url-guardrail, pii-masking-regex, aws-bedrock-guardrail, azure-content-safety-content-moderation, content-length-guardrail, json-schema-guardrail, regex-guardrail all run their JSONPath extraction/validation on the response body regardless of the upstream LLM's HTTP status. An ordinary upstream failure (429/500/401, no choices field) triggers each guardrail's own extraction-failure error, potentially masking the real upstream error.
• Raw internal Go error text returned to clients on JSONPath extraction failure
  • unconditional in pii-masking-regex, prompt-decorator, prompt-template, semantic-cache; gated behind showAssessment (default false) in url-guardrail, word-count-guardrail, sentence-count-guardrail, aws-bedrock-guardrail, and likely the rest of the guardrail family sharing the same buildAssessmentObject template.
• JSONPath is not supported for lists like $.messages
  • when the JSONPath is configured as $.messages it does nothing

Steps to Reproduce

1. Attach a policy (word count guardrail)
2. Force the backend to return an error response (401 invalid key)
3. observe the 1st scenario and the second scenario
4. add the jsonpath as $.messages and observe that the guardrail not getting applied.

Severity Level of the Issue

Severity/Minor (Non-critical functionality. Can be fixed in future releases)

Environment Details (with versions)

No response