MCP 服务器

correctover-mcp-server

Enables protocol-level runtime verification of AI agent tool calls across six dimensions with a fail-closed guarantee, blocking any action that fails verification before execution.

README

CCS Runtime Evidence MCP Server

A Model Context Protocol (MCP) server that brings CCS runtime verification to any MCP-compatible client — Claude Desktop, Cursor, Windsurf, and more.

It verifies AI agent tool calls at runtime, blocks unsafe ones by default, issues tamper-evident evidence records for every decision, and verifies that actual tool arguments match the agent's declared intent — catching cross-model parameter drift.

Runtime evidence layer, not a static scanner. Every decision is enforced at call time and produces independently verifiable cryptographic evidence.

Quick Start

npx -y ccs-mcp-server

MCP Client Configuration

{
  "mcpServers": {
    "ccs-runtime-evidence": {
      "command": "npx",
      "args": ["-y", "ccs-mcp-server"]
    }
  }
}

Zero dependencies. 44KB. Pure Node.js stdlib. No install scripts.

Tools

Tool	Purpose
`verify_tool_call`	7-dimension runtime verification (Structure/Schema/Security/Identity/Integrity/Latency/Cost) + semantic attack-chain analysis + math overflow detection. Blocks by default.
`issue_evidence`	Issue a tamper-evident evidence record (`content_hash` + `evidence_hash`, chainable). Produced for allowed AND denied calls.
`audit_mcp_config`	Audit MCP configuration JSON for security risks.
`verify_intent_binding`	(v1.1.0) Verify actual tool arguments match a declared intent — zero tolerance, zero LLM calls. Catches cross-model parameter drift (planner says `amount: 100`, executor writes `amount: 10000` → DENIED).

Intent Binding — Cross-Model Drift Detection

Agent planners (Claude, GPT) declare one thing; executors (Qwen, DeepSeek) sometimes write another. No existing protocol verifies that actual tool call arguments match the agent's declared intent:

AP2 signs human authorization — not LLM intent
AgentPay does baseline tolerance (1%) — not zero-tolerance equivalence
ACS runs policy decisions — not argument-level equivalence
VAP (draft-samal-vap-00) explicitly excludes argument semantics from its wire schema

CCS Intent Binding fills this layer. The agent framework declares a structured intent before execution; CCS verifies actual arguments against it in sub-millisecond, zero-LLM time.

Example: amount drift

// Intent declared by planner
{
  "intent_id": "int-001",
  "intent_type": "payment",
  "fields": {
    "amount": { "value": 100, "binding_mode": "exact" },
    "recipient": { "value": "Alice", "binding_mode": "exact" }
  },
  "issued_at": 1755000000000,
  "ttl_ms": 30000
}

// Actual arguments from executor
{ "amount": 10000, "recipient": "Alice" }

// Result: DENIED — intent_arg_mismatch
// field: amount, expected: 100, actual: 10000

Three binding modes

Mode	Behavior	Example
`exact`	Deep equality with math normalization	`100`, `100.0`, `1e2` all match; `10000` does not
`numeric_tolerance`	Absolute tolerance	`100 ± 0.01` matches `100.005`
`pattern`	Regex match on string fields	`^[A-Z]{3}$` matches `"USD"`

No intent declared? Falls through to standard 7-dimension verification. Zero breaking changes.

What It Detects

Command injection: shell metacharacters, curl|sh, rm -rf, eval()
Path traversal: ../, /etc/passwd, /proc/self/
SSRF: 169.254.169.254 (cloud metadata), localhost, private ranges — across any tool
Cross-tool attack chains: read sensitive file → network exfil = exfil_chain
Environment variable exfiltration: API keys, secrets, credentials
Obfuscation: hex encoding, base64, privilege escalation signals
Math safety: integer overflow (>2^53-1), NaN/Infinity
MCP config risks: plain HTTP, weak secrets, --insecure, TLS disabled

Evidence Chain

Every decision produces evidence with dual hashes (content_hash + evidence_hash) and chain linkage (parent_evidence_hash). Any third party can independently verify that evidence has not been tampered with — without trusting the operator.

evidence 1: allowed  (fs.read_file)       parent: null
evidence 2: denied   (shell.exec curl|sh) parent: ev1
evidence 3: denied   (http.fetch SSRF)    parent: ev2
evidence 4: denied   (fs + curl exfil)    parent: ev3

The 7 CCS Dimensions

Structure — valid tool name, argument format, nesting depth, payload size
Schema — type, required fields, enums, ranges, string lengths
Security — injection, traversal, SSRF, env exfiltration, obfuscation + semantic attack chains
Identity — caller agent ID verification
Integrity — request hash validation
Latency — execution time budget
Cost — cost budget

Interoperability

CCS receipts are Ed25519-signed, JSON-based, and verifiable offline with zero dependencies. If your project produces or verifies signed attestations, receipts, or evidence records, see INTEGRATION.md — a one-page guide covering:

Full receipt field schema (22 fields)
JCS canonicalization spec
Three levels of interop (same crypto → cross-referenced chains → field-aligned)
30-second verification snippets (Node.js + Python)
Clear scope boundaries (what CCS does / does not cover)

Join technical discussions in GitHub Discussions — receipt interoperability, field mapping proposals, and protocol feedback welcome.

Protocol Context

IETF: draft-correctover-ccs-06 (Experimental) — RT#55620 submitted
Complements: VAP draft-samal-vap-00 (scope/budget/purpose), Microsoft ACS (policy decisions), AP2 (human authorization)
Does not replace: authentication, payment networks, policy engines

Ecosystem

Project	What it does
ccs-demo	Complete INSPECT→SIGN→VERIFY walkthrough — 6 scenarios, zero dependencies, `node demo.js`
ccs-verifier-action	GitHub Action — verify CCS receipts in CI/CD pipelines
ccs-mcp-server	Core MCP server (this repo) — runtime verification + evidence signing
ccs-proxy	Commercial — inline enforcement proxy with L2 protocol attestation + L3 execution binding (Ed25519 signed receipts)