wso2 / wso2/api-platform

[Bug]: Chained Response Guardrails Fail

Open
#3,221 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Aspect/AI Aspect/API Severity/Critical Type/Bug
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:

  1. The upstream returns a valid OpenAI Chat Completions response.
  2. The first response guardrail successfully evaluates $.choices[0].message.content.
  3. The first guardrail does not intervene.
  4. The second response guardrail executes.
  5. 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
  1. In AI Workspace, create or use an existing LLM Provider.

  2. Create an App LLM Proxy using the provider and expose the Chat Completions endpoint.

  3. Add the following three response guardrails to the same proxy:

    • Regex Guardrail
    • URL Guardrail
    • JSON Schema Guardrail
  4. Configure all three guardrails to evaluate the same response field using:

    $.choices[0].message.content

  5. Configure each guardrail so that the test response is valid and should pass validation.

  6. Deploy the proxy.

  7. Send a Chat Completions request that produces a valid response containing content compatible with all three guardrails, for example JSON containing a valid URL.

  8. Verify that each guardrail works correctly when enabled individually.

  9. Enable all three response guardrails together and send the same request again.

  10. 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.