[Bug]: Chained Response Guardrails Fail
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 71
- Forks
- 111
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 110
Description
Please select the area the issue is related to
AI Workspace
Please select the aspect the issue is related to
Aspect/API (API backends, definitions, contracts, interfaces, OpenAPI), Aspect/AI (AI/LLM integration, MCP, AI readiness)
Description
Summary
While preparing an AI Gateway security demonstration, I identified a possible issue when chaining multiple response guardrails on the same Chat Completions proxy in WSO2 AI Gateway 1.1.0.
Environment
-
WSO2 AI Gateway 1.1.0
-
Chat Completions proxy
-
Response guardrails configured:
- Regex
- URL
- JSON Schema
Issue Description
Each response guardrail works correctly when configured and tested independently.
However, when multiple response guardrails are enabled on the same proxy, the first guardrail processes the response successfully, but the subsequent guardrail appears to receive the payload already extracted or transformed by the previous guardrail instead of the original OpenAI Chat Completions response envelope.
For example, the guardrails are configured to evaluate:
$.choices[0].message.content
The first guardrail correctly extracts and validates this value. The next guardrail then appears to evaluate the same JSONPath against the output of the previous guardrail rather than against the original upstream response.
Because the resulting payload no longer contains the choices structure, the subsequent guardrail fails with errors such as:
Error extracting value from JSONPath
key not found: choices
or:
value at JSONPath is not a string or number
Important Observation
The issue is not limited to cases where the first guardrail intervenes or blocks the response.
It can also occur during a completely valid response flow:
- The upstream returns a valid OpenAI Chat Completions response.
- The first response guardrail successfully evaluates
$.choices[0].message.content. - The first guardrail does not intervene.
- The second response guardrail executes.
- The second guardrail fails because it appears to receive the content processed by the previous guardrail instead of the original response envelope.
When the same guardrails are configured individually, the JSONPath works correctly in all cases.
Expected Behavior
Each response guardrail in the chain should evaluate the configured JSONPath against the original upstream response payload, or the response structure should otherwise remain consistent between guardrails.
A successful, non-intervening guardrail should not modify the payload in a way that causes subsequent guardrails to fail.
Actual Behavior
The first guardrail succeeds, but subsequent guardrails appear to receive a modified/extracted payload. As a result, JSONPaths that depend on the original Chat Completions response structure can no longer be resolved.
Workaround Attempted
I also tested omitting the JSONPath and attempting whole-payload validation, but this did not provide a reliable workaround.
Request
Could you please confirm whether this is a known limitation or issue in AI Gateway 1.1.0?
If multiple response guardrails are expected to be supported on the same proxy, please confirm whether each guardrail should operate against the original response payload and investigate why the response structure appears to change between guardrail executions.
Steps to Reproduce
-
In AI Workspace, create or use an existing LLM Provider.
-
Create an App LLM Proxy using the provider and expose the Chat Completions endpoint.
-
Add the following three response guardrails to the same proxy:
- Regex Guardrail
- URL Guardrail
- JSON Schema Guardrail
-
Configure all three guardrails to evaluate the same response field using:
$.choices[0].message.content -
Configure each guardrail so that the test response is valid and should pass validation.
-
Deploy the proxy.
-
Send a Chat Completions request that produces a valid response containing content compatible with all three guardrails, for example JSON containing a valid URL.
-
Verify that each guardrail works correctly when enabled individually.
-
Enable all three response guardrails together and send the same request again.
-
Observe that the first guardrail completes successfully, but a subsequent guardrail fails while evaluating the same JSONPath, with errors such as:
Error extracting value from JSONPath: key not found: choices
or
value at JSONPath is not a string or number
The failure occurs even though the upstream response is valid and the first guardrail does not intervene.
Severity Level of the Issue
Severity/Critical (Core functionality is broken but there is a workaround. Need urgent attention)
Environment Details (with versions)
- Product: WSO2 AI Gateway
- Version: 1.1.0
- Configuration Interface: AI Workspace
- Component: App LLM Proxy / Chat Completions
- Feature: Response Guardrails
- Guardrails Used: Regex, URL, JSON Schema
- Guardrail Scope: Response
- JSONPath:
$.choices[0].message.content - Deployment: AI Gateway runtime connected to AI Workspace
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the issue in AI Workspace using an App LLM Proxy with the Chat Completions endpoint and Regex, URL, and JSON Schema response guardrails configured for $.choices[0].message.content. Compare individual and chained execution with a valid response; done means every guardrail can evaluate the original response structure without a non-intervening guardrail breaking subsequent checks.
Written by the indexing model from the issue text.
Assessment
- Domain
- ai, api, backend-api-design
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100