Keymaster MCP server

Keymaster MCP

Trust infrastructure for human–AI teams.

日本語 · Five-minute demo · Adoption playbook · Philosophy · Threat model

Keymaster lets agents discover whether approved capabilities exist and whether their credentials are healthy without returning production credentials to the model. Its companion Outcome Contract accepts results only when external evidence—not the executor's own report—supports the claim.

bounded permission → trusted execution → external evidence → accepted result → next permission

Experience the philosophy without a credential

cd keymaster-mcp
npm ci
npm run demo:local

The loopback-only demo uses one synthetic value and proves that:

• secret_status returns available;
• get_secret is not exposed;
• the synthetic credential never crosses model-visible MCP output;
• no cloud account, Vault deployment, paid service, or real credential is required.

The demo is an executable explanation, not a production proxy.

Two public entry points

1. Verify whether an AI result is real

Install the public outcome-contract skill from Codex:

$skill-installer install https://github.com/AInoAKARI/keymaster-mcp/tree/main/skills/outcome-contract

Use it before accepting claims such as completed, shipped, paid, adopted, delivered, saved time, reduced cost, removed risk, or received a recipient response.

It calls the free AIﾉアカリ☆ Result Receipt Auditor and returns a verdict, accepted evidence, missing evidence, the next verification action, and the truth boundary of the verdict.

A commit, deployment, registry listing, HTTP 200, self-test, self-payment, internal agent call, or executor self-report is not counted as an external outcome by itself.

2. Check credential capability without disclosing credentials

@akari-os/keymaster-mcp is the non-disclosing Vault status bridge for autonomous AI agents.

claude mcp add keymaster -- npx -y @akari-os/keymaster-mcp \
  --vault-url https://your-keymaster.example.com

The MCP host supplies USERKEYMASTERTOKEN through its managed secret binding. Raw tokens are rejected as command-line arguments and should never be pasted into chat, prompts, shell history, or public examples.

The server exposes:

• secret_status — check one approved credential without returning its value;
• list_services — discover supported service/key-name pairs;
• list_secrets — list approved paths as metadata only;
• healthcheck — validate credentials upstream and return statuses only;
• rotate_secret — return safe rotation guidance without accepting a replacement value.

Full package documentation: keymaster-mcp/README.md

The trust model

Capability without credential custody

The model can know what capability is available and whether it works. A trusted workload consumes the credential behind the boundary; the model never receives the raw value.

Trust with evidence

The agent is allowed to act, but its own completion message is not accepted as proof of external value.

Philosophy as protocol

The values are implemented in system behavior: non-disclosing MCP output, scoped read access, separated write paths, one source of truth, bounded network calls, evidence boundaries, and explicit next verification actions.

From demo to real adoption

1. run the zero-secret demo;
2. register one low-risk credential in Vault;
3. connect Keymaster with a read-only host secret binding;
4. let the agent verify availability through secret_status;
5. execute the authenticated action behind a trusted workload boundary;
6. apply Outcome Contract at the acceptance boundary;
7. preserve the evidence packet and result receipt.

Shortened. The full README is on GitHub.