feat: add MCP redaction filtering for sensitive data

[silasjmatson]

Summary

Adds default-on redaction at the MCP boundary so connected LLMs don't see secrets the desktop app sees. Server applies a built-in rule set to every resource and tool response; opting out requires both a client request and a matching server-side permission ("two-key" model). All redaction work lives in reactotron-mcp — the React Native client only opts in via a new mcpRedaction field on Reactotron.configure.

What gets redacted

• Sensitive keys (case-insensitive, any nesting level): credentials (password, secret, client_secret, private_key, ssn, creditcard), API keys (api_key, apikey, x-api-key), auth tokens (token, bearer, jwt, access_token, refresh_token, id_token), session/CSRF (session*, csrf*, xsrf*), HTTP headers (Authorization, Cookie, Set-Cookie, Proxy-Authorization, X-Auth-Token, X-CSRF-Token, X-XSRF-Token, X-Forwarded-For, X-Real-IP).
• Value patterns (regex against strings): Bearer tokens, JWTs, OpenAI / Anthropic / GitHub / Slack / AWS / Google / Stripe keys, PEM private-key blocks.
• URL query params (?api_key=…) and form-urlencoded bodies (k=v&k=v) where the param name matches a sensitive key.
• JSON-encoded strings are parsed, redacted, and re-stringified (depth/size-guarded).
• AsyncStorage mutations — including setItem, mergeItem, multiSet, multiMerge — checked by storage-key substring.
• State-path patterns with trailing wildcard (auth.tokens.*) at known anchors (reactotron://state/current, request_state).

Two-key opt-out

Clients can send mcpRedaction.{additionalRules, removeRules, disableRedaction} in the intro payload. additionalRules is always honored. removeRules and disableRedaction only take effect when the desktop app has the matching permission enabled (both off by default). Per-app rules are scoped per-client: in multi-app reads, App A's additionalRules don't affect App B's events, and App B's removeRules can't weaken App A's redaction.

Desktop UI

• Settings modal (gear icon next to the MCP button) for editing sensitiveKeys, statePathPatterns, valuePatterns, the two client permissions, and a reset-to-defaults button. Persisted via electron-store. Defaults sourced from reactotron-mcp (single source of truth).
• Shield badge next to the MCP indicator: green while no client has actually opted out, amber when a connected client's intro requests an opt-out the server is honoring (toggling the permission alone doesn't flip it).

Architecture

• New reactotron-core-contract/src/mcpRedaction.ts with McpRedactionConfig / McpRedactionRules shared types. ClientIntroPayload carries it through the websocket handshake.
• New reactotron-core-client option mcpRedaction forwarded on client.intro.
• reactotron-mcp/src/redaction.ts exposes createRedactor(server, config) returning { redact, redactState, redactAsyncStorage }. Resolved rules and compiled regex are cached per clientId for the lifetime of one MCP request.
• resources.ts / tools.ts route every outbound payload through the redactor with the originating event's clientId.

Performance

• Value patterns are validated individually then folded into a single alternation regex (one pass per string).
• Sensitive keys are pre-lowercased into a Set; rules are parsed once per request.
• State-path tracking only allocates path strings when patterns exist.
• JSON-string redaction is depth-capped (5) and size-capped (1MB) to bound work on large payloads.

Tests

• redaction.test.ts — 75 unit tests covering rule resolution, key/value/path matching, URL/form-encoded handling, JSON-string recursion, AsyncStorage shapes, circular refs, and edge cases.
• redaction-integration.test.ts — 14 tests against realistic resource payloads (network entries, state snapshots, AsyncStorage mutations, custom commands).
• mcp-server.test.ts — adds 2 new HTTP/MCP-level tests proving per-client redaction across multi-app reads.

Docs

docs/mcp.md gains a Redaction section covering defaults, configuration, multi-app behavior, and a Limitations and gotchas subsection that flags audit-before-LLM-connection (custom field names, opaque storage keys, state paths without anchors, defaults at the MCP boundary not at storage).

Example app

apps/example-app adds a RedactionTestScreen manual test harness that exercises every code path (sensitive keys at depth, JWT/Bearer values, form-encoded bodies, AsyncStorage shapes, state path patterns) and a redux slice / nav entry to reach it.

Please verify

• yarn build-and-test:local passes
• Tests added for new behavior
• docs/mcp.md updated

[joshuayoes]

🐛 Redaction gap: request bodies aren't redacted by key

What I saw (manual QA on iOS sim + Android emulator):

Fired an API call with:

fetch("https://jsonplaceholder.typicode.com/posts?api_key=X&page=2", {
  method: "POST",
  headers: { Authorization: "Bearer abc...", Cookie: "session=..." },
  body: JSON.stringify({ password: "hunter2", api_key: "x", accessToken: "y",
                         note: "embedded sk-ABCDEFGHIJKLMNOPQRSTUVWX" }),
})

Reading reactotron://timeline/api.response via MCP, the response body is fully redacted, but the request body leaks:

"request": {
  "data": "{\"password\":\"hunter2\",\"api_key\":\"x\",\"accessToken\":\"y\",\"note\":\"embedded [REDACTED] ...\"}",
  "headers": { "authorization": "[REDACTED]", "cookie": "[REDACTED]" },
  "params": { "api_key": "[REDACTED]", "page": "2" }
}

Headers, URL query params, and the sk- token inside note (via valuePatterns) are redacted correctly. But password, api_key, accessToken in the body string pass through.

Root cause: fetch({ body: JSON.stringify(...) }) gives the networking plugin a string, cached verbatim as tronRequest.data (lib/reactotron-react-native/src/plugins/networking.ts:92-96). The redactor walks object keys but only applies valuePatterns to strings (lib/reactotron-mcp/src/redaction.ts:219-239), so the JSON-shaped string is never parsed and key-level redaction never runs on the body.

Who's affected: anyone using fetch / axios / apisauce with a JSON body — auth endpoints ({ password }), token refresh, payment flows, etc. will leak to the MCP client.

Suggested fix: in redactStringValue or summarizeNetworkEntry, detect strings that look like JSON (start with { or [, or Content-Type application/json), JSON.parse → redact → JSON.stringify, fall back to valuePatterns if parsing throws.

[joshuayoes]

🐛 State path patterns silently fail when requesting a subtree

Repro:

1. Added a Redux slice so state.redactionTest.auth.tokens = { access: "...", refresh: "..." }.
2. In the MCP redaction settings modal, added redactionTest.auth.tokens.* to State Path Patterns.
3. Via MCP: request_state({ path: "redactionTest.auth" }).

Actual:

{ "username": "alice", "password": "[REDACTED]", "api_key": "[REDACTED]",
  "tokens": { "access": "access-raw-value", "refresh": "refresh-raw-value" } }

tokens.access / tokens.refresh pass through despite the pattern.

Expected: both redacted. Confirmed the pattern matcher itself works — changing the pattern to tokens.* (relative to the returned subtree) does redact correctly.

Root cause: lib/reactotron-mcp/src/tools.ts:162 calls applyRedaction(stateValue, ...) with the path-scoped subtree, and redact() defaults currentPath = "" (lib/reactotron-mcp/src/redaction.ts:109). So tokens.access is walked with currentPath = "tokens.access" — the user-written absolute pattern redactionTest.auth.tokens.* has no chance of matching.

Why it matters: the settings-modal UI encourages absolute paths (the placeholder example is auth.tokens.*, suggesting patterns anchored to the state root). But those patterns silently no-op as soon as a caller uses a path-scoped request — and LLMs are strongly encouraged to do so by the request_state tool description ("Always specify a path to avoid oversized responses"). State path patterns effectively only work when reading reactotron://state/current (which returns the whole tree).

Suggested fix: thread the requested path through applyRedaction to redact() as the initial currentPath:

// tools.ts
const redactedState = applyRedaction(stateValue, server, serverRedactionConfig, clientId, args.path ?? "")

// redaction.ts
export function applyRedaction(data, server, config, clientId, basePath = "")
// -> return redact(data, rules, basePath)

Same treatment for any other path-scoped code paths that return subtrees.

[joshuayoes]

ℹ️ State path patterns have limited effective surface

Related to the state-path-pattern bug above: in the example app, request_state({ path: "" }) returns only { repo, logo } even though request_state_keys({ path: "" }) correctly reports ["logo", "repo", "error", "redactionTest"]. The error and redactionTest slices initialize with empty or nested-empty payloads and don't appear in the root state snapshot that reactotron-redux pushes.

Combined with the subtree bug, this means state-path patterns written as absolute paths only fire in a narrow window: the reactotron://state/current resource, and only for slices that reactotron-redux bothers to serialize at the root. Worth double-checking whether this is a reactotron-redux serialization quirk or something else — either way, state-path patterns as-designed are more of a last-resort filter than a primary line of defense.

Not blocking this PR — flagging for context.

[joshuayoes]

⚠️ Low severity — AsyncStorage mutations leak when keys/values carry secrets

Caveat up front: AsyncStorage isn't encrypted storage, and no one should be stashing secrets there. But in practice people do — tokens, session blobs, cached auth headers — and the MCP server exposes these mutations verbatim via reactotron://asyncstorage, so it's worth pointing out what does and doesn't redact.

Repro:

AsyncStorage.multiSet([
  ["auth:password", "hunter2"],
  ["auth:api_key", "leaked-api-key"],
  ["auth:accessToken", "leaked-access-token"],
  ["auth:session", JSON.stringify({ password: "hunter2", api_key: "leaked",
                                   note: "Bearer abcdef1234567890ABCDEFGH" })],
])

Actual (via reactotron://asyncstorage):

{
  "pairs": [
    { "0": "auth:password",    "1": "hunter2" },
    { "0": "auth:api_key",     "1": "leaked-api-key" },
    { "0": "auth:accessToken", "1": "leaked-access-token" },
    { "0": "auth:session",     "1": "{\"password\":\"hunter2\",\"api_key\":\"leaked\",\"note\":\"[REDACTED]\"}" }
  ]
}

Only the Bearer value pattern inside the auth:session JSON string got caught. The bare key names (auth:password), the bare values (hunter2), and the password/api_key fields inside the JSON string body all pass through.

Why: the multiSet payload shape is { pairs: [{0: "auth:password", 1: "hunter2"}] }. The redactor walks object keys — pairs, 0, 1 — none of which match sensitive keys. String values are only tested against valuePatterns, and none of the default regexes match bare secrets or namespaced storage keys. Same root issue as the JSON-body gap for network requests.

Pragmatic suggestion:

• In whatever shapes AsyncStorage mutations (summarizeCommand for asyncStorage.mutation), when serializing key / value pairs, split the key on common separators (. : _ /) and test each segment against sensitiveKeys — if any match, redact the value.
• Reuse whatever JSON-string-aware fix ends up landing for the request-body gap here too — a value like {"password":"..."} should get parsed → redacted → re-stringified.

Not security-critical on its own (AsyncStorage isn't encrypted to begin with), but it's the third place where "string values carrying structured data" sidestep the redactor, so the fix probably lands once and covers all three.

[joshuayoes]

BUG — multiSet payloads bypass redactAsyncStorageItem

Severity: medium. Same class as the original AsyncStorage finding from the prior review, but specifically scoped to multiSet / multiRemove / multiMerge — the JSON-string-value branch (introduced by 7a7876e) does fire correctly, so a value that's a stringified JSON blob containing password etc. is redacted. Bare key/value pairs are not.

Reproduction

apps/example-app/app/screens/RedactionTestScreen.tsx (the existing "multiSet sensitive pairs" button) emits:

AsyncStorage.multiSet([
  ["auth:password", "hunter2"],
  ["auth:api_key", "leaked-api-key"],
  ["auth:accessToken", "leaked-access-token"],
  ["auth:session", JSON.stringify({password: "hunter2", api_key: "leaked", note: "Bearer ..."})],
])

Reading reactotron://asyncstorage returns:

{
  "mutations": [{
    "action": "multiSet",
    "data": {
      "pairs": [
        ["auth:password",     "hunter2"],            // ← LEAK
        ["auth:api_key",      "leaked-api-key"],     // ← LEAK
        ["auth:accessToken",  "leaked-access-token"],// ← LEAK
        ["auth:session",      "{\"password\":\"[REDACTED]\",\"api_key\":\"[REDACTED]\",\"note\":\"[REDACTED]\"}"]
      ]
    }
  }]
}

The fourth pair redacts because its value happens to be a JSON-shaped string and goes through redactStringValue. The first three leak completely.

Root cause

The wire format from lib/reactotron-react-native/src/plugins/asyncStorage.ts:69 is:

sendToReactotron("multiSet", { pairs: shippablePairs })  // shippablePairs: [string, string][]

i.e. the React Native AsyncStorageStatic["multiSet"] parameter type, which is [string, string][] — array of two-string arrays.

lib/reactotron-mcp/src/redaction.ts:441-475 (redactAsyncStorageItem) only matches two shapes:

1. { "0": key, "1": value } (object with positional string keys) — line 451
2. { key, value } — line 464

Neither matches a plain [key, value] 2-tuple array. The function recurses through arrays at line 443 (Array.isArray(data) → map), so it descends into pairs, then into each [key, value], then sees two strings and returns them unchanged at line 475.

The entry point also doesn't unwrap data.pairs — applyAsyncStorageRedaction(c.payload?.data, ...) at resources.ts:245 passes {pairs: [...]} straight in. The top-level branch sees an object with no "0" and no "key" keys, so it returns immediately with no recursion into pairs.

Why the test suite doesn't catch this

lib/reactotron-mcp/test/redaction.test.ts:670-742 uses the synthetic {"0": "auth:password", "1": "hunter2"} shape:

const data = [
  { "0": "auth:password", "1": "hunter2" },
  { "0": "auth:api_key", "1": "leaked-api-key" },
  ...
]

That shape is never produced by the RN plugin. The setItem helper at line 32 of the plugin does send { key, value } — covered by the test at line 726 — so the single-set path likely works. multiSet / multiRemove / multiMerge (and their setMulti...Handler cousins, if any) are uncovered.

Suggested fix

In redactAsyncStorageItem, add an array-of-pair branch before the object branches:

function redactAsyncStorageItem(data: unknown, ctx: RedactionContext): unknown {
  // Wire shape: { pairs: [[key, value], ...] }
  if (typeof data === "object" && data !== null && "pairs" in data && Array.isArray((data as any).pairs)) {
    return { ...data, pairs: (data as any).pairs.map((p: unknown) => redactAsyncStorageItem(p, ctx)) }
  }

  // Two-element [key, value] tuple
  if (Array.isArray(data) && data.length === 2 && typeof data[0] === "string") {
    const [key, value] = data
    if (storageKeyIsSensitive(key, ctx.sensitiveKeysLower)) return [key, REDACTED]
    if (typeof value === "string") return [key, redactStringValue(value, ctx)]
    return data
  }

  // existing array recursion (multiGet/multiRemove of bare keys, etc.)
  if (Array.isArray(data)) return data.map((item) => redactAsyncStorageItem(item, ctx))

  // ...existing {0,1} and {key,value} branches
}

And mirror that with a test fixture that uses the actual wire format:

const data = { pairs: [["auth:password", "hunter2"], ...] }

Happy to push the fix as a follow-up commit on this branch if useful.

— Verified end-to-end against feat/mcp-redaction@4e32c650 with iOS sim + Reactotron Electron + MCP curl probe.

[joshuayoes]

Re-QA against b9ec83b9 — ✅ AsyncStorage fix verified, full pass green

Pulled, rebuilt, re-ran the harness against an Android emulator with iOS sim still connected (so the multi-app per-client surface gets exercised in earnest this time).

The original report — closed

multiSet of [["auth:password","hunter2"], ["auth:api_key","leaked-api-key"], ["auth:accessToken","leaked-access-token"], ["auth:session", JSON.stringify({...})]] now reads back as:

{
  "pairs": [
    ["auth:password", "[REDACTED]"],
    ["auth:api_key", "[REDACTED]"],
    ["auth:accessToken", "[REDACTED]"],
    ["auth:session", "[REDACTED]"]
  ]
}

Wire-format 2-tuple branch in redactAsyncStorageItem is doing the work. Storage-key sensitivity wins over the JSON-string-value path for the 4th pair, which is the right priority order.

Other surfaces re-checked

Concern from previous round	Status
createRedactor + per-client cache (9baca65b)	both apps connected simultaneously, each event redacts under its own clientId's rules; iOS sees iosOnlyKey: [REDACTED] + androidOnlyKey preserved, Android sees the inverse, zero bleed
headerNames -> sensitiveKeys collapse (d8587b60)	Authorization / Cookie / X-Api-Key still redact in request headers, in URL params, under non-canonical wrappers like requestHeaders / lastResponse / setCookieArray, and via the literal headers key. Identical to pre-collapse.
Combined-regex valuePatterns + path-tracking skip (1385a0e6)	Bearer, JWT, sk-, ghp_, xoxb- all caught in one pass; multiple secrets across different log lines all redact
JSON-string body parsing	nested extras wrapper with stringified JSON: inner password/api_key redact, outer user preserved

One non-blocking observation worth knowing

After d8587b60 removed mcpRedactionHeaderNames from the electron-store schema, the persisted config.json from a pre-collapse run still had it as a leftover key (silently ignored, harmless), and mcpRedactionSensitiveKeys was the older 30-entry version. Reset to defaults loads the new 40-entry merged list correctly. Users upgrading to this build won't get the merged header names in their saved sensitiveKeys list until they hit Reset — most won't, since their Bearer/Cookie patterns will still catch the values via valuePatterns. Just calling it out.

Approving.

[joshuayoes]

LGTM. Verified end-to-end against b9ec83b9 with iOS sim + Android emulator both connected — AsyncStorage multiSet fix lands the original report, per-client redaction holds across the createRedactor refactor, headerNames collapse is behaviorally identical, combined-regex valuePatterns still catch every default. Comment thread above has the full breakdown.

Two minor things that aren't blockers:

1. The mcpRedactionHeaderNames electron-store key persists after d8587b60 removed it from the schema (silently ignored, but stays on disk). Could add a one-shot migration to delete it on next boot if you want, otherwise it's noise.
2. Existing users upgrading won't get the merged header names in their saved mcpRedactionSensitiveKeys until they hit Reset to defaults. Their Bearer/Cookie values still redact via valuePatterns, but the key-name match for non-Bearer cookie values won't fire on saved configs. Worth a one-liner in the release notes.