I keep running into the same hole in agent systems, and the hole is not in the model.

When an agent picks up a tool server it has never seen before, nothing in the transport tells it whether the token it is holding was ever meant for that server. There is no issuer/audience binding worth the name, no uniform 401 path, no baseline for dynamic client registration, and the tool description and its output both arrive unsigned and unverified. So the trust boundary of an agent deployment ends up being whichever third-party tool is weakest, and right now that boundary is not specified anywhere.

I want to fund the boring part of fixing that. Two pieces of work, both runnable by someone who has never met me.

The first is an authorization conformance suite for MCP servers, months 1 to 3\. Checks for issuer/audience binding, the 401 plus discovery flow, and a dynamic client registration baseline, packaged as a harness anyone can point at their own server. The deliverable is the suite itself plus a public conformance report across at least two independent server implementations, including the divergences it actually finds.

The second is a tool-trust metadata profile and an offline verifier, months 3 to 6\. A small profile for agent tools: who published it, where the description and the output came from, supply-chain identifiers. Plus a verifier a consumer can run without trusting any registry. It builds on the public white paper I wrote on MCP tool trust metadata, which walks from the NSA PP-26-1834 requirements to a metadata profile, to offline verification, to the registry boundary.

Why one person can finish this: both artifacts are small and testable. The suite is a set of runnable checks, not a research programme. The verifier is defined by positive and negative fixtures, so a check cannot pass by accident. Every deliverable pins the spec revision it was written against.

What I have actually shipped, since that is the only thing that should count here: 24 merged pull requests, none rejected, to sipyourdrink-ltd/bernstein, an Apache-2.0 governance layer for agents. That work includes a CycloneDX 1.7 AI-BOM with a model card validated against the official schema, a C2PA 2.4 ai-disclosure assertion projection, a NIST AI 100-2e2025 crosswalk of the guardrail stack, and audit-chain, provenance and sandbox-path hardening. The white paper behind this proposal is public at github.com/Louis20060723/mcp-tool-trust-metadata. Two NGI Zero (NLnet) submissions on adjacent MCP scope are under review.

The budget: 10,000 USD covers the first piece in full and half of the second. Roughly 85 percent is my own engineering time, 10 percent pays the upstream maintainer for independent review, 5 percent goes to writing it up in public. No office, no equipment, no travel. It is part-time work at a below-market rate.

How you would know it worked. The suite runs against at least two independent MCP server implementations and the findings get published, including whatever it catches. The verifier rejects crafted negative fixtures and accepts crafted positive ones. Somebody who is not me reproduces a run. And there is an ops guide a team can follow without having to ask me anything.

What I am not claiming: this does not make agent systems safe. It makes one specific and rather boring failure class, token replay and confused deputy and tool output with no verifiable source, more expensive to pull off. It also gives auditors and buyers something they can check instead of something they have to believe. If the suite finds no divergences in the servers I test, that is a published result too.

Other funding, for transparency: two NGI Zero (NLnet) applications on adjacent MCP scope are under review, and a separate application for the same programme of work is pending with another funder. This proposal covers the conformance suite and the metadata verifier only. Any award gets reported here and to the other funders.

I am an individual developer. My public identity is github.com/Louis20060723, and the maintainer of the upstream project provides independent technical review. Correspondence can go through the platform.

Housekeeping, since this page labels the text AI-generated: the draft above was written with AI assistance and edited by me. The deliverables described here, the technical review behind them, and the responsibility for them are mine.