scout: exec call-log redaction matches argument patterns, not secret values

[jmagar]

Summary

scout with action=exec redacts arguments in its own call log based on whether an argument looks like a secret assignment, rather than whether it contains a secret value. Passing a bare key name as a grep pattern gets it replaced with [redacted].

Reproduction

Four grep -c calls against the same file, differing only in the search pattern:

pattern passed	logged as
GOTIFY_URL=	GOTIFY_URL=
GOTIFY_APP_TOKEN=	[redacted]
GOTIFY_TOKEN=	[redacted]
GOTIFY	GOTIFY

// actual call log emitted by the gateway
{"tool":"scout","params":{"action":"exec","command":"grep",
 "args":["-c","GOTIFY_URL=","/home/jmagar/.labby/.env"]}}
{"tool":"scout","params":{"action":"exec","command":"grep",
 "args":["-c","[redacted]","/home/jmagar/.labby/.env"]}}

No secret was ever passed. GOTIFY_APP_TOKEN= is a 17-character literal used as a search string. The redactor appears to trigger on TOKEN|SECRET|KEY|PASS appearing in the argument text, with no check that a value follows the =.

Why it matters

1. The audit log becomes unreliable. Two of the four calls above are indistinguishable in the log, so a reader cannot tell which key was probed. For a tool whose purpose is remote inspection, an unfaithful record of what was inspected undermines the point.
2. It redacts in the wrong direction. Redaction is applied to inputs via a name-shaped heuristic, while stdout — the field that would actually hold a secret if someone ran cat .env — is returned verbatim. The protection is aimed away from the risk.
3. Debuggability. Grepping .env files for key names is a normal config-debugging workflow, and it currently yields a log full of [redacted] with no way to reconstruct what was searched.

Suggested direction

Redact on value shape, not key name:

• Match KEY=<non-empty value> and redact only the captured value, preserving the key: GOTIFY_APP_TOKEN=<redacted:32ch>. A trailing = with nothing after it is not a secret.
• Apply the same value-shaped rule to stdout/stderr, so cat-ing an env file is actually protected.
• Consider entropy/length thresholds over a keyword denylist — the string TOKEN= carries no information on its own.

Environment

• Observed via the Labby gateway (synapse::scout) through Code Mode, 2026-07-10.
• The live tool's own description reads SSH/local host inspection for synapse2 (B14+B15). Filing here per maintainer instruction; transfer to jmagar/synapse2 if the affected code lives there.

Adjacent, possibly separate

grep -o '^GOTIFY[A-Z_]*' against the same file fails with:

kind=execution_error action='exec'

while grep -c <pattern> on the identical path succeeds. Either -o is outside the flag allowlist, or the ^/* metacharacters are rejected — but the error surfaces no reason, so it is indistinguishable from a genuine failure. Split into its own issue if unrelated.