You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to Cortex's architecture and implementation as a transparent sidecar, currently when an outbound pipeline plugin (e.g. token-exchange or session-budget #723) denies or fails a request, the HTTP error (403, 503) is returned to the agent's internal HTTP client and not to the original caller. On the rossoctl platform this surfaces as a potentially cryptic error message like "can't connect to MCP service" instead of the a structured error message showing the original error.
The gap: there's no contract between a sidecar-injected policy denial and an agent SDK. HTTP SDKs don't distinguish "upstream is down" from "a policy layer rejected your request."
Reproduction
Point the token-exchange plugin at an unreachable Keycloak with default_policy: "exchange" and no_token_policy: "client-credentials". Any outbound request returns 503 with {"error":"upstream.token-exchange-failed","message":"client credentials token acquisition failed"} but an agent deployed on rossoctl will surface a generic error.
Proposed Solution
Up for discussion, and may depend on how 'transparent' a sidecar we want cortex to remain, such as for a solution like response injection. This could also be surfaced through events more clearly.
Want to contribute?
I would like to work on this issue.
Additional Context
MCP traffic already has protocol-native error wrapping (JSON-RPC error frame). The gap is for non-JSON-RPC outbound traffic (LLM inference, raw HTTP)
Affects all deployment modes (proxy-sidecar, envoy-sidecar)
Activity