security(summary): prevent post_read GET from mutating global corporate catalog

[seonghobae]

Finding

Strix exact-head run 34746057545 on #1055 head 50c4935eef1029467595f7004818643598b737c9 completed SUCCESS and uploaded strix-reports artifact 10318318320 (digest sha256:45c82c7f1f044185a4795b4b4db37d2ce30346e44e516ce027f2bf53fe89581e). The report contains one Medium finding, CWE-862: the post_read-gated GET /api/posts/{post_id}/summary can persistently create/update the shared corporate_entity catalog when no stored summary exists.

This is independently reproducible on protected main@83eba56149eb802cd63642c507c324c9976ec78e: read_post_summary authorizes visibility through _load_visible_post, derives a missing summary, then calls persist_post_summary(...) with live _corporate_hierarchy_inference_client() and _relation_verification_client(). persist_post_summary can reach canonical get_or_create_corporate_entity, whose mutation is global catalog state rather than a read-only projection.

The same codebase already treats catalog-enriching LLM work as a write boundary on extract-keymen / customer-hint resolution (post_admin). The mismatch is therefore an authorization/integrity defect, not merely an LLM-cost concern.

Realistic RED

Add a real-service API regression using an authenticated account with post_read but no post_admin and a visible post with no persisted summary:

1. configure summary generation so the returned role contains an organization actor not already uniquely bound in the corporate catalog;
2. call GET /api/posts/{post_id}/summary as the post_read-only account;
3. assert the summary read may still succeed/persist its summary projection, but the global corporate_entity table and hierarchy remain unchanged and live hierarchy/relation-verification clients are not admitted for catalog mutation;
4. call the same path as a post_admin account and prove catalog enrichment remains available where the write permission is explicit;
5. repeat for stale-summary fallback/provider failure to prove no privilege-dependent cleanup regression.

Do not turn the GET itself into post_admin-only unless product authority explicitly changes the read contract. Do not hide the finding by disabling summary persistence or by introducing a tenant-local duplicate catalog.

Minimal causal repair

At the read-model/application boundary, separate summary read/persistence from optional global catalog enrichment. A post_read account may consume/derive a summary, but only an account with post_admin may provide live hierarchy-inference/relation-verification capabilities that can create or modify global catalog entries. Preserve existing exact-match consumption of already-known catalog identities where it is read-only.

Prefer an explicit capability/policy argument over implicit provider availability if that makes the invariant enforceable in domain tests. The canonical catalog implementation stays in corporate_entity_ingestion; no matching SQL/provider routing is copied into main.py.

Acceptance

• post_read-only summary GET cannot create/update/delete corporate_entity or its hierarchy;
• post_admin summary derivation may still perform the currently intended catalog enrichment;
• existing ABAC visibility and post_read ability to read/derive a summary are preserved;
• summary projection persistence remains deterministic/idempotent and does not gain broader authorization;
• executable tests cover both permission classes and prove global catalog row-count/content invariance for post_read;
• no provider/network call capable of catalog mutation is admitted from the low-privilege path;
• Strix finding is re-run on the repaired exact head and becomes absent/closed by code-path evidence;
• no provider/model override, local catalog clone, broad post_admin substitution for all summary reads, warning suppression, force push, destructive rebase, or gate weakening.

Coordinate with #1077: the permission fix and the catalog connection-lease repair are separate invariants. One controls who may mutate the shared catalog; the other controls how long DB resources are retained around provider I/O.

[seonghobae]

Artifact provenance correction: Strix's recommendations say the proposed post_admin capability gate was “already applied” and syntax-verified, but the same immutable artifact proves that is false. strix.log records apply_patch missing file: backend/app/main.py / /workspace/backend/app/main.py at 13:14:30Z. Exact #1055 head 50c4935... still contains the vulnerable live-client call, so #1078 remains an unfixed source finding. The central Strix remediation-evidence defect is now owned by ContextualWisdomLab/.github#2168; do not treat the scanner's remediation prose as a source receipt. The fix suggestion itself remains useful, but requires an ordinary LineageWeave RED→commit→GREEN lane.

[seonghobae]

Fresh protected-main review found the same authorization root cause extends one step beyond the Strix-reported corporate_entity path: post_summary_ingestion._replace_summary_projection unconditionally calls upsert_team(...) for R&R team actors, and upsert_team writes the shared cataloged_team registry. Therefore merely replacing hierarchy/verification clients with Null clients would still let a post_read GET mutate global identity state. The #1078 repair must gate all summary-driven shared-catalog enrichment: low-privilege reads may bind already-known corporate/person/team identities read-only, but may not create/update corporate_entity or cataloged_team; post_admin may retain the existing enrichment behavior. This is the same application-boundary authorization invariant, so keep it in #1078 rather than opening a competing security writer. #1077 remains only the connection-lease/performance invariant.

[seonghobae]

Source writer lease: fix/summary-catalog-authorization-1078 is now based exactly on protected main@83eba56149eb802cd63642c507c324c9976ec78e. A bounded, self-removing repair workflow is queued to apply the application-boundary capability gate, reader-only team lookup, focused regression tests, ADR 0375, architecture note, and changelog fragment. Do not open a competing #1078 product branch while this lease is active. No #1055 source mutation is involved; that PR remains Draft and will need ordinary descendant convergence only after this security owner integrates.

[seonghobae]

Fresh RCA on the bounded source writer: run 34764040947 did reproduce the protected-main RED and applied the intended patch in its ephemeral workspace, but failed in its own post-patch verification before cleanup/commit. The verification incorrectly asserted that hierarchy_inference_client=_corporate_hierarchy_inference_client() and verification_client=_relation_verification_client() must disappear from all of backend/app/main.py. That is broader than #1078: protected main has other legitimate post_admin-owned enrichment paths using those live clients. The #1078 invariant is only that GET /api/posts/{post_id}/summary cannot admit them for a post_read-only caller.

A same-writer harness repair has therefore been staged on fix/summary-catalog-authorization-1078: it narrows those assertions to the summary endpoint slice, preserves the RED and causal source patch, and self-removes after updating the original bounded workflow. The first harness commit had invalid workflow YAML and produced zero jobs; that harness syntax defect was corrected at 611f3886972a27ba4c6f2f064d33b37cfdf62479. Run 34766887792 is currently queued for a hosted runner; do not open a competing #1078 source branch while this lease is active.

No product GREEN is claimed yet. In particular, the planned focused helper tests are not a substitute for #1078's required authenticated real-service API/PostgreSQL regression proving post_read summary materialization leaves corporate_entity and cataloged_team unchanged while post_admin retains explicit enrichment.

[seonghobae]

Pre-merge security review of the staged patch found one acceptance hardening item: the planned persist_post_summary(..., allow_catalog_enrichment: bool = True) default is not an explicit capability boundary. The HTTP helper passes the permission-derived value explicitly, so it fixes the reported GET path, but a future/new direct caller that omits the keyword would silently inherit shared-catalog write authority. Before #1078 can be considered GREEN, make this capability fail closed—prefer a required keyword with no default, or otherwise a default that cannot grant enrichment—and update each trusted non-HTTP caller explicitly according to its intended authority. Existing backfill/tests must not acquire mutation authority merely by omission. This stays inside #1078 because it is the same authorization invariant, not a new writer.