← bindings
spec v1.0.0

MCP

spec v1.0.0

KYA-OS extends the Model Context Protocol with cryptographic identity.
The first enforcement surface for KYA-OS primitives.

Introduction

— Servers prove their identity.
— Authorization enforced per-tool.
— Proof of every agentic action.

Aligned with MCP 2026-07-28: stateless, so every request carries its own self-contained proof. Packaged as the org.kya-os/decentralized-authority extension.

1. How It Works

When an AI agent wants to use a tool, both sides prove who they are—like showing ID before entering a building.

Claude
AI Agent
"Who are you?"
→
←
"Here's my proof"
Calendar
MCP Server

2. Proof on Every Request

No handshake to establish first. Each request carries a self-contained, sender-constrained proof the server verifies on its own—so any request can land on any instance.

1. Agent attaches a proof to the request
{
  "method": "tools/call",
  "params": {
    "name": "read_calendar",
    "_meta": {
      "org.kya-os/request-proof": {
        "prf": "org.kya-os/proof.v1",
        "did": "did:key:z6Mk...",
        "requestHash": "sha-256=:...:",
        "jws": "eyJ..."
      }
    }
  }
}
2. Server verifies it and signs the response
{
  "result": { "...": "..." },
  "_meta": {
    "org.kya-os/response-proof": {
      "jws": "eyJ...",
      "meta": { "did": "did:web:srv...", "responseHash": "sha-256=:...:" }
    }
  }
}

3. Tool Authorization

Tools declare what permissions they need.
The agent checks if the human granted those permissions before calling.

User Grants Claude calendar:read
Agent Checks delegation exists
Server Validates delegation chain
Executed With signed proof

4. Origin Proof

A detached proof binds the tool request and response to identity, session, authorization context, and exact content. It proves origin; it does not assign a position in an audit ledger.

{
  "name": "read_calendar",
  "arguments": { "date": "2026-07-28" },
  "_meta": {
    "org.kya-os/request-proof": {
      "prf": "org.kya-os/proof.v1",
      "delegationRef": "vc_root>del_123",
      "requestHash": "sha-256=:...:",
      "jws": "eyJ..."
    }
  }
}

5. Errors

No proprietary numeric codes. A server that requires the extension rejects an undeclared client with MCP's own -32021 (missing required capability); every KYA-OS verification failure carries a machine-readable error.data.reason.

proof_missing              No request-proof on a gated call
proof_invalid              Holder-of-key proof did not verify
proof_level_insufficient   Assurance below the required level
delegation_invalid         Delegation chain failed verification
delegation_revoked         A credential in the chain was revoked

6. Audit Lifecycle

The MCP adapter projects protocol lifecycle transitions into strict, privacy-minimal audit events. A single authoritative recorder then orders accepted events and returns a signed append receipt.

session / authorization / tool lifecycle
                  ↓
        frozen producer event
                  ↓
     authoritative recorder append
                  ↓
        signed entry + receipt
                  ↓
 checkpoint, observation, and replay bundle

Delivery is explicitly best-effort, buffered, or required. A buffered event is pending until receipt reconciliation; only a required append has an authoritative receipt at the response boundary. Raw arguments, responses, prompts, tokens, and exception text are excluded from the integrity ledger by default.

The audit receipt is a ledger record, not a transport field: what a caller receives in _meta is the org.kya-os/response-proof, which is verifiable on its own without consulting the ledger.

Managed deployments use Checkpoint as the recorder. Self-hosted deployments retain recorder authority and can send exact signed envelopes to Checkpoint as a verified mirror. There is never more than one sequencing authority for a ledger epoch.

7. Capability Discovery

The _kyaos identity action exposes audit capability data independently from identity and delegation conformance. It declares the AAP profile, authoritative-recorder topology and epoch, delivery and durability mode, event-coverage scope, integrity suite, checkpoint/observer policy, retention policy, and latest healthy checkpoint.

AAP-0  no audit assurance
AAP-1  Recorded     structured capture of delivered events
AAP-2  Chained      durable atomic history, non-best-effort delivery
AAP-3  Transparent  source reconciliation + signed RFC 9162 proofs
AAP-4  Observed     independent observation and view comparison

The levels are cumulative, and a server must advertise them truthfully: a deployment whose configured mechanics cannot satisfy the profile it selects is required to refuse startup rather than overstate.

8. Implementation

Reference implementations:

npm install @kya-os/mcp   # identity, delegation, proof, and audit protocol

import { createAuditTrail } from '@kya-os/mcp/audit';
import { withKyaOs } from '@kya-os/mcp';

See the auditability protocol for recorder contracts, delivery semantics, privacy boundaries, assurance profiles, and offline replay verification.