Egress origin-closure stage: block cross-identity data deterministically

[George-RD]

Parent

Spec: provenance labels with typed identity — #220 (wayfinder #193, map #182).

What to build

The proving tracer bullet: make the deterministic egress gate consult the label's typed-identity origin so cross-identity data is blocked end-to-end. The pure disclosure core gains a second ordered stage AFTER the existing disclosure-coverage stage — an origin-vs-recipient closure. An outbound item whose ProvenanceOrigin is a Counterparty other than the bound recipient counterparty (and is not Owner/System/Public) is blocked unless authorized, consulting effectively_allows_provenance_label on the grant. Owner/system/public items pass. The check runs identically on worker-requested and kernel-origin/proactive (Unattended workhorse) dispatch paths. DisclosurePolicyKey/DisclosurePolicy shape is unchanged; the stage is inserted at the core-vs-preparation seam from #205; gate()'s dead EgressClassifier stays deleted (#183) and is not resurrected. No LLM judgment — typed-field/digest comparison only.

Promise: Immune system. Users: Bell, Auditor, Unattended workhorse.

Acceptance criteria

• The deterministic core runs an origin-vs-recipient stage after disclosure-coverage; DisclosurePolicyKey/DisclosurePolicy shape unchanged.
• An item originating from counterparty X is BLOCKED from egress to counterparty Y; owner/system/public origins pass.
• The stage consults effectively_allows_provenance_label on the grant for any widening.
• Worker-requested and kernel-origin/proactive dispatches hit the identical check (no second ungated path).
• gate() stays pure; the dead EgressClassifier is not resurrected.
• Table-driven core unit tests over origin × recipient × sensitivity × egress × policy × caveat, plus a production-entering disclosure_regression_tests case (X-to-Y blocked; kernel-origin path).

Blocked by

• Context assembly derives label origin from resolved typed identity #225 (Context assembly derives label origin).
• Add grant caveat ProvenanceLabelAllowlist and narrowing helper #226 (Grant caveat ProvenanceLabelAllowlist and helper).
• Prefactor: extend EgressClass and split the disclosure core from web-search preparation #205 (Prefactor: extend EgressClass and split the disclosure core from web-search preparation).

[coderabbitai]

Coding Plan

Summary

• Add an ordered second stage to the pure check_egress core that compares each item's typed-identity ProvenanceOrigin to the bound recipient counterparty, using typed-field/digest comparison only.
• Keep the core pure by passing in a pre-resolved recipient binding and a pre-resolved authorized-labels set derived from effectively_allows_provenance_label; do not change DisclosurePolicyKey/DisclosurePolicy.
• Wire the stage into enforce_disclosure_egress and share one kernel helper so both the worker-requested path (api/actions.rs) and the kernel-origin/proactive path (message_notify.rs) run the identical check.
• Keep gate() pure and do not resurrect the dead EgressClassifier; cover the behavior with table-driven core unit tests and production-entering regression tests.

Design Choices

Design Choice 1: Prerequisite tickets (`#225`, `#226`, `#205`) deliver the building blocks this stage consumes.

Options Considered:

1. Build the origin-closure stage against the prerequisite outputs, assuming #225/Add grant caveat ProvenanceLabelAllowlist and narrowing helper #226/Prefactor: extend EgressClass and split the disclosure core from web-search preparation #205 are merged first.
2. Build the prerequisites and the stage together in one plan.

Chosen Option: 1

Rationale: The ticket explicitly lists #225/#226/#205 as blockers, so this plan targets only the origin-closure stage and consumes the prerequisite types (ProvenanceOrigin on provenance labels, effectively_allows_provenance_label on the grant, the extended core seam). Implementers must confirm those types exist before starting; if any are missing, deliver the blocking ticket first.

Design Choice 2: How the pure core receives grant authorization for widening.

Options Considered:

1. Pass a pre-resolved set of authorized provenance labels into check_egress as a new argument. The kernel evaluates effectively_allows_provenance_label first.
2. Pass the TaskGrant into the pure core so it can call the helper directly.

Chosen Option: 1

Rationale: This keeps the core pure and deterministic (typed-field/digest comparison only, no grant walking inside the core), which matches the existing check_egress design and the ticket's "no LLM judgment" and purity constraints.

Design Choice 3: How the recipient identity enters the core.

Options Considered:

1. Add a typed recipient binding field to OutboundQuery.
2. Add a separate recipient argument to check_egress.

Chosen Option: 1

Rationale: OutboundQuery already carries the outbound context and provenance, so adding the resolved recipient binding there keeps the outbound context in one type. DisclosurePolicyKey/DisclosurePolicy shape is not touched.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Add the origin-vs-recipient closure stage to the pure disclosure core

This phase extends the pure, deterministic core so it evaluates typed-identity origin after coverage. The core must stay synchronous, free of I/O, and free of grant access. DisclosurePolicyKey and DisclosurePolicy must not change shape.

Task 1: Extend the outbound context with a typed recipient binding

Give the core access to the recipient identity so it can compare origins against it.

• Update crates/openspine-schemas/src/disclosure_policy.rs to add a typed recipient binding to OutboundQuery. Represent the recipient as a typed identity value that can express Owner, System, and a specific Counterparty(Ulid), mirroring the ProvenanceOrigin variants from #225.
• Ensure each provenance item exposes its ProvenanceOrigin (delivered by #225). Confirm the field is on the provenance label type (ClassifiedBriefcaseItem or its #225 successor).
• Keep the recipient binding fail-closed: an unresolved recipient must be treated as "not a match" so cross-identity data cannot pass by default.

Task 2: Add the ordered second stage to `check_egress`

Run the origin-vs-recipient closure after the existing coverage loop.

• Update check_egress in crates/openspine-schemas/src/disclosure_policy.rs so it first runs the existing coverage stage, and only after coverage passes runs the new origin-closure stage.
• Add a new argument to check_egress carrying the pre-resolved set of authorized provenance labels (from Assumption 2).
• For each provenance item, inspect its ProvenanceOrigin. If the origin is Owner, System, or Public, pass the item. If the origin is Counterparty(X) and X equals the recipient counterparty, pass the item. If the origin is Counterparty(X) and X is not the recipient counterparty, block the item, unless the item's provenance label is present in the authorized-labels set.
• Use typed-field and digest comparison only. Do not inspect query text and do not add any heuristic.

Task 3: Extend the decision outcome for cross-identity blocks

Give the kernel a distinct signal for an origin-closure block versus a coverage block.

• Update DisclosureGateDecision in crates/openspine-schemas/src/disclosure_policy.rs to add a distinct block outcome for cross-identity blocks (for example a new variant carrying the offending origin and the recipient). Do not change DisclosurePolicyKey/DisclosurePolicy.
• Keep the existing coverage Block { escalation } outcome unchanged so the two stages stay distinguishable.

🤖 Prompt for AI agents

Implement Phase 1: extend the pure disclosure core in
`crates/openspine-schemas/src/disclosure_policy.rs` with a second, ordered
origin-closure stage that runs after the existing coverage stage. The core must
stay synchronous, free of I/O, and free of grant access. Do not change the shape
of `DisclosurePolicyKey` or `DisclosurePolicy`.

- Add a typed recipient binding field to `OutboundQuery`. Model the recipient as
a typed identity value with variants for `Owner`, `System`, and
`Counterparty(Ulid)`, mirroring the `ProvenanceOrigin` variants from `#225`. Treat
an unresolved recipient as fail-closed ("not a match").
- Confirm each provenance item exposes its `ProvenanceOrigin` field (from `#225`),
on `ClassifiedBriefcaseItem` or its successor.
- Modify `check_egress` so it runs the existing coverage stage first, then, only
if coverage passes, runs the new origin-closure stage. Add a new function
argument carrying a pre-resolved set of authorized provenance labels.
- In the origin-closure stage, for each provenance item: pass items with origin
`Owner`, `System`, or `Public` unconditionally; pass items with origin
`Counterparty(X)` when `X` equals the recipient counterparty; block items with
origin `Counterparty(X)` when `X` does not equal the recipient counterparty,
unless the item's provenance label is in the authorized-labels set. Use only
typed-field and digest comparison, never query text inspection or heuristics.
- Add a new `DisclosureGateDecision` variant distinct from the existing coverage
`Block { escalation }` variant, to represent a cross-identity block. Carry the
offending origin and the recipient in this variant. Keep the existing coverage
block variant unchanged.

Phase 2: Integrate the stage into kernel enforcement and both dispatch paths

This phase wires the core stage into the kernel. It resolves the recipient and the authorized labels, then applies the identical check on the worker-requested path and the kernel-origin/proactive path. No second ungated path may remain.

Task 1: Resolve recipient and authorized labels in `enforce_disclosure_egress`

Feed the pure core the recipient binding and the grant-derived authorization.

• Update enforce_disclosure_egress in crates/openspine-kernel/src/disclosure.rs to resolve the bound recipient counterparty from the briefcase (Briefcase.task_shape.counterparty via grant.id), following the existing is_counterparty_erased precedent. Fail closed when the counterparty is Unresolved.
• Compute the authorized provenance labels by consulting effectively_allows_provenance_label (from #226) on the grant for each candidate label.
• Pass the recipient binding (on OutboundQuery) and the authorized-labels set into check_egress.
• Handle the new cross-identity block outcome: return a fail-closed disclosure error/denial and route the escalation, using the same generic worker-facing denial message policy already in place (no leak of origin/recipient internals).

Task 2: Apply the stage on the worker-requested dispatch path

Ensure the shared worker/shell path carries the recipient through to the core.

• Update mediate_and_dispatch_action_with_attribution_and_token in crates/openspine-kernel/src/api/actions.rs so the DisclosureRequest and OutboundQuery it builds include the resolved recipient binding. This path already calls enforce_disclosure_egress for catalog-declared egress actions, so the new stage applies once the recipient is passed through.
• Confirm the standing-rule timer re-dispatch (Unattended workhorse) keeps funneling through this path, so it inherits the check without extra wiring.

Task 3: Apply the identical stage on the kernel-origin/proactive dispatch path

Close the currently ungated owner.notify path.

• Update notify_owner_with_digest in crates/openspine-kernel/src/pipeline/message_notify.rs so the kernel-origin/proactive dispatch invokes the same origin-closure evaluation before it sends. Reuse a shared kernel helper in crates/openspine-kernel/src/disclosure.rs so both paths call one implementation and no second ungated path exists.
• Resolve the recipient for this path as the owner identity, and evaluate provenance items through the same stage. Counterparty-origin items reach the owner recipient only when authorized, matching the core rule.
• Do not add any dependency on EgressClassifier and do not route the new stage through gate(). Keep gate() pure and leave the dead EgressClassifier untouched (#183).

🤖 Prompt for AI agents

Implement Phase 2: wire the Phase 1 core stage into kernel enforcement and into
both dispatch paths, using one shared helper so no ungated path remains.

- In `enforce_disclosure_egress` (`crates/openspine-kernel/src/disclosure.rs`),
resolve the bound recipient counterparty from the briefcase
(`Briefcase.task_shape.counterparty`) via `grant.id`, following the existing
`is_counterparty_erased` precedent. Treat an unresolved (`Unresolved`)
counterparty as fail-closed.
- Compute the authorized provenance labels by consulting
`effectively_allows_provenance_label` on the grant for each candidate label
(from `#226`).
- Pass the recipient binding (via `OutboundQuery`) and the authorized-labels set
into `check_egress`.
- Handle the new cross-identity block decision variant: return a fail-closed
disclosure denial and route the escalation, reusing the existing generic
worker-facing denial message policy. Do not leak origin or recipient internals
in the denial.
- Expose this resolution and enforcement logic as one shared kernel helper.
- In `mediate_and_dispatch_action_with_attribution_and_token`
(`crates/openspine-kernel/src/api/actions.rs`), update the `DisclosureRequest`
and `OutboundQuery` construction to include the resolved recipient binding, so
the existing call to `enforce_disclosure_egress` for catalog-declared egress
actions picks up the new stage. Confirm the standing-rule timer re-dispatch
(Unattended workhorse) continues to funnel through this path and inherits the
check.
- In `notify_owner_with_digest`
(`crates/openspine-kernel/src/pipeline/message_notify.rs`), call the shared
kernel helper before sending, resolving the recipient as the owner identity, so
counterparty-origin items reach the owner only when authorized. Do not route
this through `gate()` and do not add a dependency on `EgressClassifier`. Keep
`gate()` pure and leave `EgressClassifier` untouched.

Phase 3: Tests

This phase adds deterministic unit tests over the full matrix and a production-entering regression test that proves cross-identity blocking end-to-end on both dispatch paths.

Task 1: Table-driven core unit tests

Cover the origin-closure stage at the schema level.

• Extend the #[cfg(test)] mod tests block in crates/openspine-schemas/src/disclosure_policy.rs, following the existing small-fixture-builder convention.
• Add tests over origin × recipient × sensitivity × egress × policy × caveat. Include: counterparty X origin to counterparty Y recipient blocked; counterparty X origin to counterparty X recipient allowed; owner/system/public origin allowed regardless of recipient; blocked-then-allowed when the authorized-labels set includes the label (widening via #226); origin-closure runs only after coverage passes.

Task 2: Production-entering regression tests

Prove the wired kernel behavior on both paths.

• Add cases to crates/openspine-kernel/src/disclosure/disclosure_regression_tests.rs, using the test_state()/test_state_with_telegram(...) AppState fixture and mint_grant_with_selection_token as the existing tests do.
• Add a worker-requested case: an item originating from counterparty X is blocked from egress to counterparty Y, with the generic denial and no internals leak.
• Add a kernel-origin case: exercise the message_notify.rs proactive path and assert the identical origin-closure check runs (no second ungated path).
• Document each case with a Blocker/Anchor-style doc comment tying it to this regression, consistent with the file's convention.

🤖 Prompt for AI agents

Implement Phase 3: add deterministic unit tests and production-entering
regression tests to prove the origin-closure stage works at the schema level and
end-to-end on both dispatch paths.

- Extend the `#[cfg(test)] mod tests` block in
`crates/openspine-schemas/src/disclosure_policy.rs`, following the existing
small-fixture-builder convention. Add table-driven tests over origin × recipient
× sensitivity × egress × policy × caveat, including: counterparty X origin to
counterparty Y recipient is blocked; counterparty X origin to counterparty X
recipient is allowed; owner/system/public origin is allowed regardless of
recipient; a blocked case becomes allowed when the authorized-labels set
includes the label (widening via `#226`); the origin-closure stage runs only after
the coverage stage passes.
- Add cases to
`crates/openspine-kernel/src/disclosure/disclosure_regression_tests.rs`, using
the existing `test_state()` / `test_state_with_telegram(...)` `AppState`
fixtures and `mint_grant_with_selection_token`, consistent with existing tests.
- Add a worker-requested regression case where an item originating from
counterparty X is blocked from egress to counterparty Y, asserting the generic
denial message with no leak of origin/recipient internals.
- Add a kernel-origin regression case that exercises the `message_notify.rs`
proactive path and asserts the identical origin-closure check runs, proving no
second ungated path exists.
- Document each new test case with a `Blocker`/`Anchor`-style doc comment tying
it to this regression, following the file's existing convention.

Research

The disclosure logic has two layers. The pure core is check_egress in crates/openspine-schemas/src/disclosure_policy.rs. It is synchronous, has no I/O, and evaluates DisclosureProvenance classes against DisclosurePolicy coverage, returning a DisclosureGateDecision (Allow/Block). The kernel orchestration layer is enforce_disclosure_egress in crates/openspine-kernel/src/disclosure.rs. It loads policies, reserves budgets, calls the pure core, and routes escalations.

Two dispatch paths reach egress. The worker-requested/shell path is mediate_and_dispatch_action_with_attribution_and_token in crates/openspine-kernel/src/api/actions.rs. It calls enforce_disclosure_egress only for actions whose catalog entry declares an egress_class. The kernel-origin/proactive path is notify_owner_with_digest in crates/openspine-kernel/src/pipeline/message_notify.rs. It calls gate() directly and performs no disclosure enforcement today. The standing-rule timer (Unattended workhorse re-dispatch) funnels back through the worker path.

The bound recipient counterparty is not a field on TaskGrant. It is resolved from the briefcase (Briefcase.task_shape.counterparty: CounterpartyRef::Bound { identity_id, relationship }) via grant.id. This mirrors the existing is_counterparty_erased precedent in api/actions.rs and api/scoped_admission.rs.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: extend the pure disclosure core in
`crates/openspine-schemas/src/disclosure_policy.rs` with a second, ordered
origin-closure stage that runs after the existing coverage stage. The core must
stay synchronous, free of I/O, and free of grant access. Do not change the shape
of `DisclosurePolicyKey` or `DisclosurePolicy`.

- Add a typed recipient binding field to `OutboundQuery`. Model the recipient as
a typed identity value with variants for `Owner`, `System`, and
`Counterparty(Ulid)`, mirroring the `ProvenanceOrigin` variants from `#225`. Treat
an unresolved recipient as fail-closed ("not a match").
- Confirm each provenance item exposes its `ProvenanceOrigin` field (from `#225`),
on `ClassifiedBriefcaseItem` or its successor.
- Modify `check_egress` so it runs the existing coverage stage first, then, only
if coverage passes, runs the new origin-closure stage. Add a new function
argument carrying a pre-resolved set of authorized provenance labels.
- In the origin-closure stage, for each provenance item: pass items with origin
`Owner`, `System`, or `Public` unconditionally; pass items with origin
`Counterparty(X)` when `X` equals the recipient counterparty; block items with
origin `Counterparty(X)` when `X` does not equal the recipient counterparty,
unless the item's provenance label is in the authorized-labels set. Use only
typed-field and digest comparison, never query text inspection or heuristics.
- Add a new `DisclosureGateDecision` variant distinct from the existing coverage
`Block { escalation }` variant, to represent a cross-identity block. Carry the
offending origin and the recipient in this variant. Keep the existing coverage
block variant unchanged.
===============================================================================

Task: 2

Implement Phase 2: wire the Phase 1 core stage into kernel enforcement and into
both dispatch paths, using one shared helper so no ungated path remains.

- In `enforce_disclosure_egress` (`crates/openspine-kernel/src/disclosure.rs`),
resolve the bound recipient counterparty from the briefcase
(`Briefcase.task_shape.counterparty`) via `grant.id`, following the existing
`is_counterparty_erased` precedent. Treat an unresolved (`Unresolved`)
counterparty as fail-closed.
- Compute the authorized provenance labels by consulting
`effectively_allows_provenance_label` on the grant for each candidate label
(from `#226`).
- Pass the recipient binding (via `OutboundQuery`) and the authorized-labels set
into `check_egress`.
- Handle the new cross-identity block decision variant: return a fail-closed
disclosure denial and route the escalation, reusing the existing generic
worker-facing denial message policy. Do not leak origin or recipient internals
in the denial.
- Expose this resolution and enforcement logic as one shared kernel helper.
- In `mediate_and_dispatch_action_with_attribution_and_token`
(`crates/openspine-kernel/src/api/actions.rs`), update the `DisclosureRequest`
and `OutboundQuery` construction to include the resolved recipient binding, so
the existing call to `enforce_disclosure_egress` for catalog-declared egress
actions picks up the new stage. Confirm the standing-rule timer re-dispatch
(Unattended workhorse) continues to funnel through this path and inherits the
check.
- In `notify_owner_with_digest`
(`crates/openspine-kernel/src/pipeline/message_notify.rs`), call the shared
kernel helper before sending, resolving the recipient as the owner identity, so
counterparty-origin items reach the owner only when authorized. Do not route
this through `gate()` and do not add a dependency on `EgressClassifier`. Keep
`gate()` pure and leave `EgressClassifier` untouched.
===============================================================================

Task: 3

Implement Phase 3: add deterministic unit tests and production-entering
regression tests to prove the origin-closure stage works at the schema level and
end-to-end on both dispatch paths.

- Extend the `#[cfg(test)] mod tests` block in
`crates/openspine-schemas/src/disclosure_policy.rs`, following the existing
small-fixture-builder convention. Add table-driven tests over origin × recipient
× sensitivity × egress × policy × caveat, including: counterparty X origin to
counterparty Y recipient is blocked; counterparty X origin to counterparty X
recipient is allowed; owner/system/public origin is allowed regardless of
recipient; a blocked case becomes allowed when the authorized-labels set
includes the label (widening via `#226`); the origin-closure stage runs only after
the coverage stage passes.
- Add cases to
`crates/openspine-kernel/src/disclosure/disclosure_regression_tests.rs`, using
the existing `test_state()` / `test_state_with_telegram(...)` `AppState`
fixtures and `mint_grant_with_selection_token`, consistent with existing tests.
- Add a worker-requested regression case where an item originating from
counterparty X is blocked from egress to counterparty Y, asserting the generic
denial message with no leak of origin/recipient internals.
- Add a kernel-origin regression case that exercises the `message_notify.rs`
proactive path and asserts the identical origin-closure check runs, proving no
second ungated path exists.
- Document each new test case with a `Blocker`/`Anchor`-style doc comment tying
it to this regression, following the file's existing convention.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!