~bigbes/sr-ht-dolt · parade

main · last commit 5 hours ago · ti41arbu

← Back to the parade

sr-ht-dolt-aff Document /mcp credential policy (bearer + meta PAT) against the family-wide MCP auth rule Lined Up

status: open P2 task
bd update sr-ht-dolt-aff --claim bd close sr-ht-dolt-aff
Created byEugene Blikh
Ownerbigbes@gmail.com
Created2026-08-17T20:39:46Z
Updated2026-08-17T20:39:46Z
Description
What is wrong: `/mcp` mounting differs across services with no shared written policy. `sourcehut-dolt/cmd/doltsrht/mcp.go` uses its own bearer validator and additionally accepts a meta PAT — a fourth distinct answer alongside bench (structurally bearer-only, no cookie/resolver access), coverage (sits under the shared resolver so cookies reach it, gates reads on `p.IsInstanceToken()` only), and curator (also sits under the shared resolver via `agents.Mount(s.Resolver.Middleware())`).

Why it matters: this is not by itself a hole in dolt — every tool still runs its own visibility check — but there is no single documented answer, family-wide, to "what does an MCP surface accept on this instance", and each service currently answers that question independently. dolt's own answer (bearer + meta PAT, no cookie) is plausible and is also the basis for the `Authorization`-only Vary header dolt uses (relevant to D02/D10), but it is undocumented as a deliberate policy rather than an accident of implementation.

Sibling comparison: none of the four current answers is wrong per se; the defect is the absence of a written rule any of them can be checked against. coverage's split (anonymous read allowed, but only via `IsInstanceToken()` gating) is explicitly documented as intentional in its own code, which is the standard the others — including dolt — should meet.

Fix: once the policy is written once, family-wide (in `sr-ht-ecore/mcphttp`'s package doc or the tokens SPEC — "MCP is bearer-only unless the tools are anonymous-readable, in which case say so at the guard"), confirm dolt's mount in `cmd/doltsrht/mcp.go` states and matches that policy explicitly (bearer + meta PAT, not cookie), including in a doc-comment on the mount itself.

Status: verified by the underlying report, which explicitly retracted an earlier misreading of a sibling's (coverage's) documented behavior — treat the family-wide policy statement itself as not yet written, and dolt's own mount as needing a documented rationale once it lands.

Audit: D30 (cross-repo audit, 2026-08-17)

Depends on

No outgoing dependencies.

Depended on by

Nothing depends on this issue.

No comments.

  • Eugene Blikh created the issue · 2026-08-17T23:39:45Z
Stored rows — what this pane was built from, as read
issues 1 row
id sr-ht-dolt-aff
content_hash 6d8842504ede56b780b9fb7ac71d1dbb30600ee8ca0cfef2efcb5bbc01723207
title Document /mcp credential policy (bearer + meta PAT) against the family-wide MCP auth rule
description What is wrong: `/mcp` mounting differs across services with no shared written policy. `sourcehut-dolt/cmd/doltsrht/mcp.go` uses its own bearer validator and additionally accepts a meta PAT — a fourth distinct answer alongside bench (structurally bearer-only, no cookie/resolver access), coverage (sits under the shared resolver so cookies reach it, gates reads on `p.IsInstanceToken()` only), and curator (also sits under the shared resolver via `agents.Mount(s.Resolver.Middleware())`). Why it matters: this is not by itself a hole in dolt — every tool still runs its own visibility check — but there is no single documented answer, family-wide, to "what does an MCP surface accept on this instance", and each service currently answers that question independently. dolt's own answer (bearer + meta PAT, no cookie) is plausible and is also the basis for the `Authorization`-only Vary header dolt uses (relevant to D02/D10), but it is undocumented as a deliberate policy rather than an accident of implementation. Sibling comparison: none of the four current answers is wrong per se; the defect is the absence of a written rule any of them can be checked against. coverage's split (anonymous read allowed, but only via `IsInstanceToken()` gating) is explicitly documented as intentional in its own code, which is the standard the others — including dolt — should meet. Fix: once the policy is written once, family-wide (in `sr-ht-ecore/mcphttp`'s package doc or the tokens SPEC — "MCP is bearer-only unless the tools are anonymous-readable, in which case say so at the guard"), confirm dolt's mount in `cmd/doltsrht/mcp.go` states and matches that policy explicitly (bearer + meta PAT, not cookie), including in a doc-comment on the mount itself. Status: verified by the underlying report, which explicitly retracted an earlier misreading of a sibling's (coverage's) documented behavior — treat the family-wide policy statement itself as not yet written, and dolt's own mount as needing a documented rationale once it lands. Audit: D30 (cross-repo audit, 2026-08-17)
design
acceptance_criteria
notes
status open
priority 2
issue_type task
assignee NULL
estimated_minutes NULL
created_at 2026-08-17T20:39:46Z
created_by Eugene Blikh
owner bigbes@gmail.com
updated_at 2026-08-17T20:39:46Z
closed_at NULL
closed_by_session
external_ref NULL
spec_id
compaction_level 0
compacted_at NULL
compacted_at_commit NULL
original_size NULL
sender
ephemeral 0
wisp_type
pinned 0
is_template 0
mol_type
work_type
source_system
metadata �{}
source_repo
close_reason
event_kind
actor
target
payload
await_type
await_id
timeout_ns 0
waiters
hook_bead
role_bead
agent_state
last_activity NULL
role_type
rig
due_at NULL
defer_until NULL
no_history 0
started_at NULL
is_blocked 0
events 1 row
id 01a01173-a0be-73f7-ac6e-4381f7f4f006
issue_id sr-ht-dolt-aff
event_type created
actor Eugene Blikh
old_value
new_value
comment NULL
created_at 2026-08-17T23:39:45Z