A hosted MCP server, verified live in front of you. Every verdict comes from the shipped @kya-os verifier, nothing is mocked, and every claim ships with a curl you can run yourself. Try to break it!
L1 · Assertiontrust the operator
L2 · Attestationtrust a root-keeper
L3 · Independentanyone can check
L4 · Self-enforcingcan't run if integrity breakspartial*
The MCP server
A live hosted server with a published identity. Everything below runs against it.
opening a connection to the live server…
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.
The verification
Each step sends a request to the server above. The verifier checks the evidence and rules on it here.
A The demo agent's request
method vault/read
file
The proof is bound to the original file - step 3 shows the mismatch
connecting…
Full proof object
No proof yet. Run a step and the proof generated by that action appears here.
→presents proof
B The verifier decides
Start with Step 1 - call the live server and verify its proof against its published DID.
The steps
Drive them one by one, or press play all in the top bar.
1 Verify the LIVE serverreal MCP call → proof from _meta → key from its published did:web
2 Establish controla demo agent (an AI assistant stand-in, keys minted just for your visit) signs a request and the server allows it
3 Try to break itevery attack hits a different gate - one click each
4 Revoke a delegation - on the LIVE serverthe agent holds a delegation for a sensitive write; revoke it on the published status list and the write is refused
5 Levels are derived, not claimedthe Entity Card's own ladder, computed from evidence (a different scale from the banner)
6 Anyone can checka 2nd implementation, another language, same verdict
Verifiability checklist · demonstrated live
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