A hosted MCP server, verified in front of you. Every verdict is produced by the shipped @kya-os/mcp verifier - nothing is mocked, and every claim comes with a curl you can run yourself. Try to break it.
connecting…
L1 · Assertiontrust the operator
L2 · Attestationtrust a root-keeper
L3 · Independentanyone can check
L4 · Self-enforcingcan't run if integrity breakspending
Where this system honestly sits: Level 3, verified live on this page.
The interaction layer below meets the self-enforcing test (fail-closed, per-request, single-use), but the did:web anchor is a domain root-keeper and the status list is issuer-published - so by the weakest-link rule the composite is L3.
L4 is pending a decentralized anchor (Midnight integration - in progress).
Note: the KYA-OS Entity Card's own conformance ladder (Step 5) also uses "L1/L2/L3" - same letters, different scale; the banner above is the Open-Verification scale.
connecting to the hosted server…
How do I know this is real?
A hosted server, not a local prop. The panel above is fetched live at page-load from the server's own /provenance, /.well-known/did.json and /card.json - the exact package version and DID are read from the wire, never hardcoded into this page.
Step 1 is a real MCP call. The walkthrough opens a genuine MCP session (streamable-http), calls vault_read, takes the proof from the response's _meta, resolves the server's public key from its published DID document, and runs ProofVerifier.verifyProof(). Any third party can do the identical dance - the curl chips above are the start.
Real attacks. Tamper: the SHA-256 request hashes no longer match. Replay: a real nonce cache rejects the spent proof. Steal: a second real keypair fails against the victim's real public key. Every verdict shows the raw { valid, errorCode } the library returned.
Revocation is enforced on the hosted server. Step 4 flips bit 94 of the server's published Bitstring Status List, then reads the PUBLIC list back independently - the same answer any verifier on earth would compute.
A second implementation agrees. Step 6 shells a stdlib-only Python verifier over the same conformance vectors. Not one codebase checking itself - a different language reaching the same verdict.
Residual trust, disclosed (the framework's Transparency rule): the did:web anchor trusts DNS + TLS for the domain; the status list trusts its issuer's hosting; timestamps are signer-stamped within a bounded skew window, not consensus-ordered; and the verifier chooses to enforce the gate. Removing those root-keepers - a witnessed DID log and a decentralized anchor (Midnight) - is exactly the L3 → L4 work.
A The agent's request
method vault/read
file
The proof is bound to the original file - step 3 shows the mismatch
connecting…
→presents proof
B The verifier decides
Start with Step 1 - call the live server and verify its proof against its published DID.
1 Verify the LIVE serverreal MCP call → proof from _meta → key from its published did:web
2 Establish controlthis page's own agent signs a request; the verifier honours it
3 Try to break itevery attack hits a different gate - one click each
4 Revoke - on the LIVE serverflip a bit on the published status list; every verifier on earth sees it
5 Levels are derived, not claimedEntity-Card ladder (its own L1/L2/L3 - see the banner note)
6 Anyone can checka 2nd implementation, another language, same verdict
Self-enforcing properties, demonstrated at the interaction layer
Live server verified - proof checked against its published DID
Fail-closed gate - no valid evidence, no action
Content binding - tamper one byte, it fails
Single-use - a proof can't be replayed
Holder-of-key - a stolen proof from the wrong key fails
Bounded freshness - a stale proof is refused
Live revocation - published, enforced, independently readable
Computed, not claimed - the verifier derives the level
Independently verifiable - a 2nd implementation agrees
What happened
One hosted server · one published dependency · real verifier under the hood. This page is a thin narrator; the security lives in the package.