fix(guardrails): redact union of overlapping spans, never leak sensitive bookends

[mayankbharati-ops]

Summary

GuardrailEngine.apply walked sorted redact matches right-to-left with a single seen_end cursor and skipped any match whose end exceeded that cursor. When a wider match overlapped — or fully contained — an already-redacted narrower match, the wider match was silently dropped and its prefix / suffix survived in the output.

Concretely, with two rules (wide: super_secret_token_value, inner: secret_token):

	Output
Before (main)	\"data super_[REDACTED:short]_value end\"
After (this PR)	\"data [REDACTED:long] end\"

The super_ and _value fragments of the wider keyword — arguably the sensitive bookends the wider rule exists to cover — leaked into the output. PR #520's earlier fix handled only the same-start subcase (via the secondary sort key); matches with different start offsets that fully contained a narrower match still slipped through.

This also affects the shipped starter rules. With _STARTER_CONFIG in app/guardrails/cli.py, text like config: api_key=AKIAIOSFODNN7EXAMPLE triggers both aws_access_key ([16:36]) and generic_api_token ([8:36]). Before this PR the prefix api_key= leaked; after, the whole span is redacted. Same for aws_secret_access_key=AKIA...xxxxx... where the label and the 40-char tail both leaked pre-fix.

Fix

Replace the single-cursor walk with a proper interval merge:

1. Sort redact matches by (start ASC, -end) so same-start ties put the widest match first — keeps the "longest-keyword-wins" behavior PR fix: overlapping keyword redaction and hardcoded investigation loop limit #520 restored.
2. Sweep left-to-right, merging any match whose start falls before the current interval's end. The representative rule name for the merged interval is the one with the largest original width.
3. Apply replacements right-to-left over the merged intervals so string indices stay valid as each redaction resizes the output.

Adjacent matches (A.end == B.start) intentionally do not merge — they touch but do not overlap. Disjoint matches produce independent redactions with intervening text preserved verbatim. Match-level audit logging is unchanged — every ScanMatch still produces one audit entry, even when multiple matches collapse into a single output redaction, so reviewers tracing audit → output can account for every rule that fired.

E2E validation — full synthetic suites, real Anthropic LLM

HEALTHY_SHORT_CIRCUIT=true, mocked backends, real claude-sonnet-4-6 + claude-haiku-4-5 on the PR #780 branch.

Full EKS suite — 14 scenarios

Result	Count	Details
PASS	11	000-healthy, 001-010 (all non-alerting-state edge-case scenarios)
FAIL	3	011, 012, 013 — all state: alerting, LLM categorization drift on healthy-recovery cases (pre-existing; same failures appear on main / PR #777 verification)

Full RDS suite — 15 scenarios

Result	Count	Details
PASS	11	000-healthy, 001, 003-006, 008-011, 014
FAIL	4	002, 007, 012, 013 — all state: alerting, LLM keyword/categorization drift (pre-existing; identical failures to PR #777 verification run)

Confirmed every failure is in state: alerting (programmatic check on each failing alert.json). The guardrail engine is used for prompt redaction; the synthetic fixtures don't contain overlapping-rule secrets, so the failures above are in territory this PR does not touch.

Unit coverage — 46 tests in tests/test_guardrails/test_engine.py

Test area	Count
Pre-existing suite	36
New regression tests	10
- test_contained_span_redacts_union_no_leak (the core regression)
- test_contained_span_uses_longest_rule_name
- test_partial_overlap_redacts_union
- test_disjoint_matches_stay_separate
- test_adjacent_matches_not_merged
- test_three_way_chain_of_overlaps_redacts_single_union
- test_contained_pattern_with_wider_keyword_preserves_wider_name
- test_real_world_api_key_and_aws_access_key_overlap (uses the exact _STARTER_CONFIG patterns)
- test_real_world_aws_secret_key_contains_aws_access_key (uses the exact _STARTER_CONFIG patterns)
- test_audit_logger_records_every_match_even_when_merged (audit-under-merge invariant)

Existing coverage preserved, including:

• test_overlapping_keyword_redaction_prefers_longest — same-start case (from fix: overlapping keyword redaction and hardcoded investigation loop limit #520)
• test_overlapping_keyword_same_rule_redaction — same-rule overlap
• test_multiple_rules_on_same_span — audit + redact on same span

Verification

• CI (Python 3.13): test (ubuntu-latest) PASS, typecheck PASS, quality PASS, CodeQL PASS, Analyze (python) PASS
• Local pytest tests/ (Python 3.14, no coverage): 2777 pass, 1 skipped, 0 failures (was 2767 on main; +10 new)
• ruff check / ruff format --check: clean on touched files
• mypy app/guardrails/: clean on touched module
• Full EKS + RDS synthetic suites run against real Anthropic LLM on this branch: no new failures introduced vs. main

Scope

One source file (app/guardrails/engine.py, ~40 lines), one test file. No public API changes. No behavior change for non-overlapping matches, audit-only rules, or blocked rules. Directly extends #520, whose same-start case is preserved verbatim.

Security note

The bug class here is sensitive-data disclosure: anywhere guardrail rules are applied to outputs shown to users, logged, or exported, two overlapping rules covering the same secret could each partially redact and leave fragments in the wild. The shipped _STARTER_CONFIG demonstrates this concretely — api_key=AKIA... and aws_secret_access_key=... values containing an access key both produced partial redactions on main. This PR closes the gap.

[greptile-apps]

Greptile Summary

This PR fixes a span-leak bug in GuardrailEngine._redact where overlapping redaction rules (e.g. a wide keyword fully containing a narrower keyword) would silently drop the wider rule's match, leaving its prefix and suffix unredacted in the output. The fix replaces the old single-cursor right-to-left walk with a proper interval merge: sort → left-to-right sweep to merge overlapping spans (tracking the largest individual match width to select the representative rule name) → right-to-left application of replacements to preserve string indices.

Key changes:

• apply delegates to a new _redact(text, matches) method, improving testability and separation of concerns.
• The sort key changes from reverse=True on (start, end) to (start ASC, -end) — preserving the "widest-match-first at same start" behavior from PR fix: overlapping keyword redaction and hardcoded investigation loop limit #520 while enabling a correct forward sweep.
• The seen_end cursor and skip logic are replaced with an O(n) interval merge that handles all three overlap classes: containment, partial overlap, and the transitive chain A∩B, B∩C, A⊥C.
• 7 new regression tests cover all relevant sub-cases; the 36 existing guardrail tests are unaffected.

Confidence Score: 5/5

Safe to merge — the interval merge algorithm is correct, well-documented, and backed by 7 targeted regression tests covering all overlap sub-cases, with zero regressions in the existing suite.

The core fix (left-to-right interval merge replacing the buggy seen_end cursor) is algorithmically correct: overlapping spans are collapsed, the widest individual match wins the representative rule name, adjacent spans remain separate, and right-to-left application preserves string indices. All edge cases (containment, partial overlap, transitive chain, disjoint, adjacent, regex+keyword mix) have dedicated tests. Code follows project style conventions. The only finding is a non-blocking P2 style suggestion to use a NamedTuple instead of a raw 4-tuple for the merged interval list.

No files require special attention.

Important Files Changed

Filename	Overview
app/guardrails/engine.py	Extracts _redact into a dedicated method that performs correct interval merging; the old single-cursor right-to-left walk is fully replaced. Algorithm is sound and well-documented.
tests/test_guardrails/test_engine.py	Adds 7 targeted regression tests covering contained spans, partial overlap, disjoint, adjacent, three-way chain, and pattern-vs-keyword cases. All new tests are well-structured and use the existing _rule helper correctly.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["apply(text)"] --> B["scan(text) → ScanResult"]
    B --> C{any matches?}
    C -- No --> D[return text unchanged]
    C -- Yes --> E[audit each match]
    E --> F{blocked?}
    F -- Yes --> G[raise GuardrailBlockedError]
    F -- No --> H["_redact(text, matches)"]
    H --> I["Filter: action == REDACT\nSort by (start ASC, -end)"]
    I --> J["Left-to-right sweep\nmerge overlapping intervals\ntrack widest individual match\nfor rule-name selection"]
    J --> K["Right-to-left application\nof replacements over\nmerged intervals"]
    K --> L[return redacted text]
    style G fill:#f66,color:#fff
    style L fill:#6c6,color:#fff

Loading

_{Reviews (1): Last reviewed commit: "fix(guardrails): redact union of overlap..." | Re-trigger Greptile}

[greptile-apps]

Consider a NamedTuple for the merged interval for readability

The inner loop reads and writes the merged list by positional tuple index (merged[-1][1], merged[-1][3], etc.). The positions are correct, but the tuple layout (start, end, rule_name, width) is entirely implicit — a reader must mentally map each index to its meaning.

A lightweight NamedTuple would make accesses self-documenting with zero runtime overhead:

from typing import NamedTuple

class _MergedInterval(NamedTuple):
    start: int
    end: int
    rule_name: str
    width: int

Then the sweep body becomes:

merged: list[_MergedInterval] = []
for match in redact_matches:
    width = match.end - match.start
    if merged and match.start < merged[-1].end:
        prev = merged[-1]
        new_end = max(prev.end, match.end)
        if width > prev.width:
            merged[-1] = _MergedInterval(prev.start, new_end, match.rule_name, width)
        else:
            merged[-1] = _MergedInterval(prev.start, new_end, prev.rule_name, prev.width)
    else:
        merged.append(_MergedInterval(match.start, match.end, match.rule_name, width))

This is a non-blocking suggestion; the current code is functionally correct.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!