Skip to content

fix(mcp): seal source-isolation leak on read path (P0)#861

Closed
toilalesondev wants to merge 4 commits into
garrytan:masterfrom
toilalesondev:fix/mcp-source-isolation-v2
Closed

fix(mcp): seal source-isolation leak on read path (P0)#861
toilalesondev wants to merge 4 commits into
garrytan:masterfrom
toilalesondev:fix/mcp-source-isolation-v2

Conversation

@toilalesondev

@toilalesondev toilalesondev commented May 11, 2026

Copy link
Copy Markdown

Builds on the baseline commit. Adds the actual enforcement and the auth wire-up that populates AuthInfo.sourceId, so OAuth-authenticated MCP clients can no longer read pages belonging to other sources.

Engine layer (the WHERE clauses the previous commit left missing):

  • core/postgres-engine.ts: searchKeyword / searchKeywordChunks / searchVector now apply AND pages.source_id = $N when ctx.sourceId is set
  • core/search/hybrid.ts: thread opts.sourceId into the searchOpts literal before calling engine.searchKeyword/searchVector. Previously this function rebuilt searchOpts without the field, silently dropping the filter even after the engine learned to honor it. This was the Tier 3 leak (query op) that survived the engine-level fix.

Auth layer (populates the field):

  • core/migrate.ts: migration v47 adds oauth_clients.source_id (FK to sources, ON DELETE SET NULL)
  • core/schema-embedded.ts + core/pglite-schema.ts: same column in the fresh-install schema
  • core/oauth-provider.ts: verifyAccessToken JOINs oauth_clients and propagates source_id into AuthInfo.sourceId
  • mcp/http-transport.ts: legacy bearer-token validateToken path also extracts source_id and federated_read claims
  • commands/serve-http.ts: tokenSourceId reads the formal AuthInfo.sourceId field instead of the previous always-'default' cast

Semantics:

  • oauth_clients.source_id SET → strict isolation, engine WHERE-filters
  • oauth_clients.source_id NULL → federated/super-reader, no filter (matches stdio CLI behavior — unscoped = full reach)

Pre-fix, every OAuth client silently collapsed onto source 'default' because the field was planned but never wired, and the engine ignored the param even when callers passed it. This commit closes both halves.

Verified end-to-end against live shared Postgres with three test clients (scoped-empty / scoped-populated / NULL-federated) across all four read surfaces: list_pages, search, query (hybrid), get_page cross-source.


View in Codesmith
Need help on this PR? Tag @codesmith with what you need.

  • Let Codesmith autofix CI failures and bot reviews

Builds on the baseline commit. Adds the actual enforcement and the auth
wire-up that populates AuthInfo.sourceId, so OAuth-authenticated MCP
clients can no longer read pages belonging to other sources.

Engine layer (the WHERE clauses the previous commit left missing):
- core/postgres-engine.ts: searchKeyword / searchKeywordChunks / searchVector
  now apply `AND pages.source_id = $N` when ctx.sourceId is set
- core/search/hybrid.ts: thread opts.sourceId into the searchOpts literal
  before calling engine.searchKeyword/searchVector. Previously this
  function rebuilt searchOpts without the field, silently dropping the
  filter even after the engine learned to honor it. This was the Tier 3
  leak (`query` op) that survived the engine-level fix.

Auth layer (populates the field):
- core/migrate.ts: migration v47 adds oauth_clients.source_id (FK to sources,
  ON DELETE SET NULL)
- core/schema-embedded.ts + core/pglite-schema.ts: same column in the
  fresh-install schema
- core/oauth-provider.ts: verifyAccessToken JOINs oauth_clients and
  propagates source_id into AuthInfo.sourceId
- mcp/http-transport.ts: legacy bearer-token validateToken path also
  extracts source_id and federated_read claims
- commands/serve-http.ts: tokenSourceId reads the formal AuthInfo.sourceId
  field instead of the previous always-'default' cast

Semantics:
- oauth_clients.source_id SET  → strict isolation, engine WHERE-filters
- oauth_clients.source_id NULL → federated/super-reader, no filter
  (matches stdio CLI behavior — unscoped = full reach)

Pre-fix, every OAuth client silently collapsed onto source 'default'
because the field was planned but never wired, and the engine ignored
the param even when callers passed it. This commit closes both halves.

Verified end-to-end against live shared Postgres with three test clients
(scoped-empty / scoped-populated / NULL-federated) across all four read
surfaces: list_pages, search, query (hybrid), get_page cross-source.
The dispatch chain (verifyAccessToken → ctx.sourceId → opts.sourceId)
was wired correctly but both engine implementations (postgres-engine and
pglite-engine) silently dropped the filter, returning unscoped pages.
Live stress test confirmed: HR-scoped token returned 50 rows from other
sources, including a 'shared/' handoff page it should never see.

This patch:
- adds sourceId to PageFilters type (src/core/types.ts)
- threads WHERE p.source_id = $sourceId into postgres-engine.listPages
- threads the same into pglite-engine.listPages

Re-validated end-to-end against live MCP HTTP server with three OAuth
tokens (scoped, scoped, federated): scoped tokens now return only their
own source; NULL/federated tokens still see cross-source results, as
intended by the v0.31.4 architecture.

Reported-and-verified-by: Augustus (WeCare)
The image-similarity branch passed sourceId to engine.searchVector but
the main hybridSearch call path silently dropped it. hybridSearch
already accepted+threaded the param internally; the op handler just
never set it.
The traverse_graph operation leaked page slug + title + type metadata
across source boundaries even when get_page correctly sealed the page.
A scoped HR token could discover an Augustus or robin page exists by
seeding the graph traversal — it'd return depth=0 with the title visible.

Same engine-side gap as list_pages and query (fixed earlier in this PR):
the handler threaded ctx.sourceId but the engine SQL ignored it.

Fix scopes every page-touching JOIN/FROM in the recursive CTE for both
graph methods on both engines:

- traverseGraph: seed + recursive step + inner jsonb_agg edge subquery
- traversePaths: seed + recursive step + outer projection, for all
  three direction branches (in, out, both)

Same canonical pattern as resolveSlugs: `AND (${!scoped} OR
<alias>.source_id = ${sourceId})`. NULL/undefined sourceId =
federated/super-reader (matches the rest of this PR's contract).

Also threads ctx.sourceId in the resolve_slugs handler — was already
the engine-side accepting the param but the handler wasn't passing it.

Files: engine.ts (interface), postgres-engine.ts, pglite-engine.ts,
operations.ts (handler).

Verified live against Supabase: HR token traversing a robin-source
handoff page now returns 0 nodes; LOG token traversing an Augustus
page returns its own neighborhood; SYS token (federated, source_id
NULL) sees everything. No false-negatives on get_page / list_pages /
query / resolve_slugs regression checks.
garrytan added a commit that referenced this pull request May 15, 2026
…ederated_read + 3 more (#996)

* fix(mcp): skip stdin EOF handlers when MCP_STDIO=1

OpenClaw's bundle-mcp gateway and similar wrappers pipe the JSON-RPC
handshake on stdin then close their stdin half. Pre-fix, both stdin
'end' and 'close' listeners (server.ts:65-66 and serve.ts:204-206)
treated this as a permanent disconnect and shut the server down before
the first tool call arrived.

Guard both sites with `process.env.MCP_STDIO !== '1'`. Signal handlers
(SIGTERM/SIGINT/SIGHUP), transport.onclose, and the parent-process
watchdog still cover legitimate shutdown paths. The serve.ts site
threads the env read through an injectable `mcpStdio?: boolean` on
ServeOptions so tests stay isolated (no process.env mutation per
scripts/check-test-isolation.sh R1).

Tests: 3 new cases in test/serve-stdio-lifecycle.test.ts pin the
guard's invariants — mcpStdio=true must NOT trigger shutdown on stdin
EOF, signals must still drive shutdown with mcpStdio=true, and
mcpStdio=false (default) preserves existing CLI behavior. 25/25 pass.

Origin: PR #870.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(oauth): honor token_endpoint_auth_method=none for PKCE public clients

RFC 7591 §3.2.1: when a DCR client declares
token_endpoint_auth_method="none" (PKCE-only public clients like Claude
Code, Cursor), the authorization server MUST NOT issue a client_secret.
Pre-fix, registerClient unconditionally minted a secret, and the MCP
SDK's clientAuth middleware then rejected valid public-client flows on
/token because it expected client.client_secret to match.

Three changes to src/core/oauth-provider.ts:registerClient:

  - Gate clientSecret generation on isPublicClient = (auth_method === 'none').
    Public clients store client_secret_hash = NULL.
  - Omit client_secret from the response payload for public clients.
    Confidential clients (default client_secret_post and explicit
    client_secret_basic) keep their existing one-time-reveal shape.
  - Normalize NULL secret_hash to JS undefined in getClient so SDK
    middleware (which checks client.client_secret === undefined, not
    === null) correctly identifies public clients and skips the
    secret-comparison branch on /token.

Schema is already permissive (client_secret_hash TEXT, no NOT NULL on
both src/schema.sql and src/core/pglite-schema.ts) — no migration
needed.

Tests: 5 new cases in test/oauth.test.ts pin:
  - public client → no client_secret in response (#11 from plan)
  - default auth_method → secret unchanged (regression guard)
  - explicit client_secret_post → secret unchanged
  - getClient NULL→undefined normalization
  - PKCE full /authorize → /token end-to-end with no secret (#15 from plan)

69/69 oauth.test.ts cases pass. typecheck clean.

Origin: PR #909.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* feat(serve-http): --bind HOST, default to loopback (127.0.0.1)

Adds `gbrain serve --http --bind <interface>` to control which network
interface the HTTP MCP server listens on. Default flipped from
`0.0.0.0` (pre-v0.34) to `127.0.0.1` (v0.34.0+).

Why the flip: gbrain's primary use case is a personal-knowledge brain on
a laptop. The previous default exposed brains on every interface — one
accidental `--http` invocation away from publishing the brain to a LAN.
Server operators who need remote access pass `--bind 0.0.0.0` (or a
specific interface). Codex's outside-voice on the original PR #864
correctly flagged that the additive flag wasn't actually the fix; the
default needed to change for the safety claim to hold.

If `--public-url` is set but `--bind` is unset, runServeHttp prints a
loud stderr WARN at startup recommending `--bind 0.0.0.0`. Declaring a
public URL while quietly binding loopback is almost always a
misconfiguration; we want the operator to see it on first start, not
silently fail remote requests.

Startup banner now includes a `Bind:` row so the listening interface is
visible alongside Port / Engine / Issuer.

Origin: PR #864, extended with D11 (default flip) per /plan-eng-review
codex outside-voice review.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(mcp): seal source-isolation leak on read path (P0)

Pre-fix, an authenticated OAuth MCP client scoped to source-A could
enumerate source-B pages via six read-side ops: search, query (text
AND image paths), list_pages, traverse_graph, and find_experts. The
v0.31.8 source-scoping pattern shipped through dispatch.ts but the op
handlers never threaded ctx.sourceId into their engine calls, and
hybridSearch.ts:223's explicit SearchOpts rebuild dropped sourceId
even when callers passed it.

Sealing the leak:

  - src/core/operations.ts adds sourceScopeOpts(ctx), the canonical
    precedence ladder: ctx.auth.allowedSources (federated) wins over
    ctx.sourceId (scalar) wins over nothing. Threaded into all 5
    read-side op handlers + the query-image-path searchVector call
    (the 6th leak surface codex caught in plan review).

  - src/core/search/hybrid.ts:223 now threads sourceId + sourceIds
    fields through the inner SearchOpts rebuild. The explicit pick
    shape is preserved (HNSW inner-CTE ordering depends on it) but
    extended.

  - src/core/types.ts adds sourceIds?: string[] to SearchOpts +
    PageFilters (D9: federated read needs array-shaped engine filter
    or fan-out; array wins for hot retrieval).

  - src/core/operations.ts AuthInfo gains sourceId + allowedSources
    (D2: identity surface symmetric with the federated_read column
    #876 will add).

  - Both engines now apply WHERE source_id = $N (scalar) or = ANY($N::text[])
    (array) at the SQL layer for searchKeyword, searchKeywordChunks,
    searchVector, listPages, traverseGraph, traversePaths. Array form
    wins when both are set. The searchVector filter pushes into the
    inner HNSW CTE (codex flagged this placement during plan review).

  - traverseGraph + traversePaths signatures gain opts.sourceId +
    opts.sourceIds; engine.ts interface updated.

  - findExperts (the whoknows op, D3 5th leak surface) accepts
    sourceId + sourceIds and threads them into its internal
    hybridSearch call. PR #861 was authored before v0.33 shipped so
    this op wasn't covered in the original PR.

Auth wiring:

  - GBrainOAuthProvider.verifyAccessToken populates AuthInfo.sourceId
    from oauth_clients.source_id. JOIN guarded by isUndefinedColumnError
    so pre-v55 brains degrade to legacy projection rather than refusing
    every token verification.

  - GBrainOAuthProvider.registerClientManual gains a sourceId
    parameter (defaults to 'default'). DCR registerClient also sets
    source_id='default' on the inserted row.

  - serve-http.ts:929 cleanup: AuthInfo.sourceId is now a real typed
    field. The cast + GBRAIN_SOURCE env fallback chain is gone (D13).
    Legacy bearer tokens default to 'default' source in
    verifyAccessToken.

  - http-transport.ts (legacy access_tokens path) threads
    sourceId='default' through DispatchOpts so v0.22.7 callers stay
    source-scoped.

  - auth.ts CLI adds --source flag to gbrain auth register-client.

Migration v55 (D10 + D13):

  - ALTER TABLE oauth_clients ADD COLUMN source_id TEXT (nullable).
  - Backfill UPDATE source_id = 'default' WHERE source_id IS NULL —
    preserves v0.33 effective behavior verbatim for legacy clients.
  - ADD CONSTRAINT FK ... REFERENCES sources(id) ON DELETE SET NULL,
    wrapped in DO block so re-runs against fresh-install brains (where
    the FK already lives inline in SCHEMA_SQL) no-op cleanly.
  - CREATE INDEX idx_oauth_clients_source_id WHERE source_id IS NOT NULL
    for the verifyAccessToken JOIN.
  - GBRAIN_ACCEPT_SILENT_WIDEN env-flag wired through the runner via
    SET LOCAL gbrain.accept_silent_widen — reserved for future migrations
    that hit the silent-widen footgun codex flagged. This migration
    doesn't need it (column is brand new; no pre-existing stale values
    possible by definition).
  - src/core/pglite-schema.ts + src/schema.sql include the column +
    FK + index inline for fresh installs.

Tests: new test/e2e/source-isolation-pglite.test.ts with 13 regression
cases — one per leak surface (search/list_pages/traverse/etc.) plus
explicit AuthInfo.sourceId and AuthInfo.allowedSources op-handler
threading checks. Full unit suite: 6034 pass / 0 fail. PGLite
initSchema time dropped from 2.4s to 850ms after consolidating v55's
DO blocks (multiple DO blocks were slow on PGLite; one DO block for
the FK install only is fine).

Origin: PR #861 + plan-eng-review decisions D2/D3/D4/D9/D10/D13 + F2.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* feat(gateway): multimodal embedding for openai-compatible providers

Pre-fix, embedMultimodal hardcoded a recipe.id === 'voyage' branch and
threw AIConfigError for every other recipe. Multimodal-capable providers
fronted by LiteLLM (or any openai-compatible proxy) were unreachable
even when the operator had wired up the model.

The fix:

  - src/core/ai/gateway.ts adds embedMultimodalOpenAICompat() that
    POSTs to the standard /embeddings endpoint with content arrays
    carrying image_url entries. Routing comes from the existing
    recipe.implementation switch — Voyage stays on its own
    /multimodalembeddings path; every other openai-compatible recipe
    flows through the new helper.

  - src/core/ai/recipes/litellm-proxy.ts declares
    supports_multimodal: true so embedMultimodal accepts the recipe.
    No multimodal_models allow-list: LiteLLM is a passthrough proxy
    and the user owns model-id selection; provider rejection (400 from
    upstream) is the right enforcement layer there. Voyage's static
    allow-list shape stays unchanged (its 12 models share
    supports_multimodal but only one is multimodal-capable).

  - D12 runtime dimension validation: the new helper checks the
    returned vector length against the recipe's declared default_dims
    (preferred) or the brain's embedding_dimensions config. Mismatch
    throws AIConfigError with model id + observed + expected so the
    operator can swap models or rebuild the column. Pre-fix, a
    wrong-dim response would surface as a cryptic pgvector
    "vector dimension mismatch" at INSERT time.

  - Auth resolution routes through the existing defaultResolveAuth
    helper so optional-auth recipes (LiteLLM proxy with no
    LITELLM_API_KEY) and required-auth recipes both share one code
    path. Optional-auth sends "Authorization: Bearer unauthenticated"
    which servers like Ollama / llama-server ignore but the SDK
    contract requires.

Tests: 11 new cases in test/openai-compat-multimodal.test.ts cover
happy-path, multi-input batching, unauthenticated proxy, D12 dim
mismatch + default-dim fallback, 401 / 400 / malformed-JSON / non-array
error paths, and an explicit Voyage-regression test pinning that the
new openai-compat route doesn't accidentally hijack the Voyage path.
All 41 multimodal-related tests pass (existing voyage suite + new).
typecheck clean.

Origin: PR #875 + plan-eng-review D12 (runtime dim validation).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* feat(oauth): federated_read read scope (#876)

Pre-fix, OAuth clients had a single source-scope axis (source_id, added
in v55). A client could either write+read one source OR be a super-reader
across all sources (via NULL source_id). There was no middle ground —
WeCare-style L3 dept clients that need to write to dept-x but read
dept-x + parent canon + shared canon had no expression.

#876 adds federated_read TEXT[] as an orthogonal read-scope axis. source_id
is the WRITE authority; federated_read is the READ authority. They default
to matching values (read scope == write scope, the pre-v0.34 default)
when a client is registered without an explicit federated read list.

Migrations v56-v60 (six new migrations on top of v55):

  - v56: ALTER TABLE ... ADD COLUMN federated_read TEXT[] NOT NULL DEFAULT '{}'.
  - v57 (F5): explicit CASE backfill so source_id IS NULL → '{}' (not an
    array containing NULL — codex caught this ambiguity during plan review).
  - v58: post-backfill validation. Fails loud if any row's source_id isn't
    in its federated_read array, pointing at a logic bug in v57 if fired.
  - v59: flip the source_id FK from ON DELETE SET NULL to ON DELETE
    RESTRICT now that federated_read provides the alternative scope-loss
    path. Pre-flip, deleting a source could silently widen any oauth_client
    to super-reader; post-flip, source delete is refused if any client
    references it (operator must revoke/re-scope first).
  - v60: GIN index on federated_read for array-containment queries.

Auth wiring:

  - GBrainOAuthProvider.verifyAccessToken JOINs c.federated_read and
    populates AuthInfo.allowedSources. Pre-v56 / pre-v55 brains degrade
    via the existing isUndefinedColumnError fallback chain.
  - registerClientManual gains a federatedRead?: string[] parameter
    (defaults to [sourceId]).
  - DCR registerClient sets source_id='default' + federated_read=['default']
    on the inserted row.
  - auth.ts CLI adds --federated-read SRC1,SRC2,... flag. The
    register-client output now prints "Federated reads:" so operators
    confirm the scope they set.

Engines consume the federated array through the SearchOpts.sourceIds /
PageFilters.sourceIds field that #861 added (no engine changes here — the
plumbing was D9). sourceScopeOpts in operations.ts already prefers the
auth.allowedSources array over scalar ctx.sourceId when set.

Test seam:
  - test/book-mirror.test.ts now spawns the CLI with GBRAIN_HOME pointed
    at a tempdir so the test isn't sensitive to the developer's local
    ~/.gbrain/config.json. Pre-fix the test could silently inherit a real
    Postgres connection and hang past the default 5s test timeout. Fresh
    GBRAIN_HOME → "No brain configured" → exit 1 in <1s.
  - test/e2e/source-isolation-pglite.test.ts gains one more regression
    case: AuthInfo.allowedSources = [] (explicit empty) MUST NOT widen
    scope to "all sources" — the silent-widen footgun precedence ladder.
  - test/openai-compat-multimodal.test.ts is part of the wave's commits
    via the migrate.ts changes that bump the schema chain. typecheck-only
    fix on a captured-auth type was already in #875's tree.

6045 unit tests pass / 0 fail. typecheck clean. PGLite initSchema runs
v55-v60 in ~786ms total (within the test-harness budget for tests using
the canonical beforeAll engine pattern).

Origin: PR #876 + plan-eng-review F5 (CASE backfill).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* v0.34.0.0: MCP fix wave (#870 #909 #864 #861 #875 #876)

VERSION + package.json + CHANGELOG bump for the six-PR MCP fix wave.
Schema chain extends from v54 → v60; oauth_clients gains source_id +
federated_read columns; auth'd MCP clients now stay inside their scope
across all read-side ops; PKCE-only DCR works; --bind defaults to
loopback; LiteLLM multimodal embedding ships.

Contributed by @Hansen1018 (#870), @ding-modding (#909), @DukeDawg
(#864), @toilalesondev (#861 + #876), @yoelgal (#875).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs: update project documentation for v0.34.0.0

Sync README, CLAUDE.md, SECURITY.md, docs/architecture/topologies.md,
and docs/mcp/DEPLOY.md to reflect the v0.34.0.0 MCP fix wave:

- README: document --bind HOST default (loopback), --source +
  --federated-read register-client flags, PKCE public-client gate
- SECURITY.md: note loopback-by-default for serve --http, update the
  trust-proxy contract to point at the new default
- CLAUDE.md: annotate operations.ts (sourceScopeOpts helper),
  oauth-provider.ts (verifyAccessToken JOIN + PKCE public clients),
  serve-http.ts (--bind flag), gateway.ts (openai-compat multimodal +
  dim validation), mcp/server.ts (MCP_STDIO guard), auth.ts (--source
  + --federated-read), migrate.ts (v58-v63 chain), engine.ts
  (sourceIds field). Add 4 new test-file entries for
  source-isolation-pglite, openai-compat-multimodal,
  serve-stdio-lifecycle, oauth.test.ts PKCE cases
- docs/architecture/topologies.md: source-scoped register-client
  example, --bind 0.0.0.0 for thin-client host setup
- docs/mcp/DEPLOY.md: --bind explanation in the ngrok section,
  source-scoped client recipe
- llms-full.txt: regenerated per the CLAUDE.md-edit chaser rule

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore: bump v0.34.0.0 → v0.34.1.0

Renumbering the MCP fix wave from v0.34.0.0 to v0.34.1.0 so the
release slot lands between master's v0.33.2.1 and the next minor.

Touches every release-artifact mention:
- VERSION: 0.34.0.0 → 0.34.1.0
- package.json: same
- CHANGELOG.md header + "To take advantage" block
- CLAUDE.md key-files annotations (8 entries that document this wave)
- llms-full.txt (regen from CLAUDE.md)
- README.md / SECURITY.md / docs/architecture/topologies.md / docs/mcp/DEPLOY.md
- Wave code-comment markers ("// v0.34.0 (#NNN):" → "// v0.34.1 (#NNN):")

Test files renamed alongside since they were committed with the wave.

Commit subjects on the original 6 PR commits + the v0.34.0.0 bump
commit (4f533c76b47db7) intentionally NOT rewritten — those are
history. `git log` finds the implementation by message subject, not by
version tag.

6275 unit tests pass, typecheck clean, migration chain v58-v63 unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@toilalesondev toilalesondev closed this by deleting the head repository May 27, 2026
donogeme added a commit to donogeme/gbrain that referenced this pull request May 27, 2026
…read scope

Bumps to 0.36.0.1.

v0.34.1.0 (garrytan#861) introduced the sourceScopeOpts(ctx) helper to give
OAuth clients federated read scope across multiple sources via the
auth.allowedSources array. Its docstrings and changelog claimed every
read-side op handler routed through the helper, naming get_page
explicitly. The handler change never landed for four ops -- they kept
the v0.31.8 scalar-only `ctx.sourceId ? { sourceId } : {}` pattern, so
federated MCP clients silently lost access to pages in their federated
sources via get_page / get_links / get_backlinks / get_chunks even
though list_pages / search / traverse_graph honored the federated array.

Symptom that surfaced this: resolve_slugs (unscoped) returned a page
slug that get_page (scalar-scoped) immediately rejected with
page_not_found, on a brain where the federated client demonstrably had
read scope to the page's source.

Fix in three layers:

- Op handlers (operations.ts): swap the four handlers to
  sourceScopeOpts(ctx). One-line diff per handler.
- Engine interface (engine.ts) + types (types.ts): extend
  getChunks/getLinks/getBacklinks opts and GetPageOpts with
  `sourceIds?: string[]`.
- Engine implementations (pglite-engine.ts, postgres-engine.ts):
  WHERE source_id = ANY(sourceIds::text[]) branch ahead of the
  existing scalar branch. Empty array falls through to scalar
  (precedence guard against an attacker-controlled `federated_read: []`
  being misread as "no filter, see everything").

7 new regression cases in test/e2e/source-isolation-pglite.test.ts
pin the fix at the op-handler layer for all four ops, including the
empty-array fallback guard. The existing tests in that file only
exercised the engine layer directly, which is why the original drift
wasn't caught.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
donogeme added a commit to donogeme/gbrain that referenced this pull request May 27, 2026
…read scope

Bumps to 0.36.0.1.

v0.34.1.0 (garrytan#861) introduced the sourceScopeOpts(ctx) helper to give
OAuth clients federated read scope across multiple sources via the
auth.allowedSources array. Its docstrings and changelog claimed every
read-side op handler routed through the helper, naming get_page
explicitly. The handler change never landed for four ops -- they kept
the v0.31.8 scalar-only `ctx.sourceId ? { sourceId } : {}` pattern, so
federated MCP clients silently lost access to pages in their federated
sources via get_page / get_links / get_backlinks / get_chunks even
though list_pages / search / traverse_graph honored the federated array.

Symptom that surfaced this: resolve_slugs (unscoped) returned a page
slug that get_page (scalar-scoped) immediately rejected with
page_not_found, on a brain where the federated client demonstrably had
read scope to the page's source.

Fix in three layers:

- Op handlers (operations.ts): swap the four handlers to
  sourceScopeOpts(ctx). One-line diff per handler.
- Engine interface (engine.ts) + types (types.ts): extend
  getChunks/getLinks/getBacklinks opts and GetPageOpts with
  `sourceIds?: string[]`.
- Engine implementations (pglite-engine.ts, postgres-engine.ts):
  WHERE source_id = ANY(sourceIds::text[]) branch ahead of the
  existing scalar branch. Empty array falls through to scalar
  (precedence guard against an attacker-controlled `federated_read: []`
  being misread as "no filter, see everything").

7 new regression cases in test/e2e/source-isolation-pglite.test.ts
pin the fix at the op-handler layer for all four ops, including the
empty-array fallback guard. The existing tests in that file only
exercised the engine layer directly, which is why the original drift
wasn't caught.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants