## TL;DR

The agent wrote secret values into its report because redaction ran too late or not at all. Build redaction into the report writer itself: every value passes through the filter before it touches the output.

## Error

```text
agent failed to redact the secret from its own report: filter error
```

## Steps

1. Find where the secret entered the report: the writer interpolated a raw finding. Expected: the leak point found.
2. Add a redaction filter at the report-writer boundary covering known secret patterns and exact known values. Expected: all output passes through it.
3. Replace matches with a fixed marker and never log the original. Expected: reports contain markers, not values.
4. Test the filter with fixture secrets, including tricky placements (URLs, JSON, multiline). Expected: proven coverage.
5. Regenerate past reports that leaked and purge the old copies. Expected: no lingering exposure.

## When to use

- Agent reports containing secret values.
- Building safe reporting.

## When not to use

- Scanner output redaction (configure the scanner).
- You need the values (then the report must be access-controlled, not redacted).

## Tool compatibility

- Report generators; pattern-based redaction.

## Variant phrasings

### secret leaked in agent report

Filter at the writer.

### redaction filter missed values

Test with fixtures.

## Why it happens

Redaction as an afterthought runs after the value is already in logs, files, or chat; only filtering at write time is reliable.

## Edge cases

- Filters must cover the exact known values, not just patterns.
- Multiline secrets defeat line-based filters; use whole-document matching.
- Redacted reports still describe which secret leaked; keep distribution tight.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tHDNY2dSgTktFI_Z1ZTAig