Summary

• The proxy audit middleware determined outcome solely from the HTTP status code. Because MCP servers return errors inside HTTP 200 responses per the JSON-RPC spec, application-level failures (expired tokens, API errors, invalid parameters) were logged as outcome=success, making them invisible in audit logs.
• Adds JSON-RPC error detection: after receiving an HTTP 200, the middleware inspects a small prefix of the response body for a top-level "error" field. If found, it records outcome=application_error with the JSON-RPC error code and truncated message as metadata.
• Adds a DetectApplicationErrors config flag (default true) that controls this behavior independently of IncludeResponseData, so error detection works without enabling full response capture.

Fixes #4678 as a BUG FIX

Changes

Does this introduce a user-facing change?

Yes. Audit logs now distinguish between true successes and application-level failures. Events that previously showed outcome=success for JSON-RPC errors will now show outcome=application_error with jsonrpc_error_code and jsonrpc_error_message in metadata. This is enabled by default and can be disabled via the detectApplicationErrors audit config flag.

Special notes for reviewers

• The errorDetectionBody buffer is only allocated when IncludeResponseData is false. When response data capture is already enabled, the existing rw.body buffer is reused to avoid double-buffering.
• A prefix[0] == '{' guard skips JSON parsing for non-JSON responses (health checks, SSE keepalives).
• Custom jsonRPCError/jsonRPCResponseEnvelope structs are used instead of jsonrpc2.DecodeMessage because the library's wireError type is unexported, making it impossible to extract the numeric error code from outside the package.
• This approach only covers Streamable HTTP JSON responses. Legacy SSE transport (where POST returns 202 and the response arrives on a separate GET stream) is not covered — documented as a known limitation per discussion in Proxy audit middleware records outcome=success for JSON-RPC application-level errors in HTTP 200 responses #4678.