Should Maka remove all redaction?

[M4n5ter]

English

Proposal

Yes: Maka should remove all redaction.

Here, redaction means any mechanism that examines arbitrary strings and rewrites content suspected of containing secrets after that content has already been produced or transported. This includes:

• generic regex and provider-token matching;
• exact-known-value scrubbing;
• backend, display, and renderer-side secondary redaction;
• streaming redaction state and recovery;
• redacted flags propagated through events and projections;
• masked copies of authoritative content.

Not returning a credential at all is access control/data projection, not redaction. Maka must continue to protect credential stores and omit credential values from read APIs, but it should not maintain a system-wide content-rewriting feature.

The product contract should be explicit

Maka should make no promise to detect or remove secrets from arbitrary user, model, tool, process, error, file, or network content.

Those bytes should remain faithful. If a command prints a secret, it may appear in tool output, events, persistence, and the UI. Users must not assume that a transcript, log, screenshot, or export is safe to share merely because Maka processed it.

This is a narrower but honest contract. The current alternative is a broad promise that cannot be fulfilled consistently.

Why delete the concept instead of improving it?

Maka's security model already describes in-process output redaction as a best-effort heuristic rather than containment. The mechanism does not establish a real security boundary:

1. It acts too late. If a model, tool, or process has already received a secret, rewriting its later output does not protect the secret from that principal.
2. Coverage can never be complete. Secret formats are open-ended, user-defined, encoded, fragmented, and context-dependent.
3. False positives destroy legitimate facts. Hashes, identifiers, URLs, examples, commands, errors, and debugging output can be silently changed.
4. It creates multiple truths. Backend, persistence, memory, search, renderer, copy/export, and streaming paths can observe different versions of the same content.
5. It turns content into protocol state. Chunking, truncation, abort, replay, and reversible matches require recovery state and cross-layer flags.
6. It creates false confidence. A <redacted> marker can be mistaken for a guarantee even though another path may already contain the original value.

A rough inventory on current main finds redactSecrets() at 224 production call sites across 61 files, with at least 39 test files encoding redaction behavior or state. Seven central redaction/streaming files alone contain about 1,836 lines. These numbers indicate architectural reach, not guaranteed removable LOC.

#2990 and #3007 are a useful example: preserving whole-text regex semantics under streaming required a differential oracle, bounded recovery state, truncation rules, and a dedicated state machine. That implementation was correct under the existing contract. The stronger conclusion is that the contract itself is not worth preserving.

Adding more patterns or retaining a “temporary” exact-value scrubber leaves the wrong abstraction alive. Temporary exceptions become permanent compatibility requirements, and every remaining scrubber continues to imply a guarantee it cannot provide.

What remains after redaction is removed

These are security boundaries, not redaction, and should remain:

• protected credential storage;
• secret metadata and references that never expose the stored value;
• write-only set/clear credential mutations;
• read DTOs that return configured: true/false rather than a mask sentinel;
• field allowlists for control-plane telemetry and diagnostics;
• OS, process, renderer, and IPC boundaries already documented as load-bearing.

The hard removal prerequisite is narrow: deleting redaction must not cause credential read APIs to start returning stored values. Any current mask-based settings API should first become an omission-based/write-only contract.

This prerequisite does not extend to arbitrary content channels. If user or tool content contains the same bytes as a credential, Maka will not scan and rewrite it.

What should be future work

If Maka later needs stronger secret isolation, it should be designed as a separate architecture:

• capability or credential references instead of raw values in model context;
• signing/authentication proxies;
• per-tool credential brokers;
• injection only inside a narrow execution boundary;
• explicit, opt-in safe-share/export workflows with their own threat model and guarantees.

None of these should be a prerequisite for deleting the current redaction system. Keeping an unbounded heuristic until a perfect replacement exists only preserves the wrong abstraction indefinitely.

Screen-sharing privacy and DLP are also separate products. If we want them, they should be explicit modes with measurable guarantees—not invisible mutation of Maka's internal source of truth.

Kill list

• redactSecrets() and equivalent generic helpers;
• provider-prefix, authorization-string, URL-query, and opaque-token heuristics;
• exact-known-value scrubbers, including activation/runtime fallback scrubbers;
• separate backend/display redaction grammars;
• renderer-side secondary redaction;
• streaming redaction state, recovery, and differential-oracle machinery;
• redaction-only event fields and redacted propagation;
• masked authoritative content in persistence, memory, search, diagnostics, and error classification;
• the •••••• round-trip sentinel once settings use write-only mutations.

Do not replace these with a new redaction service, compatibility shim, feature flag that becomes permanent, or two long-lived data paths.

Deletion plan

1. Freeze new redaction call sites.
2. Convert credential read surfaces from masked values to omission plus configured metadata; expose explicit write-only set and clear operations.
3. Remove all content redactors, exact-value scrubbers, secondary UI passes, streaming state, flags, and redaction-dependent tests in one coordinated migration.
4. Add fidelity tests proving that arbitrary hashes, tokens, URLs, commands, errors, and chunked output remain unchanged end to end.
5. Add boundary tests proving that credential stores and credential read APIs do not expose stored values by construction—not because a string replacement happened to match.
6. Update the security model and user-facing documentation to state clearly that Maka provides no arbitrary-content secret detection or DLP guarantee.
7. Track capability-based secret handling and safe-share/export as independent future proposals.

What would falsify this proposal?

The proposal should be rejected if Maka has a concrete regulatory, contractual, or approved product requirement to perform DLP over arbitrary unstructured content.

If that requirement exists, the answer is still not to preserve today's regex system by default. We should specify the protected principals, supported secret classes, false-positive/false-negative targets, enforcement points, and audit requirements, then design a real DLP system against that contract.

Absent such a requirement, redaction is complexity without a defensible guarantee and should be deleted.

Decisions needed

1. Do we agree that Maka provides no secret detection/DLP guarantee for arbitrary content?
2. Do we agree that exact content fidelity is the default for user/model/tool/runtime data?
3. Which credential read APIs still rely on masked values and must become omission-based before deletion?
4. Do we agree to delete every redaction implementation rather than retain scoped or temporary scrubbers?
5. Should future capability-based secret handling and safe-share/export be tracked as separate designs with no compatibility dependency on today's redaction behavior?

简体中文

提案

是的：Maka 应该删除所有脱敏。

这里的“脱敏”是指：在任意字符串已经产生或传输之后，再检查其中疑似 secret 的内容并改写它。包括：

• 通用正则和 provider token 匹配；
• 基于已知 secret 精确值的 scrubber；
• backend、display 和 renderer 二次脱敏；
• 流式脱敏状态与 recovery；
• 在 event 和 projection 中传播的 redacted flag；
• 对权威内容生成的 masked copy。

完全不返回 credential 属于访问控制/数据投影，不是脱敏。Maka 必须继续保护 credential store，并从读取 API 中省略 credential value，但不应继续维护一套全局内容改写功能。

产品契约应该明确

Maka 应明确不承诺识别或删除任意 user、model、tool、process、error、file 或 network content 中的 secret。

这些字节应该保持原样。如果某条命令打印了 secret，它可能出现在 tool output、event、persistence 和 UI 中。用户不能因为内容经过 Maka 处理，就默认 transcript、log、截图或 export 可以安全分享。

这是一个更窄但诚实的契约。当前替代方案则是在暗示一个无法稳定兑现的宽泛承诺。

为什么应该删除这个概念，而不是继续改进？

Maka 的安全模型已经把进程内输出脱敏描述为 best-effort heuristic，而不是 containment。它并没有建立真实安全边界：

1. 它发生得太晚。 如果 model、tool 或 process 已经拿到 secret，改写后续输出无法保护 secret 不被该主体获取。
2. 覆盖不可能完备。 Secret 格式是开放的、用户自定义的、可编码的、可分片的，并且依赖上下文。
3. 误报会破坏合法事实。 Hash、标识符、URL、示例、命令、错误和调试输出可能被静默改写。
4. 它制造多个事实版本。 Backend、persistence、memory、search、renderer、copy/export 和 streaming 可能看到同一内容的不同版本。
5. 它把内容变成协议状态。 Chunk、截断、abort、replay 和可逆匹配需要 recovery state 与跨层 flag。
6. 它制造错误安全感。 <redacted> 很容易被理解成安全保证，但其他路径可能早已包含原始值。

对当前 main 的粗略盘点显示：redactSecrets() 分布在 61 个生产文件的 224 个调用点；至少 39 个测试文件固化了脱敏行为或状态。仅 7 个核心脱敏/流式文件就约有 1,836 行代码。这些数字只表示架构影响面，不代表保证可删除的行数。

#2990 和 #3007 是很好的例子：为了在流式场景维持全量正则语义，系统需要 differential oracle、有界 recovery state、截断规则和专用状态机。在现有契约下，这个实现是正确的；更强的结论是，这个契约本身不值得保留。

继续增加 pattern，或者保留“临时”的 exact-value scrubber，都会让错误抽象继续存活。临时例外最终会成为永久兼容要求，而任何残留 scrubber 都会继续暗示它无法提供的保证。

删除脱敏后保留什么

以下属于安全边界而不是脱敏，应该保留：

• 受保护的 credential storage；
• 永不暴露存储值的 secret metadata 和 reference；
• write-only 的 credential set/clear mutation；
• 返回 configured: true/false 而不是 mask sentinel 的 read DTO；
• control-plane telemetry 与 diagnostics 的字段白名单；
• 安全文档中已经明确为 load-bearing 的 OS、process、renderer 与 IPC 边界。

删除前唯一的硬性前置条件很窄：删除脱敏不能导致 credential read API 开始返回已存储值。 当前任何依赖 mask 的 settings API，都应先改成字段省略加 write-only contract。

这个前置条件不扩展到任意内容通道。如果 user 或 tool content 中包含与某个 credential 相同的字节，Maka 不会扫描并改写它。

哪些应该交给未来解决

如果 Maka 未来需要更强的 secret 隔离，应该将其设计为独立架构：

• model context 只接收 capability 或 credential reference，不接收 raw value；
• signing/authentication proxy；
• per-tool credential broker；
• 只在狭窄执行边界内部注入；
• 有独立威胁模型和保证的显式、可选 safe-share/export workflow。

这些都不应成为删除当前脱敏系统的前置条件。在完美替代方案出现之前保留无边界 heuristic，只会让错误抽象无限期存在。

屏幕分享隐私和 DLP 也是独立产品。如果确实需要，就应该做成具有可度量保证的显式模式，而不是隐式修改 Maka 的内部事实源。

Kill list

• redactSecrets() 及等价通用 helper；
• provider prefix、authorization string、URL query 和 opaque token heuristic；
• exact-known-value scrubber，包括 activation/runtime fallback scrubber；
• backend/display 两套独立脱敏 grammar；
• renderer 二次脱敏；
• 流式脱敏状态、recovery 和 differential-oracle 机制；
• 只为脱敏存在的 event 字段与 redacted 传播；
• persistence、memory、search、diagnostics 和 error classification 中的 masked 权威内容；
• settings 改为 write-only mutation 后的 •••••• 往返 sentinel。

不要用新的 redaction service、兼容 shim、最终永久化的 feature flag，或者两条长期并存的数据路径替代它们。

删除计划

1. 冻结新增脱敏调用点。
2. 将 credential read surface 从 masked value 改成字段省略加 configured metadata；提供明确、write-only 的 set 和 clear 操作。
3. 在一次协调迁移中删除所有 content redactor、exact-value scrubber、UI 二次处理、流式状态、flag 和依赖脱敏的测试。
4. 增加 fidelity test，证明任意 hash、token、URL、命令、错误和分块输出在端到端保持不变。
5. 增加边界测试，证明 credential store 与 credential read API 从结构上就不会暴露存储值，而不是依赖某次字符串替换恰好匹配。
6. 更新安全模型与用户文档，明确 Maka 不提供任意内容 secret detection 或 DLP 保证。
7. 将 capability-based secret handling 和 safe-share/export 作为独立未来提案跟踪。

什么证据可以推翻本提案？

如果 Maka 存在明确的监管、合同或已批准产品要求，必须对任意非结构化内容执行 DLP，那么本提案应被否决。

即便存在这个要求，答案仍然不是默认保留当前正则系统。我们应该先明确受保护主体、支持的 secret 类型、误报/漏报目标、执行点和审计要求，再围绕该契约设计真正的 DLP 系统。

如果不存在这种要求，那么脱敏就是一套没有可辩护保证的复杂度，应该删除。

需要决定的问题

1. 我们是否同意 Maka 不对任意内容提供 secret detection/DLP 保证？
2. 我们是否同意 user/model/tool/runtime 数据默认保持内容保真？
3. 哪些 credential read API 仍依赖 masked value，必须在删除前改成字段省略？
4. 我们是否同意删除每一种脱敏实现，而不是保留局部或临时 scrubber？
5. 未来 capability-based secret handling 与 safe-share/export 是否应作为独立设计跟踪，并且不再兼容今天的脱敏行为？

[Astro-Han]

Support this direction. I audited current main (b69898c) against decisions 3 and 4; findings below.

Decision 3 — masked-value read surfaces. Four fields currently round-trip a mask sentinel:

1. network.proxy.password and webSearch.providers.tavily.apiKey — already backed by the credential store; queryCredential returns configured/revision metadata, and the sentinel is only the settings-form round-trip token. Converting these to write-only set/clear is a small, well-defined change.
2. botChat.channels.telegram.token and botChat.channels.feishu.appSecret — stored plaintext in the regular settings store; the mask in maskAppSettings() is their only read-side protection. These need a real home (credential store or write-only patch semantics) before omission is safe.

Two sentinel constants coexist for the same fact (SENSITIVE_PLACEHOLDER = 8 bullets, MASKED_TOKEN_SENTINEL = 6), and the preload boundary checks both. The export path (stripSettingsSecretsForExport) already demonstrates the target omission-based contract. Separately, maskedTokenForDisplay() in packages/core/src/web-search.ts has zero production consumers — only its own test keeps it alive; it can be deleted today regardless of this proposal.

Decision 4 — agreed, no survivors. One concrete false positive to add to the evidence: the backend redactor's \b([a-f0-9]{40,})\b catch-all (and the display redactor's equivalent) rewrites full git commit SHAs in git log tool output to [redacted] — persisted authoritative content silently corrupted, exactly the multiple-truths problem in section 4. The two "Adapter MUST scrub secrets" contract comments on ErrorEvent.details / RuntimeEventErrorContent.details are also protocol-level promises that must be explicitly withdrawn, not just deleted.

Worth noting for the deletion plan: packages/storage/src/activation-secret-injector.ts is injection at a narrow boundary, not redaction — it is already a seed of the capability-based direction in "future work" and should be named as a keep.

(Drafted with AI assistance; I verified every claim against main source and git history.)

简体中文

支持这个方向。我基于当前 main（b69898c3）核对了 decision 3 和 4，结论如下。

Decision 3 —— masked-value 读取面。 目前有四个字段在读取时往返 mask sentinel：

1. network.proxy.password 和 webSearch.providers.tavily.apiKey——已经由 credential store 支撑；queryCredential 返回 configured/revision 元数据，sentinel 只是 settings 表单的往返令牌。把它们改成 write-only 的 set/clear 是小而明确的改动。
2. botChat.channels.telegram.token 和 botChat.channels.feishu.appSecret——以明文存在普通 settings store 中，maskAppSettings() 里的 mask 是它们在读取侧唯一的保护。在改成字段省略之前，这两个需要先有一个真正的归宿（credential store 或 write-only patch 语义）。

同一个事实并存着两个 sentinel 常量（SENSITIVE_PLACEHOLDER 8 个圆点，MASKED_TOKEN_SENTINEL 6 个），preload 边界不得不同时判断两者。导出路径（stripSettingsSecretsForExport）已经示范了目标形态：基于字段省略的契约。另外，packages/core/src/web-search.ts 里的 maskedTokenForDisplay() 没有任何生产消费方——只有它自己的测试在维持它存活；无论本提案是否通过，它今天就可以删除。

Decision 4 —— 同意，一个都不留。 补充一个具体的误报证据：后端 redactor 的 \b([a-f0-9]{40,})\b 兜底规则（以及 display redactor 的等价规则）会把 git log 工具输出里完整的 commit SHA 改写成 [redacted]——被持久化的权威内容遭到静默破坏，这正是正文第 4 条"多个事实版本"问题的现成实例。ErrorEvent.details / RuntimeEventErrorContent.details 上两条 "Adapter MUST scrub secrets" 契约注释也是协议层承诺，删除时应该明确撤销，而不是悄悄删掉。

对删除计划还有一点值得说明：packages/storage/src/activation-secret-injector.ts 是在狭窄边界内做注入，不是脱敏——它已经是"未来工作"中 capability-based 方向的雏形，应该被明确列为保留项。

（本评论由 AI 辅助起草；每条论断我都已对照 main 源码和 git 历史核实。）