fix(plugins): redact credential patterns in free-text values, not just exact keys - #6499
prasanna8585 wants to merge 1 commit into
Conversation
|
Hi @jawoszek , Can you review this PR and let me know if anything is required for the update from my side? thanks for your time! |
|
Hi @jawoszek , Can you review this PR and let me know if anything is required for the update from my side? |
1 similar comment
|
Hi @jawoszek , Can you review this PR and let me know if anything is required for the update from my side? |
|
Hi @jawoszek , Can you review this PR and let me know if anything is required for the update from my side? or can you assign someone from the team for the review of this code fix? |
|
Hi @jawoszek , Can you review this PR and let me know if anything is required for the update from my side? |
|
Hi Team, Can you review this PR and let me know if anything is required for the update from my side? or can you assign someone from the team to review this PR? |
|
Hi @jawoszek , Can you review this PR and let me know if anything is required for the update from my side? |
…t exact keys
_recursive_smart_truncate -> _sanitize_json_blob / _sanitize_free_text
is the sanitization path used for tool args/results, session-state
deltas, usage/cache metadata, A2A payloads, and tool schemas (every
event type BigQueryAgentAnalyticsPlugin logs except proper LLM Part
content, which already goes through _sanitize_strings ->
_sanitize_sensitive_text).
That path only pattern-inspects strings that are JSON-container-shaped
(start with '{' or '['); plain prose values were returned completely
unchanged, with only exact dict-key matches against _SENSITIVE_KEYS
redacted. A credential embedded in ordinary text under an unrecognized
key -- e.g. a tool's own status/error message containing
'Authorization: Bearer sk-...' or 'api_key: sk-...' -- reached BigQuery
in plaintext.
This wires the existing _redact_sensitive_patterns() pass (already used
for signed-URI segments, Part-content text, and error/traceback text)
into the two prose fallback branches of _sanitize_json_blob and
_sanitize_free_text, so credential-shaped text is caught regardless of
which key it's nested under or whether it's JSON-shaped at all.
Verified against the existing test suite (437 passed, 0 regressions)
and added a regression test covering the reported gap.
e86d52a to
1b1051e
Compare
_recursive_smart_truncate->_sanitize_json_blob/_sanitize_free_textis the sanitization path used for tool args/results, session-state deltas, usage/cache metadata, A2A payloads, and tool schemas. That path only pattern-inspects JSON-container-shaped strings; plain prose values passed through unredacted with only exact dict-key matches against_SENSITIVE_KEYSbeing caught. This wires the existing_redact_sensitive_patterns()pass (already used for signed-URI segments, Part-content text, and error/traceback text) into the two prose fallback branches so credential-shaped text is caught regardless of which key it's nested under.Verified against the existing test suite (437 passed, 0 regressions) with a new regression test added for the fixed gap.