security(ui): make streaming display redaction differential-safe

[M4n5ter]

English

Problem

Streaming assistant and thinking text currently stays safe by re-running redactSecrets over the accumulated display text. PR #2975 briefly attempted to optimize this with bounded incremental state, but review found that the incremental path could diverge from whole-text redaction: some chunk boundaries exposed secret suffixes, while others redacted legitimate opaque text.

#2975 therefore keeps the existing whole-text security boundary. A future optimization needs a stronger contract than a collection of regex examples.

Required behavior

• For every input prefix and every possible chunking, the visible result must be exactly equivalent to applying redactSecrets to that full prefix, subject only to the existing documented display truncation.
• No intermediate, aborted, errored, or truncated state may reveal bytes that whole-text redaction classifies as secret.
• Normal text must not be redacted solely because tokens happen to cross chunk boundaries.
• The implementation must remain bounded in retained state and demonstrate a material improvement on realistic long streams before replacing the current path.

Validation

Add differential/property tests over arbitrary chunk boundaries, including:

• API keys and authorization values containing separators such as /, ., =, _, and -;
• JWT-like values and long opaque hexadecimal/alphanumeric strings;
• legitimate hashes adjacent to paths or punctuation;
• one-character chunks, long whitespace, truncation boundaries, stream completion, abort, and error;
• randomized inputs comparing every streamed prefix with the whole-text oracle.

Keep a benchmark for a long response delivered in small deltas, but treat security equivalence as the hard constraint.

Related: #2975

中文

问题

Assistant 与 thinking 的流式文本目前通过对累计显示文本重复执行 redactSecrets 来保证安全。#2975 曾尝试用有界增量状态优化这条路径，但 review 发现增量结果可能偏离全量脱敏语义：部分切块会暴露 secret 后缀，另一些切块会误伤正常的 opaque text。

因此 #2975 保留现有的全量文本安全边界。后续优化需要先定义严格契约，而不是继续补充正则样例。

必须满足的行为

• 对任意输入前缀和任意切块方式，可见结果都必须与对该完整前缀执行 redactSecrets 严格等价，唯一例外是已有且明确记录的显示截断。
• 中间态、abort、error 和截断状态都不能暴露被全量脱敏判定为 secret 的内容。
• 正常文本不能仅因为 token 跨越 chunk 边界而被误脱敏。
• 实现必须保持有界状态；只有在真实长流基准中证明有显著收益后，才替换当前路径。

验证

增加覆盖任意切块边界的 differential/property tests，包括：

• 包含 /、.、=、_、- 等分隔符的 API key 与 authorization value；
• JWT 类值以及较长的十六进制/字母数字 opaque string；
• 紧邻路径或标点的合法 hash；
• 单字符 chunk、长空白、截断边界、stream completion、abort 与 error；
• 随机输入，并在每个流式前缀上与全量 oracle 对比。

保留“小 delta 组成长回复”的性能基准，但安全等价性是硬约束。

关联：#2975

[Mingqwqqaq]

I'd like to take this issue.

Plan

1. Add the differential oracle before changing the production path.

   • Compare every assistant/thinking display prefix against
     redactSecrets(completeSourcePrefix).
   • Cover exhaustive chunkings for short inputs and deterministic property
     tests for longer inputs.
   • Include /, ., =, _, -, JWTs, opaque tokens, valid hashes,
     arbitrary whitespace, replayed deltas, and Unicode boundaries.

2. Model truncation as part of the streaming state.

   • Keep per-delta truncation separate from total-cap state.
   • Preserve whether discarded input remains inside an authorization, API-key,
     query-secret, provider-token, or opaque-token candidate.
   • Verify that the next delta after truncation cannot reveal a secret suffix.
   • Preserve the existing assistant head-keep and thinking tail-keep behavior.

3. Establish a bounded-state proof before replacing whole-text redaction.

   • Explicitly handle the reversible opaque-token case where a 40+ character
     prefix is initially redacted but later becomes legitimate text.
   • Bound recovery data according to the existing display cap without changing
     when that cap becomes visible.
   • Keep raw recovery data outside enumerable React/live projection state.

4. Avoid duplicating the redaction grammar.

   • Derive incremental matcher/stability metadata from the same pattern
     definitions used by redactSecrets, so future pattern changes cannot make
     the streaming path silently diverge.

5. Integrate assistant and thinking independently.

   • Cover completion, abort, error, replay, per-delta truncation, and total
     truncation.
   • Remove private recovery state on every terminal path.
   • Keep the existing whole-text implementation until the differential suite
     passes.

6. Benchmark the real integration path.

   • Run realistic long responses delivered in small deltas through
     applyAssistantDelta, applyThinkingDelta, and live projection.
   • Use warm-ups and multiple measured runs.
   • Treat performance as a reported measurement; differential security
     equivalence remains the hard requirement.

[Astro-Han]

One broader question may be worth separating from the streaming optimization: should display redaction remain a security boundary at all?

The current contract protects the rendered UI. It does not prevent a secret from reaching the model, tool output, runtime events, session persistence, IPC, logs, or telemetry. By the time the renderer replaces a value with <redacted>, the Agent and several internal layers may already have handled the raw value.

That leaves an important threat-model question: who are we hiding the value from? If the UI is visible only to the user who owns the session, display masking mainly protects screen sharing and screenshots. That can be a useful privacy feature, but it is different from preventing the Agent from reading or disclosing a secret.

A simpler long-term design may be to move the boundary upstream:

• give the Agent credential handles or capabilities instead of raw values;
• inject credentials only at the tool or process execution boundary;
• sanitize tool output before it enters model context, runtime events, persistence, or IPC;
• keep raw secrets out of assistant and thinking events entirely.

If those invariants hold, the main assistant and thinking render paths no longer need to maintain a second, regex-based security system across chunking, replay, truncation, abort, and recovery. Display masking could then be removed or kept as an explicit privacy mode rather than treated as the primary secret boundary. This would also avoid false positives that hide legitimate hashes, examples, and debugging output.

I do not think this needs to block #3007. The current implementation exists today, and a differential-safe incremental path is still a useful optimization while the larger architecture is evaluated. I would keep #3007 focused on preserving the current contract, then open a separate architecture issue to document the threat model, trace every place raw secrets can enter the system, and decide whether display redaction can be deleted.

This position was developed with AI-assisted code-path analysis using Codex and Claude; I verified the architectural boundaries and the distinction between display privacy and Agent access.

中文

这里还有一个更基础、也适合与流式性能优化分开讨论的问题：显示层脱敏是否应该继续作为安全边界？

当前契约保护的是最终渲染出来的 UI。它无法阻止 secret 进入 model context、tool output、runtime event、session persistence、IPC、日志或遥测。等 renderer 把内容替换成 <redacted> 时，Agent 和多个内部层可能已经处理过原始值。

因此需要先明确威胁模型：我们究竟不希望谁看到这个值？如果 UI 只对拥有该 session 权限的用户可见，那么显示遮罩主要保护的是共享屏幕、截图和录屏。这可以是一项有价值的隐私功能，但它与“不要让 Agent 读到或泄露 secret”是两个不同的问题。

更简单的长期设计可能是把边界上移：

• Agent 只获得 credential handle 或 capability，不获得原始值；
• 只在 tool 或进程执行边界注入 credential；
• tool output 在进入 model context、runtime event、持久化或 IPC 前完成清理；
• assistant 和 thinking event 中从一开始就不出现 raw secret。

如果这些不变量成立，assistant 和 thinking 的主要显示路径就不需要再维护一套跨 chunk、replay、truncation、abort 和 recovery 的正则安全系统。显示遮罩可以被删除，或收敛为明确的可选 privacy mode，而不是承担主要的 secret 安全职责。这样也能减少对正常 hash、示例和调试内容的误伤。

这不需要阻塞 #3007。现有方案仍在生产路径中，在更广泛的架构评估完成前，把它优化为 differential-safe 的增量实现仍然有价值。建议让 #3007 继续聚焦于保持现有契约，再单独建立一个架构议题，明确威胁模型，追踪 raw secret 进入系统的所有路径，并判断是否可以删除显示层脱敏。

本观点使用 Codex 与 Claude 辅助分析代码路径；我核对了相关架构边界，以及显示隐私与 Agent 访问之间的区别。