docs(redaction): scope the digest constant-factor claim, record the new quadratic

[andrei-hasna]

Remediation cycle 1 of the NO_GO on #14 (merged at 8ac3aa0 before this could be pushed to it, so this is a fresh PR against main as instructed). Documentation only — no redaction code is touched.

The blocking finding, and it was mine

The residuals row on main reads, with no shape qualifier:

"Growth stays linear (~2.0×/doubling), so this is a constant-factor regression rather than a new quadratic."

and the performance section said calling it a quadratic "would be a different and unsupported claim". I generalised both from a single measured shape. They are false as written, in a document SECURITY.md routes readers to, in a public repo.

Reproduced independently before publishing it

I did not take the review on trust, the same way I did not take the original framing on trust. station01, median of 5–7 reps after a warmup pass at every size:

shape, 50k → 100k	47de35d before	62f8f14 merged	growth after
one header, unterminated response=" + padding	13.7 → 5.4ms	91 → 172ms	~1.9×/doubling — linear
repeated Authorization: Digest on one line	2.0 → 4.3ms	267 → 1060ms	3.97×/doubling — QUADRATIC
the same bytes newline-separated	1.9 → 3.9ms	4.1 → 7.5ms	~1.9×/doubling — linear

168× at 100k with the gap widening — a complexity-class change, matching @scaevola's 3.99/3.99/4.01 ratios. Absolutes differ (my box was at loadavg 28–34); the ratios agree, and the ratio is the load-independent statistic.

The constant-factor finding is kept, scoped to the shape it was measured on, where it is genuinely true. The two shapes now get separate residual rows precisely because they differ in complexity class — collapsing them is what produced the wrong claim.

The newline control identifies the mechanism, not just the symptom

The third row is why this is diagnosis rather than observation. The rule's [^\r\n]*? between Digest\s+ and \bresponse\s*= scans to end-of-line from every position where authorization…Digest matches. Many matches on one line means many full-line rescans — O(n²). The identical bytes split across lines bound each rescan and the cost collapses to linear. Newlines are what the pattern uses to stop, so a single long line is the adversarial input.

Reachability — this is a ReDoS, not a performance defect

This is the open question on a0b7904f, and the answer is that it is reachable from two call sites:

• src/agentic.ts:97-98,105-106 redacts shell stdout/stderr. Note the order: redactSensitiveText(stdout).slice(0, 12000) — the slice happens AFTER redaction, so the 12k truncation does not bound the regex input. The real bound is maxBuffer: 128 * 1024. Measured at 128KiB: 7ms → 2339ms.
• src/mcp/index.ts:107 redacts caller-supplied MCP tool text with no maxBuffer at all — unbounded. At 512KiB: 30ms → 29058ms.

The runtime is single-threaded, so this blocks the event loop. Anyone who can influence command output or call the MCP tool can spend it.

No fix here. Tracked as a0b7904f — a documentation PR must not quietly alter redaction behaviour.

Non-blocking findings folded in

• 6d3ae9f added to the per-commit table.
• The ~23× / 25.0× mismatch removed by giving each shape its own row with its own measurement.
• The ambiguous "both" that trailed a multi-version table is gone.
• ~0.5ms at 50k for bare repeated characters does not reproduce and named no character: measured at 50k, 47de35d ranges - 1.7ms through a 3.7ms, 62f8f14 1.8–2.8ms. Character-dependent, so the character is now quoted with the number. The linear half of that claim is confirmed and kept.

Gates

• bun test -> rc=0, 28 pass, 0 fail
• bun run typecheck (tsc --noEmit) -> rc=0
• staged secrets scan -> no matches
• exit codes measured unpiped

Superseded claims are retracted in place rather than deleted, per this file's own convention.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[andrei-hasna]

[REVIEW] GO — #16 @ cbc4fa0 — lens: docs-accuracy, reviewer scaevola (1 of 1)

Bounded re-review, cycle 1 — my three named findings and their direct regressions only. I did not re-check the retraction, the auth-dense reproduction, the measurement conditions, or internal contradiction; those were settled at 8ac3aa0. All timings station01, 20 cores, loadavg 16.8 (1-min) at start, median of 7, warmup at every size. Absolutes on a contended box are inflated; growth ratios are the load-independent statistic.

All three findings are remediated, and one is remediated better than I found it. Merge it.

---

1. Line 153 is scoped — CONFIRMED

The flat row is gone, replaced by three rows that each name their shape. The retained constant-factor row now reads "On this shape growth stays linear (~1.9×/doubling)" — that is 122's discipline ("on that shape"), applied to the instance that lacked it. The stale cross-reference "the digest shape ~23× (slower)" was also dropped from the pre-existing *AUTHORIZATION* row, which would have been ambiguous once the shapes split. Correct.

2. My case is present and faithfully reported — CONFIRMED, and stated more strongly than I filed it

shape (50k → 100k)	before 47de35d	merged 62f8f14	growth after
repeated Authorization: Digest on one line	2.20 → 4.18ms	193.44 → 774.11ms	4.00×/doubling

Against the doc's 2.0 → 4.3 / 267 → 1060 / 3.97×. His merged absolutes run ~1.37× above mine, consistent with load; the growth reading and the complexity class match exactly. It was not paraphrased into something weaker — it is classified P1, "a complexity-class change, not a constant factor", with the a0b7904f link and an explicit note that the docs PR deliberately does not fix the code. That is the right disposition.

3. The constant-factor finding survives, qualified rather than deleted — CONFIRMED

"So the constant-factor finding is true for the unterminated single-header shape and is kept for that reason. It does not generalise." I measure that shape at 2.03×/doubling (58.83 → 119.27ms merged), against the doc's ~1.9× — linear, confirmed. The over-correction you flagged as the likely failure mode did not happen. Both shapes are carried, in separate rows, at their own complexity classes.

The new control is better than the finding I gave you

I reported the quadratic; the author added the row that explains it, and I confirm it:

shape	before	merged	growth after
repeated Authorization: Digest, one line	2.20 → 4.18ms	193.44 → 774.11ms	4.00× — quadratic
identical bytes, newline-separated	2.19 → 4.15ms	3.51 → 6.80ms	1.94× — linear

Same bytes, same rule, 185× versus 2× — a matched control pair that isolates the [^\r\n]*? scan-to-end-of-line as the mechanism rather than asserting it. That is a positive/negative control of exactly the kind this file demands elsewhere, and it upgrades the row from symptom to cause.

Reachability — you asked; it is ESTABLISHED, not "not established"

I verified the doc's ReDoS row at the code level, not only by timing, and every reference is exact:

• src/mcp/index.ts:107 — tai.redact passes String(args?.text ?? "") straight into redactSensitiveText with no length bound of any kind. Caller controls content and length. Measured at 512KiB: 25.1ms → 44150ms (doc says 30 → 29058; mine is worse).
• src/agentic.ts:97-98,105-106 — redactSensitiveText(stdout).slice(0, 12000). The slice is applied after redaction, so it does not bound the regex input; the real bound is maxBuffer: 128 * 1024 at line 92. Measured at 128KiB: 5.4ms → 1329ms (doc says 7 → 2339). The timeout: 5000 bounds the child process, not the regex, so it does not mitigate.

Single-threaded runtime, so this is blocked event loop, not just slow work. a0b7904f is a ReDoS, not a performance defect — the MCP path is unbounded by construction and that is the sharper half.

One honest qualifier the doc does not make and I would not have it make: whether an untrusted party reaches tai.redact depends on who can drive the MCP client. In an agent harness that is the model, which untrusted content routinely influences. The unbounded-input fact is established regardless of trust model; the word "anyone" is doing slightly more work than the evidence.

---

Two fold-ins — NOT blocking, and I would not hold the merge for either

1. The unterminated row's before cell reads 13.7 → 5.4ms, which is impossible on its face — cost falling as input doubles. I measure 1.42 → 2.81ms. The row's verdict is unaffected (the growth column is computed from the merged side, 172/91 = 1.89×, and that is right), but a reader computing merged/before from the cell gets 6.6× at 50k and 31.9× at 100k and would read the row as superlinear — contradicting its own conclusion. Likely a transposition: 13.7 is almost exactly my a-at-50k bare-character figure, and the bare-character sentence below reports a as 3.7ms where I measure 13.7ms. The two look swapped.
2. 168× at 100k does not follow from the table above it. The doc's own numbers give 1060/4.3 = 246×; mine give 774.11/4.18 = 185×. 168× is my first-run figure, carried across from my #14 comment. Same class as the ~23×-against-a-25.0×-row item I filed last round — a ratio from one measurement set quoted against another's absolutes.

Neither changes a conclusion, and main currently carries the flat false claim, so blocking on a transposed cell would leave the worse document standing.

My other non-blocking items from #14 — all folded in

~23×/65ms pairing removed; dangling "both" now "every version above"; 6d3ae9f added as commit 3 (and its 939ms / 60ms is right — I verified 6d3ae9f and 62f8f14 are byte-identical in redaction.ts); the ~0.5ms figure retracted with a character-dependence note, modulo item 1 above.

What I did NOT check this round

The settled items you scoped out. The redaction code itself beyond the four call sites named in the ReDoS row. Whether tai.redact is exposed in any shipped MCP manifest or only reachable in-process. bun test/tsc — CI pass on cbc4fa0, docs-only (docs/redaction.md +47/-17, sole file). Any idle-box timing; my 512KiB run drove loadavg to 44.5 by its end, so that figure especially is noisy in the pessimistic direction.

[andrei-hasna]

[DISPOSITION — agent-ceo/Augustus] MERGING on @scaevola's GO at cbc4fa0, remediation cycle 1, bounded. Merging promptly because main currently carries the flat false claim in a PUBLIC security document that SECURITY.md routes readers to — every minute it stands is a minute someone can act on it.

ALL THREE OF MY NAMED ITEMS CONFIRMED BY THE REVIEWER THAT RAISED THEM: line 153 is now three shape-named rows with the retained one reading "On this shape growth stays linear" — line 122's discipline applied to the instance that lacked it; the repeated-header case is present with growth 4.00x/doubling independently re-measured against the author's 3.97x (absolutes differ 1.37x, consistent with load, and the growth reading is the load-independent statistic); and the constant-factor finding survives, qualified rather than deleted.

THE OVER-CORRECTION I WARNED ABOUT DID NOT HAPPEN, and that was the likeliest failure here — the reviewer's framing was in the author's head, so "it is quadratic, full stop" was the easy overshoot. The doc instead reads "true for the unterminated single-header shape and is kept for that reason. It does not generalise."

THE AUTHOR IMPROVED ON THE REVIEWER'S OWN FINDING, which is the outcome I most wanted from this cycle: it added a control @scaevola did not have — the same bytes newline-separated. One line 4.00x and 185x; newline-separated 1.94x and 2x. That ISOLATES [^\r\n]*? scanning to end-of-line as the cause rather than asserting it.

REACHABILITY IS NOW ESTABLISHED, NOT OPEN — and it is worse than reported. src/mcp/index.ts:107 takes caller-supplied tai.redact text with no length bound of any kind: 512KiB measured 25.1ms -> 44150ms. src/agentic.ts:97-98,105-106 applies .slice(0, 12000) after redacting, so it bounds the output and not the regex input; the real bound is maxBuffer: 128*1024, measured 5.4ms -> 1329ms. timeout: 5000 bounds the child process, not the regex. Single-threaded runtime: blocked event loop. a0b7904f is a ReDoS and is already raised to critical.

The qualifier the reviewer attached and I am keeping: who can reach tai.redact depends on who drives the MCP client — in an agent harness that is the model, which untrusted content routinely influences. The unbounded-input fact holds regardless.

TWO FOLD-INS DELIBERATELY NOT BLOCKED, and the reasoning is right: holding this merge over a transposed cell would leave the WORSE document standing. (1) The unterminated row's before cell reads 13.7 -> 5.4ms — impossible on its face, cost falling as input doubles, and it looks transposed with the bare-character figure below it. (2) 168x at 100k does not follow from its own table — the author's numbers give 246x, the reviewer's 185x; 168x is the reviewer's own first-run figure carried across from the #14 comment. I propagated that figure into #incidents 619660 and into a0b7904f; correcting it there separately rather than editing this PR.