Roadmap & Fleet Sync
Adding a capability to an agent is one line of JSON, and after that line an unvetted server describes its own tools to your agent. Doorman makes tool governance continuous across your team: auditing coworker harnesses, keeping golden allowlists synced across Claude Code, Cursor, and Windsurf, and diffing builds week-over-week.
The 7 Stages Cryptographic Trust Rail Try Simulator
Click canvas or button to drop and snap a new cryptographic block
The shape of the decision
Every stage can end the run. Three of them end it for free. The expensive one is deliberately last, and it is the only one that does not run on your machine.
| Stage | What it answers | Runs | Cost |
|---|---|---|---|
doctorL0 |
What does this build already have, and is the gate installed and wired | your machine | free |
| feedshared | What has been graded lately, one row per server | ours | free |
watchprivate |
Which of those are new to this build, and which are already installed or blocked | your machine | free |
| Fit Review | redundant, fits, needs-new-subagent, or out-of-scope. Two of those stop the run | your machine, your key | tokens |
reportL1 |
What it actually implements: protocol, schemas, annotations | your machine | free |
| grade paidL2 | Is it safe and competent. Does it tell your agent to do something you did not ask for | ours | $0.01 |
evalL3 |
Does it actually make your agent better, measured against a real task | your machine, your key | $3.57 typical |
The order is the argument. The A/B at the bottom is the measurement anyone actually wants, and it is the expensive one: three runs per arm on Sonnet is $54.47 worst case and $272.34 on Opus, which is refused outright at a $5 ceiling. So a cent spent above it is not a fee, it is the gate on a fifty dollar spend. That is also the only stage that can honestly be sold, because it is the only one running on somebody else's computer.
Not everything can be measured the same way
A candidate arrives as a link. What it is decides what can honestly be said about it, and the detector refuses to guess: a path that is neither a url nor a markdown file raises rather than sending a directory to a grader.
| Kind | Recognised from | Behavioural grade |
|---|---|---|
| MCP server | a url that is not a repo, a gist or a markdown file | yes, it has tools to drive |
| Skill | a .md file, a gist, a blob/ or raw/ link |
scanned, never graded |
| Repo | github.com/owner/repo |
scanned, never graded |
A skill gets behavioral: "n/a - no tools to probe".
Not a null, and not a zero. There is nothing to drive, so no behavioural
grade can exist, and the report says which of those it is rather than
leaving a gap for a reader to fill in wrongly. The same rule runs
through everything here: an unmeasured layer is null and
weights renormalise over what actually ran, because zeroing a layer
nobody measured fails an honest partial audit.
The direction
A weekly digest of interesting repositories tells everybody the same thing. This is the version that knows what you already run. Getting there without collecting anyone's stack means splitting the work in two.
| Half | Where it runs | Who pays | Cost of the next subscriber |
|---|---|---|---|
| The gradeshared, cached, public tape | ours | whoever asked first, once | $0.00 |
| The fityour roster, your servers, your allowlist | your machine | you, in tokens | their own |
Nothing about your build is sent anywhere.
doorman watch makes exactly one request, a GET
for the feed, and that request says nothing about who is asking. Your
agent roster, your installed servers and your allowlist are read locally
and stay there. The privacy is not a policy, it is the shape of the thing.
And it will not claim more than it measured. What runs in
watch today is a mechanical overlap check: it can tell you
that you already have something, and that something hard-failed. It cannot
tell you whether a server you do not have would help, so it never says
fits. Two tests exist for the sole purpose of stopping it
ever doing so, because that word belongs to the fit review and a string
match cannot earn it.
Why this needs a payment rail
The useful price for "is this new tool worth your attention" is a fraction of a cent. Card fees exceed the value of the thing being sold, so the product cannot exist on that rail at all. It is not that a micropayment rail is nicer here. It is that the service is impossible without one.
A grade is cached and its full transcript is free and needs no token, forever. So the first agent to ask about a server pays a cent, and every agent after it reads that verdict and its evidence for nothing. One micropayment does not buy one answer. It funds a commons that nobody could bill for directly.
What is missing is on the other side. A subscription
that tracks new listings needs a source of new listings, and the
released Bazantic CLI has no marketplace discovery command:
gateway list returns your own gateways, not the catalogue.
That is the one dependency in this design that does not exist yet, and
it is stated here rather than drawn as though it did.
Where this goes
Grading a server answers “is this safe and worth adopting”. There is a larger question underneath it that nothing currently answers: why is my agent worse than yours?
Everyone on a team runs a different harness. Different MCP servers, different skills, different versions, different permissions, different things silently blocked. When something works on one machine and not another, the honest answer today is a shrug, because the two builds are not comparable and never were. Call it harness drift. It is the same class of problem as dependency drift, twenty years less mature, and currently invisible.
Most of the parts already exist and were built for the single-user case.
doorman doctor inventories a build and reports what is gated.
doorman needs matches that build against what its own prompt history
keeps asking for. The feed is a shared catalogue where every grade links to a
replayable transcript. And the gate resolves its trust list project first, then user,
then shipped default. That resolution order is the load-bearing part: a team layer
slots between project and user without a redesign, and a plugin update still cannot
overwrite a choice somebody made.
A working build becomes a snapshot somebody else can adopt: which servers, which versions, which are graded and which are merely allowed. The distinction between graded and allowed is the whole point, and it is already tracked.
“You run deepwiki graded A, I have nothing. You have chrome-devtools, mine is blocked. Your scorecard plugin is a version behind.” This is the feature people would open daily, and the one that turns a security gate into something a team notices.
One list, agreed once, enforced offline on every machine, with the same fail-closed behaviour and the same rule that an ungraded server is not a trusted one. No new mechanism is needed: the gate’s existing resolution order accepts another layer.
None of this is built. It is written here because the grading engine is what would make the answer credible. A config diff tells you two machines differ. A graded catalogue tells you which one is right.
The line, drawn where it falls
Everything in the first table can be run today by anyone reading this. Everything in the second is specified and honest about being specified.
| Working today | How to check |
|---|---|
| The feedone row per server, newest grade | GET scorecard.wanessalabs.com/feed, free, no account |
doorman watchthe private half |
clone the repo, run it against your own project |
doorman doctorreads your build |
free, local, read only |
| The static gradeand the injection scan | 24 servers on the board, every one linking its tape |
| The gatewaylive and priced | a 402 price probe costs nothing and returns the real price |
| The gatefails closed, exit 2 | 29 adversarial tests, offline, dependency free |
| Not built | What is actually missing |
|---|---|
| The behavioural layer70 of every 100 points | An API key. The probes are written and tested; they have never met a live model. Every published grade says so. |
| Marketplace ingest | A discovery API on the gateway side. Today the feed contains what was pointed at it. |
| Recurring settlement | Nobody has paid through the gateway even once. The rail is live; the meter has never turned. |
| On-chain anchoring | A stub that returns anchored: false and a null tx, on purpose, so nothing downstream can mistake it for real. |
How Clembot Doorman scales from a single-project security gate into a decentralized package manager and registry for autonomous agents across all harnesses.
180-line deterministic offline hook (exit 2), doorman doctor, 12-taxonomy doorman needs prompt engine, static injection scanner, cross-platform Node installer, multi-directory skill discovery, and live Bazantic x402 gateway.
Automated recurring subscription daemon (doorman watch --poll) notifying developers when trusted tools suffer adverse security demotions, with automatic recipe.md redrafting when tool schemas change.
First-class integration across Claude Code plugins, Cursor / VS Code extensions, Google Antigravity and Windsurf. Universal skill frontmatter registry across .claude/skills and .agents/skills.
On-chain cryptographic anchoring of SHA-256 evidence bundles on Hedera Consensus Service / 0G Network. Autonomous agent micropayment settlement via Coinbase AgentKit / ERC-4337 smart accounts on Base.
Ephemeral just-in-time tool provisioning in throwaway sandboxes, execution strictly behind pinned recipes, and continuous adversarial fuzzing of public MCP directories funded by x402 bounties.
How to check this page is honest: the four ordered tests behind it are written down, with the observed output of each, in RUNBOOK.md. Three of the four cost nothing to run. If any row above is wrong, that is a bug and it is worth reporting.
