fix(swm): accept plaintext SWM on public-on-chain agent-gated context graphs

[branarakic]

The bug

On a public/curated Context Graph, a member's SWM share is permanently dropped by the receiver. The share reports success to the sender (status: swm-shared) while the content silently goes nowhere, so member shares → curator publishes — the headline curated-CG flow — cannot complete.

Receiver log:

SWM write rejected: Sender Key encrypted workspace payload required for
private or agent-gated context graph "…"
SWM substrate receiver dropping share from 12D3KooW… (permanent rejection)

Root cause: sender and receiver used different authorities

	condition	source
sender	accessPolicy === 0 → plaintext, agent gate never consulted	dkg-agent-crypto.ts resolveWorkspaceRecipientsGated
receiver	hasPrivateAccessPolicy || agentGateAddresses !== null → require encryption	workspace-handler.ts

They disagree on exactly one set: accessPolicy = 0 AND agent-gated — which is the public/curated cell (creating a curated CG stamps the curator into allowedAgents). Sender emits plaintext, receiver demands encryption, write dropped with retryable: false.

Why the receiver is the side that was wrong

The sender's plaintext choice is deliberate and correct. From swm-public-cg-plaintext.test.ts:

"On a public CG the allowedAgent list governs publish authority, not read access."

That test file was itself the fix for a production bug: a public CG carrying DKG_ALLOWED_AGENT took the encrypted path, bootstrapped a sender-key handshake that non-gated recipients rejected, and surfaced as HTTP 500 on promote. Encrypting a public CG protects nothing — the content is readable by policy — while reintroducing that failure.

The receiver, by contrast, derived its requirement from local allowedAgent/participantAgent triples — intent, not authority — which is precisely what the sender's own comment warns against relying on.

A sender-side fix was attempted first and reverted: it broke 2 of 38 tests in swm-public-cg-plaintext.test.ts, whose assertion store.query.calls == [] requires the public path not to touch the store at all.

The fix

The receiver now consults the same live on-chain predicate the sender uses, injected as publicAccessPolicyOnChainOracle alongside the existing chainAgentGateOracle and wired to isContextGraphPublicOnChain. An agent gate forces encryption unless the CG is proven public on-chain.

Fail-closed throughout: absent oracle, false, or a throw all mean "not proven public" and keep the encryption requirement. A stale mapping or RPC flake can never become a plaintext-acceptance hole.

Reviewer ask: this relaxes a security check. It is safe only because "public on-chain" means the content has no confidentiality requirement at all. Please confirm that reasoning holds.

Test coverage

New packages/publisher/test/swm-public-gated-plaintext-accept.test.ts — 5 cases: public+gated accepts, gated-not-public requires, probe-throws fails closed, no-oracle fails closed, ungated unaffected.

Mutation-tested: restoring the pre-fix behaviour makes the public+gated case fail. It invokes the real private probe off the prototype rather than reimplementing it.

CI gap closed

Both vitest.unit.config.ts files use explicit include lists, and neither the new test nor swm-public-cg-plaintext.test.ts was listed — the latter guards a previously-fixed production bug and was not running in CI at all. It only caught the wrong first fix because it was run by hand. Both added.

Publisher 422 → 424, agent 1132 → 1143 on a pure main base.

Verification

Devnet, 6 nodes: member share now reaches the curator (curator node received the member-shared asset — 2 quads, previously "not visible after 90228ms"). Curated authorization still holds — non-curator SWM gossip refused, non-curator VM publish refused (409).

Mixed-fleet note

Un-upgraded receivers keep rejecting plaintext on agent-gated public CGs until they take this build.

🤖 Generated with Claude Code

[lupuszr]

Requesting changes on the existing encrypted-wire compatibility blocker. I reproduced it through the real SharedMemoryHandler.handle() path on this head: with an agent gate, publicAccessPolicyOnChainOracle returning true, and a valid signed encrypted payload (the sender's legitimate fail-closed result during oracle or RPC skew), the handler returns applied=false and logs that encrypted workspace payload is only supported for private or agent-gated graphs. Public proof should allow plaintext; it must not forbid the safer encrypted format for the same gated CG. The added five tests still do not exercise handle(), so they all pass while this real regression fails.

[branarakic]

Both findings addressed in 6d251e6.

Public proof makes encrypted public-gated writes permanently fail (RED) — correct, and the first cut of this fix had inverted the failure rather than removed it. The two questions are now separate: requiresEncryptedPayload (MUST it be encrypted — private, or gated-and-not-proven-public; chain-derived) vs supportsEncryptedPayload (MAY it be encrypted — private, or gated at all; structural). An agent-gated CG always accepts Sender-Key payloads even when proven public, so a sender whose chain probe flaked and failed closed into encryption is admitted rather than permanently dropped. Applied to both encoding branches — the review flagged the senderKeyMessage arm; the identical flaw was in the encryptedPayload arm. An ungated public CG still refuses encrypted payloads exactly as before.

Regression test mirrors the fix instead of exercising the receiver (RED) — the decision is now an exported unit, resolveWorkspaceEncryptionRequirement, and the handler consumes it, so the test covers shipped logic: reverting the production decision breaks the suite. This also lands the centralization the YELLOW thread asked for — send-side and receive-side policy now have one named home — and removes the cast-heavy private-helper stubbing the other YELLOW flagged. The suite asserts the public/curated accept, the fail-closed unproven case, that a public proof never downgrades a PRIVATE CG, unchanged ungated behaviour, and the skew invariant (never REQUIRE without SUPPORT) across all eight input combinations.

🤖 Generated with Claude Code

[Jurij89]

Adversarial review — fix(swm): accept plaintext SWM on public-on-chain agent-gated context graphs

Multi-lens review against the PR head (a4640d03d), with an explicit adversarial pass on the security question you flagged. Headline: the relaxation is safe. The two findings are a performance regression on the SWM write hot path and a test that doesn't actually guard the line it's meant to.

---

✅ The security relaxation is sound (your reviewer ask, confirmed)

You asked reviewers to confirm that accepting plaintext on a public-on-chain gated CG opens no hole. It does not, and the reason is worth stating explicitly: the encryption decision is independent of the authority check. The if (agentGateAddresses !== null) branch still runs verifyAgentEnvelope against the gate (workspace-handler.ts:~1007) before the new gateRequiresEncryption computation, so a non-gated sender's plaintext is still rejected on envelope verification — relaxing encryption never relaxes who may write. Adversarial attempts to (a) bypass the gate via the trustedReplay / public-host-catchup branch and (b) mis-prove a private CG as public (numeric-id reuse / stale local mapping) both failed: resolveOnChainAccessPolicyState rebinds a locally-resolved id to the on-chain name-hash before trusting it, and the whole chain fails closed on unknown/throw. Encrypting a public CG protects nothing, so accepting plaintext removes no confidentiality. 👍

---

🟡 MEDIUM — the on-chain oracle now runs on every agent-gated SWM write, including private/encrypted ones where its result is discarded

gateRequiresEncryption short-circuits on &&, so the oracle is invoked whenever agentGateAddresses !== null:

const gateRequiresEncryption = agentGateAddresses !== null
  && !(await this.isContextGraphProvenPublicOnChain(contextGraphId, ctx));
const requiresEncryptedPayload = hasPrivateAccessPolicy || gateRequiresEncryption;
if (requiresEncryptedPayload && !decoded.encryptedPayload && !decoded.senderKeyMessage) { … }

Two things compound here:

1. isContextGraphProvenPublicOnChain → resolveOnChainAccessPolicyState → readLiveOnChainAccessPolicy deliberately reads fresh from chain and bypasses onChainAccessPolicyCache for this security decision (its own comment: "Always read the access policy FRESH from chain here"). That's 2–3 eth_calls per invocation (isContextGraphActiveOnChain + getContextGraphAccessPolicy, plus the identity-binding read), each bounded by CHAIN_POLICY_READ_TIMEOUT_MS.
2. The result only matters when the payload is not encrypted (it only feeds the requiresEncryptedPayload && !decoded.encryptedPayload && !decoded.senderKeyMessage gate). On a private/gated CG every SWM write is encrypted, so the oracle runs and its answer is thrown away every time.

Net effect: every private-CG SWM write now issues 2–3 fresh chain reads it never needed, and its latency is coupled to RPC health — an RPC flake adds up to the read timeout to an SWM write that was always going to be accepted. Host-catchup replay of N aged envelopes multiplies this by N.

Fix (trivial): consult the oracle only when the payload is actually plaintext:

const payloadIsEncrypted = Boolean(decoded.encryptedPayload || decoded.senderKeyMessage);
const requiresEncryptedPayload = !payloadIsEncrypted && (
  hasPrivateAccessPolicy
  || (agentGateAddresses !== null && !(await this.isContextGraphProvenPublicOnChain(contextGraphId, ctx)))
);
if (requiresEncryptedPayload) { … }

This preserves the exact accept/reject semantics while removing the chain read from the common encrypted-write path entirely.

---

🟢 LOW — the regression test does not exercise the call site it's meant to guard

swm-public-gated-plaintext-accept.test.ts invokes the real isContextGraphProvenPublicOnChain off the prototype (good), but decide() reimplements the surrounding decision (agentGated && !provenPublic) and drops the hasPrivateAccessPolicy || disjunct — it never calls the workspace-handler.ts decision path. So the mutation that actually matters — reverting the call site to hasPrivateAccessPolicy || agentGateAddresses !== null — leaves all 5 tests green. The "mutation-tested: restoring the pre-fix behaviour makes the public+gated case fail" claim holds only for mutating the probe, not for reverting the line the PR changes. The regression guard has a blind spot exactly at that line.

Suggested: drive the assertion through the handler's real decision (even a thin seam that calls the actual requiresEncryptedPayload computation), so a revert of the call-site expression fails a test.

---

Method: independent lenses (perf / security-authority / test-quality) plus two adversarial verifiers per candidate re-reading the head code; the security "safe" conclusion is the result of skeptics failing to construct an exploit, and the perf finding was re-verified by hand against readLiveOnChainAccessPolicy.

[branarakic]

New commit 9894759 pushed for review: evaluate the on-chain public probe lazily, only for agent-gated CGs. The earlier integration awaited isContextGraphProvenPublicOnChain unconditionally in handle(), putting a live chain RPC on the hot path of every SWM gossip receive — measured ~3ms → ~33ms per receive on a 6-node devnet, which made LIVE receivers miss VM/markdown convergence windows (caught by the devnet gate, not by unit tests). The probe is now only evaluated when the CG is agent-gated; ungated public receives never touch the chain. Handler-boundary tests with a counting oracle: ungated → probe never invoked (mutation-checked by re-introducing the unconditional await), gated → probe invoked. Same fix is staged for testnet-canary as #1852.

[otReviewAgent]

🟡 Issue: The “canonical” encryption policy is still receiver-only

What's wrong
The PR says it keeps both sides of the wire on one authority, but structurally the policy is still duplicated: the receiver calls this new helper while the sender keeps its own inline branch. That leaves the invariant protected by comments and tests rather than by one shared abstraction.

Example
If a future access-policy state changes when plaintext is allowed, a maintainer has to update both resolveWorkspaceRecipientsGated and resolveWorkspaceEncryptionRequirement; updating only the new helper would reintroduce sender/receiver drift.

Suggested direction
Make this module own the common policy decision used by both sender and receiver, or stop presenting it as canonical and keep it explicitly receiver-local.

For Agents
Unify the shared must-encrypt/may-encrypt decision between workspace-encryption-policy.ts, DKGAgent.resolveWorkspaceRecipientsGated, and the handler receive path. Preserve public-on-chain agent-gated plaintext on both send and receive, with recipient-key lookup layered separately on the sender side.

[otReviewAgent]

🟡 Issue: The policy helper leaks the nullable allowlist representation

What's wrong
The helper’s contract suggests address contents matter, but the implementation only cares about nullness. That bakes a handler sentinel into a supposedly canonical policy API and forces every caller to remember that [] is materially different from null.

Example
agentGateAddresses: [] and agentGateAddresses: ['0x...'] both mean “agent-gated/supports encryption”, while null means “ungated”. A future caller that normalizes an empty gate to null changes policy without touching the policy code.

Suggested direction
Pass explicit facts such as hasAgentGate or a discriminated agentGate model instead of the raw address array, and consider a small handler-level resolver that owns the lazy public probe before calling the pure policy function.

For Agents
Refactor WorkspaceEncryptionPolicyInput and the call in workspace-handler.ts around the policy resolution. Preserve the fully-revoked gate distinction from getContextGraphAgentGateAddresses by mapping it explicitly to hasAgentGate: true.

[otReviewAgent]

💡 Suggestion: Keep the wiring test off publisher test internals

Why it matters
This makes the agent package’s test depend on another package’s private test layout and on DKGAgent internals, so routine refactors can break the test even when the production wiring behavior is unchanged.

Suggestion
Promote the rootless request encoder to a shared test utility or build the payload through exported protocol APIs, and prefer a typed test harness or mock chain adapter over casting the agent to private shapes.

[branarakic]

Both remaining review items addressed in 0d08cb2ae:

Extract the SWM encryption policy (:297) — resolveWorkspaceEncryptionRequirement and the canonical must-vs-may rationale now live in packages/publisher/src/workspace-encryption-policy.ts; workspace-handler.ts keeps only the local lazy-probe sequencing note, and the policy tests import the focused module. The duplicated policy narrative at the call site is collapsed into a pointer to the module.

No test verifies the agent-to-handler oracle wiring (:926) — new packages/agent/test/swm-plaintext-oracle-wiring.test.ts (in the explicit vitest include list) builds the handler through the REAL getOrCreateSharedMemoryHandler, installs a counting isContextGraphPublicOnChain on the agent, and delivers a signed plaintext write on an agent-gated CG: it must apply and the probe must be consulted. Mutation-verified: deleting the publicAccessPolicyOnChainOracle option from dkg-agent-swm-substrate.ts fails the test with the exact production drop ('Sender Key encrypted workspace payload required...'). Full agent unit suite green (1144 tests).

Same module move cherry-picked cleanly onto the #1852 canary branch (09f876581).

[branarakic]

Superseded: this work shipped to main in the v10.0.9 promote (#1888) and is published as @origintrail-official/dkg@10.0.9. The commits reached main via testnet-canary rather than through this PR, so GitHub could not auto-close it. Closing to keep the review queue accurate — no content is lost.