Ownership Provenance Protocol

io.github.bg4ff8mtdn-dotcom由 GitHub 帳號 bg4ff8mtdn-dotcom 發布v1.0.1更新於 Oct 24, 2026

MCP protocol requiring task acceptance and provenance tags. Self-hosted only - see README.

已驗證Streamable HTTP可網頁執行效率與工作流開發者工具

概覽

AI 產生的概覽

一個精簡的 MCP 協定伺服器,要求代理明確接受任務歸屬,並為每筆完成聲明標註其驗證來源。

可以做什麼
  • 建立處於待接受狀態的任務,並明確接受任務;若任務已有其他擁有者則以原子方式拒絕。
  • 回報完成時必須附上來源標籤(observed、reviewed 或 reported),缺少或無效的呼叫會被直接拒絕。
  • 交接任務時凍結當下的狀態快照,接收方須自行接受後才成為擁有者。
  • 查詢單一任務的完整歷程(接受、完成聲明及其來源、交接),並列出目前無人擁有的任務。
適用情境
適用於多代理或人機協作中任務交接容易遺失、完成聲明的可信度被誇大的情境。它是一個用來驗證接受與來源標註機制的窄範圍參考實作,而非治理平台或評估框架。
執行需求
清單標示為遠端端點,但 README 描述的是自架部署:需要 Node.js 24、PostgreSQL 與 pnpm,並設定 DATABASE_URL 與 MCP_ACCESS_TOKEN。MCP 服務掛載於 /mcp,除健康檢查外每個請求都需在 Authorization 標頭帶上 MCP_ACCESS_TOKEN 作為 bearer token。呼叫任何工具前資料庫中必須已存在至少一個 actor,因為協定不提供建立 actor 的工具。
安裝前請注意
README 說明本專案處於早期階段,僅由作者本人測試,未聲稱可用於正式環境。除健康檢查外,每個請求都需要 MCP_ACCESS_TOKEN 這個 bearer token。工具會將任務、歸屬與完成紀錄寫入資料庫;測試套件會清空所有資料表,切勿指向真實資料庫。actor 身分由呼叫方提供,協定本身不簽發身分。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Ownership Provenance Protocol,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Web executable,透過 Streamable HTTP。 遠端服務在工作區中設定後即可從網頁執行環境執行。

交給代理程式安裝

把這段提示詞貼上到 Claude Code、Codex、Cursor 等代理程式,或 SourceWeft 對話中。代理程式會讀取該伺服器的安裝指南,先向你展示發布者、端點和登入方式,經你同意後再把它新增到你的客戶端。金鑰不會寫進任何命令。

閱讀 https://sourceweft.com/mcp/io.github.bg4ff8mtdn-dotcom%2Fownership-provenance-protocol/install.md,並按其中說明把這個 MCP 伺服器接入我的客戶端。修改任何設定之前,先告訴我它的發布者、端點和登入方式,等我確認。不要把 API 金鑰寫進命令或我會提交的檔案;問我金鑰應從哪裡取得。

檢視代理程式所依據的安裝指南

其他 MCP 客戶端

把它新增到你客戶端的 mcpServers 設定中。

{
  "mcpServers": {
    "ownership-provenance-protocol": {
      "type": "http",
      "url": "https://ownership-provenance-protocol.replit.app/mcp"
    }
  }
}

README

Ownership & Attestation Protocol (OAP)

A small MCP protocol that enforces two rules no mainstream agent framework currently enforces natively:

  1. A task isn't owned until it's explicitly accepted. Assignment, inference, or ambient context aren't enough — an actor (human or AI agent) must explicitly accept a task before it counts as theirs.
  2. No completion claim can be reported without saying how the reporting actor knows it's true. Every "this is done" claim carries a mandatory provenance tag: Observed (I did this myself), Reviewed (I checked evidence of it), or Reported (I'm relaying what I was told). There is no fourth option, and there is no way to report completion without picking one.

That's the whole protocol. Everything else in this repo exists in service of those two rules.

Why this exists

Broken ownership handoffs are a commonly cited failure mode in production multi-agent systems — an agent hands work to another agent, context gets lost, and nobody ends up owning the result. Separately, a March 2026 paper on agent identity protocols (Prakash, AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A, arXiv:2603.24775) reports that in the authors' survey, they did not identify a prior implemented protocol that jointly combines verifiable delegation, attenuated authorization, and provenance-oriented completion records.

This project was built to test a narrow, specific fix for both problems at once — not a full governance platform, not an evaluation framework, just the ownership/acceptance and attestation mechanics.

Real-world motivation

Two documented, public incidents shaped this design directly:

  • A Replit AI coding agent deleted a production database during an active code freeze, then falsely claimed rollback was impossible — a claim stated with full confidence that was never actually verified. Rollback worked fine once someone actually tried it. (AI Incident Database, Incident #1152)
  • Air Canada's chatbot gave a customer incorrect eligibility details for its own bereavement-fare policy, telling him he could claim the discount retroactively when the actual policy required approval before travel. A tribunal ruled the airline liable — establishing that companies own what their AI tells people, whether or not a human ever reviewed the claim first. (Moffatt v. Air Canada, 2024 BCCRT 149, British Columbia Civil Resolution Tribunal)

Both failures are the same shape: a claim stated with more confidence than it had earned. That's the specific thing this protocol is built to catch — not by making agents smarter, but by making it structurally impossible to report a claim without saying how it was actually verified.

The six MCP tools

ToolWhat it does
create_taskCreates a task in pending_acceptance state. Nothing is owned yet.
accept_taskExplicit acceptance. Fails if the task already has a different current owner — enforced atomically, safe under real concurrency, not just sequential calls.
report_completionRequires a valid provenance value (observed | reviewed | reported). Rejects the call outright if it's missing or invalid — this is the one non-negotiable rule in the whole system.
handoff_taskTransfers ownership, capturing a frozen snapshot of task state at the exact moment of transfer. The recipient does not automatically become the owner — they must call accept_task themselves before they can act.
get_task_statusReturns the complete history for one task: injection, all acceptances, all completion claims with their provenance, all handoffs.
list_unaccepted_tasksSurfaces tasks with no current owner — a direct, queryable signal for exactly the "silent inheritance" risk this protocol exists to prevent.

Protocol invariants

These six statements hold in any conformant implementation, at all times:

  1. Every task has zero or one current owner.
  2. Ownership changes only through explicit Acceptance.
  3. Every completion claim has exactly one provenance value.
  4. Provenance values never become "more certain" without new evidence — an actor cannot upgrade a Reported claim to Observed without an intervening act of verification. This implementation enforces that by rejecting an observed claim that supersedes a reported one on the same task unless the call supplies a sourceReference naming what was verified. Downgrades, corrections in the other direction, and first claims are unaffected.
  5. Every handoff captures a state snapshot.
  6. Every task's history is fully reconstructable.

An implementation is OAP-conformant if it requires explicit acceptance, rejects claims without provenance, supports all three provenance categories, preserves reconstructable history, and supports ownership transfer via handoff. Partial implementations should describe themselves as "OAP-inspired," not conformant.

Why not just use logs / Git / OpenTelemetry / Temporal?

Fair question, and the short answer is that OAP is meant to sit alongside these, not replace them:

  • Logs record what happened passively, after the fact. OAP requires an active commitment before a claim is accepted as complete.
  • Git versions content and records who committed what, but has no concept of an accepted, ongoing obligation separate from the artifact itself.
  • OpenTelemetry propagates context through a distributed trace excellently, but has no schema concept equivalent to a provenance tag on a claim of correctness.
  • Temporal / durable execution engines solve state persistence and reliable resumption extremely well — this reference implementation is meant to be built on top of something like that, not reinvent it. But durable execution answers "did this step run," not "did the actor own this task by explicit acceptance, and how do we know its completion claim is true."

Running it locally

Requirements: Node.js 24, PostgreSQL, pnpm.

bash
pnpm install

Set the required environment variables:

DATABASE_URL=<your Postgres connection string>MCP_ACCESS_TOKEN=<a long random string — generate one with `openssl rand -hex 32`>

Push the schema and start the API server:

bash
pnpm --filter @workspace/db run pushpnpm --filter @workspace/api-server run dev

Create at least one actor before calling any tool. Every tool takes an actor id, and every one of them requires that actor to already exist — the actor columns are NOT NULL foreign keys. The protocol deliberately has no create_actor tool or route: actor identity is an input to OAP, not something OAP issues, so on a real deployment actors come from whatever system already owns identity. That means a freshly pushed database has no actors in it and the first create_task call will fail with a 404 until you add one. For local development there is a seed script:

bash
pnpm --filter @workspace/scripts run seed-actor alice human "Alice"

It is a plain script, not part of the protocol surface — it is never imported by the server and is not reachable over HTTP.

The MCP server is mounted at /mcp and requires the MCP_ACCESS_TOKEN as a bearer token in the Authorization header on every request except /api/healthz, which stays open for health checks.

Connect a real MCP client (e.g. Claude Code):

bash
claude mcp add --transport http opp http://localhost:5000/mcp --header "Authorization: Bearer <your-token>"

Running the tests

The suite covers the protocol's concurrency guarantees, so it needs a real PostgreSQL instance — it exercises genuinely simultaneous transactions and cannot run against an in-process or single-connection substitute.

bash
pnpm --filter @workspace/api-server run test

Tests connect to postgresql://opp:[email protected]:55432/opp_test by default. Point them elsewhere with OPP_TEST_DATABASE_URL, and push the schema to that database first. The runner ignores DATABASE_URL entirely and refuses to start against any non-loopback host: the suite truncates every table between tests, and inheriting a real connection string would destroy exactly the provenance record this protocol exists to protect.

Status

This is an early, personally-tested project, not a polished product. It has been built and adversarially tested by hand — concurrency races, malformed inputs, ownership-bypass attempts — and verified end-to-end with a real external MCP client completing the full protocol handshake against a live deployment. The ownership and attestation guarantees that hand-testing covered are now pinned by an automated suite that runs the races concurrently against a real database. It has not been used by anyone beyond its author, and no claims are made about production-readiness beyond what's described above. If you use this and find something that breaks, or a case the invariants don't cover, please open an issue.

License

MIT

來源:README.md,提交 aeed118

工具

0
SourceWeft 尚未讀取此伺服器的工具。

版本歷史

1
  1. v1.0.1最新Sep 16, 2026

評分

已滿足適用檢查項的 85%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通必需25 分
  • 已宣告認證方式必需10 分
  • 已列出工具必需15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分