Apply firewall redaction on the handle-expansion path

[dgenio]

Summary

Route HandleStore.expand() output through the same redaction the Firewall applies on
first invocation, so expanded rows cannot return inline PII/secrets that the initial
Frame would have stripped.

Why this matters

expand() enforces grant constraints (max_rows, allowed_fields, scope, principal
binding) but builds its Frame directly from the raw stored dataset and never calls
redact(). A field permitted by allowed_fields can still contain inline secrets
(e.g., a note field with a Bearer token) that the Firewall would normally scrub on
the summary/table path. Expansion is a fully supported workflow (README quickstart),
so this is a reachable leak, not a corner case.

Current evidence

• handles.py: expand() slices/filters/projects rows and returns a Frame(...) with no redaction call.
• Raw data is stored pre-firewall: kernel/_invoke.py calls kernel._handles.store(... data=raw_result.data ...) before Firewall.transform.
• firewall/redaction.py scrubs inline email/phone/card/SSN/Bearer/JWT/API-key/connection-string patterns — none of this runs in expand().
• docs/security.md "Handle expansion boundary" documents constraint rechecks but not redaction.

External context

Not required for this issue.

Proposed implementation

1. After field projection and pagination in expand(), pass the resulting rows through
   redact() using the handle's persisted allowed_fields and the firewall's
   max_depth.
2. Prefer giving HandleStore a reference to a Firewall/redaction callable rather
   than importing redaction directly, to keep one redaction implementation.
3. Carry redaction warnings into the expansion Frame.warnings.

AI-agent execution notes

• Inspect first: handles.py, firewall/redaction.py, firewall/transform.py, kernel/__init__.py (expand), tests/test_handles.py, tests/test_firewall_boundary.py.
• Preserve the existing constraint-recheck and principal-binding logic exactly.
• Decide injection point so HandleStore does not gain a hard dependency cycle with the firewall package.

Acceptance criteria

• An expanded Frame never contains an inline secret/PII string that the first-invocation Frame redacted.
• Redaction warnings appear in the expansion Frame.
• All existing handle constraint tests still pass.

Test plan

Extend tests/test_firewall_boundary.py to expand a handle whose allowed field holds a
fake secret and assert it is redacted. Run make ci.

Documentation plan

Add a redaction note to the "Handle expansion boundary" section of docs/security.md.

Migration and compatibility notes

Expanded values containing sensitive patterns will now be redacted. Document under
Security. No API change.

Risks and tradeoffs

Slight per-expand CPU cost; acceptable for a security boundary. Wiring a firewall
reference into HandleStore must avoid import cycles.

Suggested labels

security, reliability, testing

[dgenio]

Closing as fixed by merged PR #229 (merged 2026-06-17).

HandleStore.expand() now routes its projected rows through the same redact() the firewall applies on first invocation, so an inline secret in a grant-permitted field (e.g. a Bearer token in a note value) is scrubbed on the expand path, and expansion Frames carry redaction warnings. The kernel threads the firewall's configured Budgets.max_depth into the expand redaction (new Firewall.budgets property). Verified in the current tree at src/weaver_kernel/handles.py (the redaction block in expand(), from .firewall.redaction import redact) and src/weaver_kernel/kernel/__init__.py (max_depth=self._firewall.budgets.max_depth). Regression coverage: tests/test_firewall_canary.py::test_canary_never_leaks_through_handle_expand / ::test_canary_never_leaks_through_field_projected_expand.

---

Generated by Claude Code