fix: avoid false positives when blocking secrets in tool responses

[Pnkcaht]

What I did

Adjusted the secret-blocking middleware to avoid false positives for read-only tools by scoping response secret scanning to cases where secrets were already present in the tool input.
This change ensures that tools such as get_issue no longer fail due to overly aggressive secret detection in responses, while preserving protection against real secret exfiltration scenarios.

Related issue

Fixed #334

What was the problem?

When using read-only tools (e.g. get_issue) through the MCP Gateway, users consistently hit errors indicating that secrets were being returned, even though no secrets were provided as input.

This behavior was caused by the secret-blocking middleware scanning all tool responses unconditionally, regardless of whether the request itself contained sensitive data.

As a result:

• Read-only tools were blocked unexpectedly
• Tools that simply return text (issues, tickets, descriptions) failed
• Users had no reliable workaround other than disabling secret blocking entirely

How this change fixes it

The middleware now tracks whether secrets were present in the tool input and only scans the tool response when there is a real risk of secret exfiltration.

Specifically:

• Tool arguments are scanned first
• If secrets are detected in the input, the request is rejected as before
• Tool responses are only scanned if secrets were present in the input
• Read-only tools with non-sensitive inputs are no longer blocked

This preserves the original security guarantees while eliminating false positives.

Before / After (Summary)

Before

• Tool responses were always scanned for secrets
• Read-only tools like get_issue could fail unexpectedly
• Frequent false positives from heuristic secret detection

After

• Tool responses are scanned only when secrets were present in the input
• Read-only tools work reliably
• Protection against secret exfiltration is preserved

Screenshot

Secret detection in tool call input

This section ensures that tool invocation arguments are scanned for secrets before the tool is executed.
The arguments are first normalized into a string representation, allowing them to be safely analyzed regardless of their original structure. If the resulting input is non-empty and a secret pattern is detected, the execution is immediately blocked.

Conditional secret scanning in tool responses

This logic ensures that tool responses are only scanned for secrets when the input originally contained sensitive data.
Instead of blindly inspecting every tool response, the middleware tracks whether a secret was detected in the input arguments (inputHadSecrets). Only in that case does it perform a secondary scan on the tool’s output.

Tracking secret presence across the tool call lifecycle

The inputHadSecrets flag is introduced to track whether sensitive data was detected in the tool input arguments.
This variable acts as state shared across the middleware execution, allowing later stages to make informed decisions based on what happened during input validation.

[cutecatfann]

Thank you!