[GH-ISSUE #6334] [Feature] Add opt-in redaction profiles for shareable analysis reports #3819

New issue

Open

opened 2026-10-31 00:44:22 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:44:22 +00:00

Owner

Originally created by @jayykernel on GitHub (Oct 22, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6334

Problem

Analysis reports can include environment-specific values such as local paths, hostnames, or other sensitive metadata. Users who want to share a report may need to manually edit it, which is error-prone and can accidentally remove context needed to interpret the result.

Desired outcome

Offer an explicit redaction step for exported reports, with clear boundaries between original evidence and the redacted representation.

Proposed behavior

Define a documented, configurable set of supported fields that can be redacted.
Make redaction opt-in and select it at export time.
Mark redacted values clearly and preserve structural validity.
Avoid changing the source artifact or stored/original analysis result.
Document fields that cannot safely be redacted without changing meaning.

Acceptance criteria

The same report and profile produce deterministic redacted output.
Tests cover nested data, missing fields, and partially redacted records.
Redaction does not silently drop findings or break references between evidence records.
The output makes clear that redaction occurred.

Scope

This is a report-export feature, not a guarantee that arbitrary free-form evidence contains no secrets. The documentation should state its limits and avoid promising complete secret detection.

Originally created by @jayykernel on GitHub (Oct 22, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6334 ### Problem Analysis reports can include environment-specific values such as local paths, hostnames, or other sensitive metadata. Users who want to share a report may need to manually edit it, which is error-prone and can accidentally remove context needed to interpret the result. ### Desired outcome Offer an explicit redaction step for exported reports, with clear boundaries between original evidence and the redacted representation. ### Proposed behavior - Define a documented, configurable set of supported fields that can be redacted. - Make redaction opt-in and select it at export time. - Mark redacted values clearly and preserve structural validity. - Avoid changing the source artifact or stored/original analysis result. - Document fields that cannot safely be redacted without changing meaning. ### Acceptance criteria - The same report and profile produce deterministic redacted output. - Tests cover nested data, missing fields, and partially redacted records. - Redaction does not silently drop findings or break references between evidence records. - The output makes clear that redaction occurred. ### Scope This is a report-export feature, not a guarantee that arbitrary free-form evidence contains no secrets. The documentation should state its limits and avoid promising complete secret detection.

bsakaguchi commented

2026-10-31 00:44:22 +00:00

Author

Owner

@Xipong commented on GitHub (Oct 29, 2026):

A concrete HAR case for the proposed opt-in export/redaction profiles, independently exercised with rea-agents 6.7.0 on Linux/WSL:

inspect_web_network_capture {capture_path:<synthetic HAR>, format:"har"} excluded Authorization/cookie values, but retained a synthetic query-token value QUERY_CANARY, an X-Api-Key value KEY_CANARY, and response-body text BODY_CANARY. Adding sensitive_values:["QUERY_CANARY","KEY_CANARY","BODY_CANARY"] removed these markers from the complete retained Evidence, including the parameters. No real credentials or network requests were involved.

This is the existing declared/literal-redaction contract, not a newly demonstrated credential leak. It is a useful acceptance case for this feature: make the distinction between original local evidence and a deliberately shareable representation visible; offer configurable common app-credential surfaces or a clear warning when only transport exclusions are active, without silently rewriting the original evidence or promising universal secret detection.

I inspected current main's CaptureRedaction source; it still distinguishes known transport credentials from explicitly declared literals. I did not runtime-test its newer HAR paths. Posting here instead of opening a duplicate generic redaction issue.

@Xipong commented on GitHub (Oct 29, 2026): A concrete HAR case for the proposed **opt-in** export/redaction profiles, independently exercised with rea-agents **6.7.0** on Linux/WSL: `inspect_web_network_capture {capture_path:<synthetic HAR>, format:"har"}` excluded Authorization/cookie values, but retained a synthetic query-token value `QUERY_CANARY`, an `X-Api-Key` value `KEY_CANARY`, and response-body text `BODY_CANARY`. Adding `sensitive_values:["QUERY_CANARY","KEY_CANARY","BODY_CANARY"]` removed these markers from the complete retained Evidence, including the parameters. No real credentials or network requests were involved. This is the existing declared/literal-redaction contract, **not a newly demonstrated credential leak**. It is a useful acceptance case for this feature: make the distinction between original local evidence and a deliberately shareable representation visible; offer configurable common app-credential surfaces or a clear warning when only transport exclusions are active, without silently rewriting the original evidence or promising universal secret detection. I inspected current main's CaptureRedaction source; it still distinguishes known transport credentials from explicitly declared literals. I did not runtime-test its newer HAR paths. Posting here instead of opening a duplicate generic redaction issue.

bsakaguchi referenced this issue

2026-10-31 01:10:28 +00:00

[PR #3819] [MERGED] fix(javascript): resolve child ownership at receiver reads #5921

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#3819

No description provided.

Rows
Columns