fix: redact sensitive tokens from invoke CLI output

[notgitika]

Summary

Restores redactSensitiveText() that was present on the preview branch but dropped during the preview→main consolidation (PR #1341).

Without this, bearer tokens and client secrets can appear verbatim in --json output or error messages when invoking harnesses with CUSTOM_JWT auth.

Redacts:

• Bearer <token> → Bearer [REDACTED]
• client_secret=<value> → client_secret=[REDACTED]
• token=<value> → token=[REDACTED]

Test plan

• TypeScript compiles cleanly
• Lint/prettier pass
• Manual: invoke with --bearer-token + --json, verify token is redacted in output

[github-actions]

Package Tarball

aws-agentcore-0.15.0.tgz

How to install

gh release download pr-1419-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.15.0.tgz

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-cli-automation]

Thanks for restoring this. The intent is right, but I think there are a couple of correctness gaps worth addressing before merge — primarily that the JSON-quoted forms of client_secret and token (which are the most common shapes when redacting from --json output and from agent/server response bodies) are not actually matched by the current regexes.

A second gap: errors thrown from inside the invoke flow that propagate up to the outer catch (error) in command.tsx (around lines 354–361) and the early --region is required exit inside handleInvokeCLI (around lines 52–58) bypass redactSensitiveText entirely. These paths can carry network error bodies (e.g. Invoke failed (${status}): ${body} from invokeWithBearerToken* in src/cli/aws/agentcore.ts), so they should also go through the redactor — either inline or via a shared helper.

[agentcore-cli-automation]

Regexes don't match JSON-quoted forms — the most common shape this PR is meant to cover.

The client_secret and token patterns require secret / token to be followed (after optional whitespace) by a literal : or =. In JSON output (the PR's stated motivating case — --json), the actual shape is:

"client_secret":"abc123"
"token":"abc123"
"access_token":"jwt.token.here"

There's a " between the key and the :, so \s*[:=]\s* does not match and these values are not redacted. Quick check:

redact('{"client_secret":"abc123"}')
// => '{"client_secret":"abc123"}'   (unchanged)
redact('{"token":"abc123"}')
// => '{"token":"abc123"}'           (unchanged)

This means agent responses or upstream error bodies that echo headers/tokens as JSON (a realistic case for misbehaving harnesses or 4xx response bodies) still leak.

Options:

1. Allow an optional " (or any non-word char) between the key and the separator, e.g. /(client[_-]?secret["']?\s*[:=]\s*["']?)([^"',\s}]+)/gi and similarly for token.
2. Add separate JSON-shape patterns alongside the existing key=value / key: value ones.
3. Redact the known-sensitive value directly when we have it (e.g., when options.bearerToken is set, do a literal replaceAll(options.bearerToken, '[REDACTED]') in addition to the heuristic regexes). This is the most reliable for the bearer case and is independent of the surrounding syntax.

Whichever path you take, please widen the value character class so the closing " / } aren't consumed as part of the redacted value (the current [^,\s]+ would swallow them when no comma/whitespace follows).

[agentcore-cli-automation]

No tests for redactSensitiveText.

This is a security-sensitive helper that's easy to get subtly wrong (see the JSON-shape comment above — a unit test would have caught it immediately). A small table-driven test in src/cli/commands/invoke/__tests__/ covering at least:

• Bearer <jwt> in a plain string and inside a JSON-stringified body
• client_secret=... and "client_secret":"..."
• token=... and "access_token":"..."
• A negative case (no sensitive content → unchanged)

would be enough to lock down the behavior and prevent regressions like the one this PR is fixing.