Context-scoped node visibility (beyond credential redaction)

[elan-chels]

The 0.9.2 credential redaction in card / query --include-content is a great primitive.

A natural extension: let a node or source be tagged as "restricted," with a query flag (or context setting) that excludes restricted nodes from a given query context, so visibility is enforced by the store rather than by each caller remembering to filter.

This is useful anywhere a single store serves callers with different access levels: some queries should see everything, others should only see a non-sensitive subset. Tag + a query-time flag would be enough to lean on the store for that boundary instead of re-implementing filtering in every consumer.

Redaction already handles the credential-value case; this is about excluding whole nodes/sources by policy rather than masking a value inside them.

[muthuishere]

Agreed this is worth building, and the tag + query-flag design is the right ergonomic answer. Before it gets built, one distinction that matters a lot for the use case behind it.

A query-time filter is a filter, not a boundary

The store is a directory of plain ndjson files. If a caller can run a query against it, that caller can also read graph/nodes.ndjson directly, or run the same query without the flag. So a tag + --restricted flag gives you:

• ✅ a caller that cooperates not accidentally surfacing staff-only nodes
• ❌ any guarantee against a caller that does not

For "don't accidentally show cost nodes in this dashboard widget", that is genuinely useful. For "clients must never see the rate card, or another client's project" — a confidentiality requirement where the adversary might be the person on the other end of the connection — leaning on it as the isolation mechanism would be a mistake, and I would rather say so now than after it ships and gets trusted.

Note this is different from the 0.9.2 credential redaction, which is not an access-control feature either: its job is narrower and absolute — a secret's value must never enter a model's context window, on any code path.

The design that is actually a boundary

Partition at build time instead of filtering at query time: the client-facing store simply never contains the restricted nodes. Then there is nothing to leak, and no flag to forget.

The machinery is already there — stores are keyed, one repo can have several, and producers are scoped. Something like a per-store node policy at gather time, so proof-client and proof-staff are two stores built from the same sources with different inclusion rules. A client-side breach then exposes a store that never held the rate card.

Suggested split

1. Node/source tagging + --exclude-tag / context flag — cheap, useful, ships first. Documented explicitly as hygiene, not authorization, so nobody builds a security story on it.
2. Build-time partitioned stores — the real answer for PROOF's multi-tenant case, and a larger design (needs its own ADR: where the policy lives, how it interacts with remote push, what happens on a re-gather).

If PROOF only ever serves restricted queries through a server you control, and clients never touch the store directly, then (1) may be sufficient on its own — the boundary is your server, and the store is just helping it not slip. Worth confirming which shape PROOF is, because it changes which of these is urgent.