Skip to content

feature: Surfacing outbound pipeline denials #724

Open

Description

@evaline-ju

Feature Description

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)

Metadata

Metadata

Assignees

No one assigned

    Labels

    nice to haveIt would be nice to have this fixed

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions