]> Correctover

Xiamen, Fujian China wangguigui@correctover.com

Correctover

Xiamen, Fujian China wgg234114134@163.com

Internet Engineering Task Force The Correctover Conformance Shape (CCS) defines a tamper-evident, cryptographically bound receipt format that provides runtime verification for agent tool invocations. Each CCS receipt captures a seven-dimensional verification outcome -- Structure, Schema, Latency, Cost, Identity, Integrity, and Security -- as a single artifact suitable for consumption by audit, compliance, and observability systems. CCS is designed as a pluggable runtime verification infrastructure layer that complements -- but does not replace -- existing and emerging agent protocol work at the IETF. Specifically: (1) the AUDIT effort (draft-kuehlewind-audit-architecture) defines an auditing architecture with Action Record and Authorization Transition Record types; a CCS receipt provides the verifiable, tamper-evident evidence payload that can populate these record types with cryptographically bound proof of runtime governance decisions. (2) The agentproto WG-forming effort (IETF 126 BoF) addresses agent-to-agent and agent-to-tool communication protocols; CCS provides per-invocation, sub-millisecond runtime verification that operates beneath the session/transport layer, complementing protocol-level context exchange with evidence-level integrity guarantees. Version 1.1 of the CCS receipt comprises 29 fields with full Ed25519 signature coverage, including three causal chain fields (rule_version, tool_call_id, args_digest) that elevate the Integrity dimension from behavioral traceability to verifiable decision causality. The reference implementation (ccs-verifier v1.1.0, PyPI) passes 154 conformance tests across all verification dimensions. This document specifies the CCS Receipt Schema, the Canonical Configuration model, the nine binding mechanisms, key management, transport requirements, verifier source classification, conformance levels, and negative test cases. CCS is protocol-agnostic: it is not bound to Model Context Protocol (MCP), Agent2Agent (A2A), or any other specific agent protocol, and can be integrated into any runtime that governs tool invocations.

The Correctover Conformance Shape (CCS) is a receipt-and-binding specification that produces a single, tamper-evident, cryptographically bound artifact for every tool invocation decision made by an agent runtime's governance layer. A CCS receipt answers: "Given this exact request, this exact configuration, this exact runtime context, and this exact set of rules, the verifier decided ALLOW/DENY/ESCALATE, and here is the proof." CCS is defined as a seven-dimensional runtime verification standard: (1) Structure -- output structural completeness; (2) Schema -- field value conformance; (3) Latency -- within SLA bounds; (4) Cost -- within budget; (5) Identity -- correct model version; (6) Integrity -- HMAC untampered; (7) Security -- RCE/SSRF/credential hijacking interception. CCS is a general-purpose agent verification framework, not limited to any specific protocol such as MCP or A2A. CCS is not a policy language, an authorization framework, or a transport protocol. It is the shape of the evidence that a verifier produces when it finishes evaluating a command. This evidence is intended to be consumed by downstream systems -- including an executor- side Action Evidence Boundary (AEB) as defined in -- as one native artifact within a larger Authorization Evidence Chain (AEC). The reference implementation (ccs-verifier v1.1.0, available on PyPI under Proprietary Commercial License) provides an in-process verifier with Ed25519 receipt signing covering all 29 receipt fields, including the three v1.1 causal chain fields (rule_version, tool_call_id, args_digest). The implementation passes 154 conformance tests and supports both in-process and out-of-process deployment modes.

CCS specifies: A receipt schema () that binds a verdict to the exact invocation context. A canonical configuration model () that binds the receipt to the exact rule set and policy under which verification occurred. Nine binding mechanisms () that connect the receipt to the request bytes, response bytes, runtime context, action identity, parameter identity, issuer, audience, nonce, and freshness window. Key management requirements (). Transport requirements () including fail-closed semantics. Verifier source classification (). Conformance levels and test vectors ( and ). CCS does NOT define: A new authorization receipt format that replaces or competes with . CCS is a verifier-side decision record, not an organizational authorization artifact. A policy language. Rules are pluggable; CCS specifies how rule outcomes are recorded and bound, not what the rules are. A transport protocol for inter-process communication. The reference implementation uses in-process function calls; the out-of-process transport has been implemented with Unix-socket and TCP with TLS. A universal evidence taxonomy. CCS defines one artifact shape for one class of decision (tool-invocation governance). A session management protocol or agent-to-agent communication protocol. CCS operates at the per-invocation verification layer, beneath session and transport protocols.

Two active areas of IETF work are directly relevant to the problem of agent runtime verification and auditing. This section clarifies how CCS relates to each effort and what gap it fills. The AUDIT architecture document () defines an auditing framework for AI agent delegation and interactions, specifying record types including Interaction Records, Action Records, Delegation Records, and Authorization Transition Records. The architecture identifies the need for verifiable evidence at each action boundary. CCS provides precisely this evidence: a CCS receipt is a tamper-evident, cryptographically signed artifact that can serve as the verifiable "action provenance" data source within the AUDIT architecture's Action Record. Where the AUDIT architecture defines what data the audit record should contain, CCS provides the mechanism to prove that each tool invocation was governed, the governance decision was correct, and the decision has not been tampered with since issuance. The agentproto effort, which held a WG-forming BoF at IETF 126 (Vienna, July 2026) (), addresses agent-to-agent and agent-to-tool communication protocols including session management, context exchange, multimodal transport, and discovery. CCS complements this protocol-layer work by providing per-invocation runtime verification at sub-millisecond latency (in-process P50 approximately 7.5 microseconds, out-of-process P50 approximately 133 microseconds). While agentproto defines how agents communicate and manage sessions, CCS verifies that each individual tool invocation within those sessions was properly governed. CCS is protocol-agnostic: it can be integrated with MCP, A2A, or any future protocol standardized by agentproto, as it operates on the verification decision itself rather than on the communication protocol carrying the invocation. The use cases and requirements document (, Reddy/Sarker/Yao) derives protocol requirements for agentic AI communication systems. These requirements include security, authentication, and error handling for agent-to-tool interactions. CCS addresses the runtime verification aspect of these requirements: when an agent invokes a tool, CCS produces a cryptographically bound receipt proving the invocation was governed, the parameters were validated, and the decision was authorized. This evidence can be propagated alongside the session and transport mechanisms defined by agentproto protocols. In summary, CCS occupies a distinct layer in the agent protocol stack: it is neither a session protocol (like agentproto), nor an audit data model (like the AUDIT architecture), nor a communication protocol (like MCP or A2A). It is the runtime verification infrastructure layer that produces the tamper-evident receipts that both audit systems and protocol implementations can consume as proof of governance.

This Internet-Draft is a protocol specification derived from and complementary to the following academic publications: DOI: 10.5281/zenodo.21783723 -- "CCS 7-Dimensional Runtime Verification Framework v0.4.1 Three-Endpoint Closed Loop." This work documents the complete three-endpoint closed loop: IETF Internet-Draft + Zenodo DOI + PyPI ccs-verifier v1.1.0. It covers the seven-dimensional verification model and its implementation. DOI: 10.5281/zenodo.21271910 -- "CCS Formal Framework." This paper defines the mathematical foundation: the Required(tau) subset of Supported(tau) conformance criterion, the transition model, and the formal proof that fail-closed enforcement satisfies the governance criterion. This I-D does not reproduce the formal framework; it specifies the wire-level receipt and binding mechanisms that implement it. DOI: 10.5281/zenodo.21603250 -- "Action Receipts." This paper defines the concept of an action receipt as a tamper-evident record binding a decision to a specific action invocation. The CCS receipt in this I-D is a concrete instantiation of that concept, specialized for tool-invocation governance in agent runtimes. A Palo Alto Networks (PANW) contributor cited CCS DOI in a fork of Palo-Alto-AI-Research-Lab/semantic-kernel (PR #14199, closed by Microsoft). This citation is noted as evidence of external interest in the CCS DOI; it does not constitute adoption by Microsoft or the Semantic Kernel project. Major frameworks including CrewAI and AutoGen are part of the broader agent ecosystem that CCS is designed to serve; CCS DOI has been cited in related research contexts.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. CCS-specific terms: Command: An immutable, structured representation of a tool invocation request, comprising at minimum: agent_id, tool name, parameters, timestamp, and trace_id. The Command is the input to verification. Verifier: A component that evaluates a Command against a set of Rules and produces a VerificationResult. The verifier MAY run in- process (same address space as the agent) or out-of-process (separate address space, separate crash domain). Rule: A pluggable unit of policy evaluation. A Rule accepts a Command and returns a RuleResult with a verdict (allow, deny, escalate), an optional reason string, and a latency measurement. VerificationResult: The output of a verification. Contains the verdict, signed receipt, rule results, and metadata. Receipt: A cryptographically signed digest (HMAC-SHA256 or Ed25519) that binds the verification context to a signing key, providing tamper-evident audit. Config Hash: A SHA-256 digest of the canonical JSON representation of the verifier's configuration (rule set, policy version, signing key identifier). Binds the receipt to the exact policy under which verification occurred. Fail-closed: A property of the enforcement mechanism whereby any failure in the verification path -- exception, timeout, missing input, ambiguous state -- results in the tool invocation being blocked, not allowed. This is the opposite of fail-open (CWE-636). Conformance Shape: The complete set of fields, bindings, and semantic constraints that a CCS receipt MUST satisfy to be considered conformant at a given level.

A conforming CCS Receipt is a JSON object conforming to I-JSON . The receipt comprises 29 fields. Version 1.1 (ccs-verifier v1.1.0) includes all 29 fields with full Ed25519 signature coverage. Fields marked "Implemented" are present and operational in ccs-verifier v1.1.0.

The receipt field is computed over a signing payload. In v1.1 (ccs-verifier v1.1.0), Ed25519 is used with the following payload:

The Ed25519 signature is computed over UTF-8 encoding of this payload. The full 64-byte Ed25519 signature is included in the receipt field. Extended signing payload (for full AEC mapping with all 29 fields):

Critical property: The signed bytes cover the full verification context. Any change to any signed field invalidates the receipt.

The following is an example CCS receipt as produced by ccs-verifier v1.1.0 with all 29 fields populated and Ed25519 signature:

", "verified_at": 1722384000.123890, "block_reason": "", "request_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb924...", "response_hash": "", "runtime_context_hash": "sha256:7d865e959b2466918c180089...", "action": "ccs:tool-invoke:search_web:sha256:1234567890abcdef", "config_hash": "sha256:aabbccdd0011223344556677...", "issuer": "https://verifier.example.com/ccs/v1", "audience": "https://executor.example.com/aeb", "nonce": "f47ac10b58cc4372a5670e02b2c3d479", "sequence": 42, "issued_at": 1722384000.123000, "expires_at": 1722384060.123000, "max_clock_skew": 30.0, "rule_version": "1.1.0", "tool_call_id": "550e8400-e29b-41d4-a716-446655440000", "args_digest": "sha256:9f86d081884c7d659a2feaa0c55ad015..." } ]]>

Version 1.1 introduces three fields that extend the CCS Integrity dimension from "behavioral traceability" to "verifiable decision causality chains." These fields address two attack scenarios: Scenario 1: Legitimate chain masking garbage decisions. An attacker constructs a valid CCS receipt chain where each receipt passes cryptographic verification, but the underlying decision rules are systematically degraded. Without rule_version binding, the chain appears valid despite decisions being produced by different rules. Scenario 2: Silent-Drop (approval-execution decoupling). An attacker obtains a valid approval, silently drops the approved invocation, and substitutes a different invocation with different arguments. Without tool_call_id and args_digest, the executor cannot detect the swap. rule_version: A version identifier identifying the specific version of the decision rule set that produced this verdict. Enables detection of rule drift. tool_call_id: A UUID (RFC 4122) uniquely identifying a single tool invocation instance from dispatch. Creates an unbreakable link between the approval decision and the specific execution. The executor MUST verify that the tool_call_id in the CCS receipt matches the invocation being executed. args_digest: SHA-256 of the exact arguments passed to the tool at execution time (hex string). Distinct from params_hash: params_hash captures pre-verification parameters as seen by governance; args_digest captures post-approval execution-time arguments as seen by the executor. Divergence indicates argument modification between approval and execution. Signing requirement: All three fields MUST be included in the Ed25519 signature scope (see ). Backward compatibility: The three new fields are OPTIONAL for existing Level 0-2 implementations. Implementations targeting Level 3 or claiming v1.1 conformance MUST include all three fields.

A CCS Canonical Configuration is a JSON object that describes the exact state of the verifier at the time a receipt was issued. It MUST contain:

The canonical configuration MUST be serialized using JSON Canonicalization Scheme (JCS) as defined in :

bytes: """Serialize config to canonical JSON per RFC 8785 (JCS).""" return json.dumps( config, sort_keys=True, separators=(",", ":"), ensure_ascii=True, allow_nan=False ).encode("utf-8") ]]>

Key properties: keys sorted lexicographically, no whitespace between tokens (compact form), ASCII-only encoding, NaN and Infinity not permitted.

The config_hash is computed as:

The config_hash MUST be included in the extended signing payload () when the extended fields are in use.

This section defines the nine binding mechanisms that connect a CCS receipt to the various elements of the invocation lifecycle.

Purpose: Bind the receipt to the exact request bytes as received by the verifier.

bytes: return json.dumps({ "agent_id": command.agent_id, "tool": command.tool, "params": command.params, "timestamp": command.timestamp, "trace_id": command.trace_id, }, sort_keys=True, separators=(",", ":")).encode("utf-8") request_hash = "sha256:" + hashlib.sha256(canonical_bytes(command)).hexdigest() ]]>

Purpose: Bind the receipt to the exact response produced by the tool invocation.

Timing: Computed after tool invocation completes (post-hoc binding).

Purpose: Bind the receipt to the runtime execution environment.

Purpose: Provide a CAID-compatible action identifier.

The source media type is "application/x-ccs-receipt+json".

Purpose: Bind the receipt to the exact tool parameters.

str: return hashlib.sha256( json.dumps(params, sort_keys=True, separators=(",", ":")).encode() ).hexdigest()[:16] ]]>

Implementations targeting Level 2+ SHOULD use full SHA-256 digest.

Purpose: Identify the verifier that produced the receipt. The URI MUST be stable across key rotations and covered by the signature.

Purpose: Identify the intended consumer. A receipt whose audience does not match the consumer MUST be rejected.

Purpose: Prevent replay. The consumer MUST maintain a replay cache of seen (issuer, nonce) pairs. A previously-seen nonce MUST be rejected. The cache MUST persist across restarts.

Purpose: Bound the temporal validity of the receipt.

receipt.expires_at + skew: return False return True ]]>

Recommended expiry: issued_at + 60 seconds for tool-invocation governance.

HMAC-SHA256 (backward compatible): signing_key = secrets.token_bytes(32). The key MUST NOT be derived from predictable sources. Ed25519 (implemented in ccs-verifier v1.1.0):

HMAC: shared secret via secure channel. Ed25519: public key pinned via out-of-band mechanism.

Phased: Announce -> Dual-sign -> Cutover -> Retire. Overlap window MUST be at least 2x maximum receipt lifetime.

In-process: shared address space, signing key accessible. Out-of-process: separate process, signing key protected. Out-of-process is RECOMMENDED for security-critical applications.

CCS enforcement MUST be fail-closed. If the verifier raises an exception, times out, returns ambiguous result, or is unreachable, the tool invocation MUST be blocked.

This is the fundamental difference from observer-pattern hooks (which fail-open per ).

Verifier timeout: invocation MUST be blocked. Receipt timeout: expired receipts MUST be rejected. Both are independent and both MUST be enforced.

Note: P50/P99 latency figures are informational measurements, not normative requirements.

Built, operated, and audited by the relying party's own organization. Assurance: Highest.

Built by third party, independently audited. Assurance: High.

Operator claims conformance without independent audit. Assurance: Low.

Level 0 -- Baseline: Signed receipt covering trace_id, verdict, timestamp, tool, params_hash, rule_summary. Fail-closed implemented. Level 1 -- Extended Bindings (ccs-verifier v1.1.0): Adds request_hash, config_hash. Ed25519 signing. All 29 fields populated including v1.1 causal chain fields. 154 tests passed. Level 2 -- Full AEC Readiness: Adds response_hash, runtime_context_hash, action, issuer, audience, nonce, sequence, issued_at, expires_at, max_clock_skew. Level 3 -- Out-of-Process with Full Isolation: Separate process, key protection, distributed replay prevention.

CV-001: Basic ALLOW receipt (Level 0). CV-002: Basic DENY receipt. CV-003: Config hash binding (Level 1). CV-004: Request hash binding. CV-005: Issuer/audience binding (Level 2). CV-006: Freshness enforcement. ccs-verifier v1.1.0 passes 154 conformance tests across all levels.

Ten negative test cases: eight original plus two v1.1.

Attacker modifies tool parameters. params_hash mismatch detects it. Binding defeated if removed: params_hash binding ().

Attacker modifies tool response. response_hash mismatch detects it. Binding defeated if removed: response_hash binding ().

Attacker replays receipt. Nonce in replay cache detects it. Binding defeated if removed: nonce/sequence binding ().

Attacker presents old receipt. expires_at check detects it. Binding defeated if removed: freshness binding ().

Attacker redirects receipt. audience mismatch detects it. Binding defeated if removed: audience binding ().

Attacker forges receipt with own key. Issuer trust check detects it. Binding defeated if removed: issuer binding ().

Verifier always returns ALLOW. Statistical monitoring + Class B/A audit mitigates. Not a cryptographic attack.

Transport unavailable, runtime falls back to allow. Fail-closed semantics () MUST block the invocation.

Attacker replays receipt from old rule version. rule_version mismatch detects it. Binding defeated if removed: rule_version binding ().

Attacker substitutes invocation after approval. tool_call_id and args_digest mismatch detects it. Binding defeated if removed: tool_call_id and args_digest binding ().

Truncated hashes: params_hash truncated to 16 hex chars (64 bits) in 0.4.1 HMAC mode. Cross-deployment SHOULD use full-length. v1.1 Ed25519 mode uses full 64-byte signatures. HMAC key exposure in in-process mode: compromised agent can read signing key. Out-of-process mitigates this (Unix-socket and TCP/TLS implemented in v1.1.0). Float timestamp precision: IEEE 754 double provides ~15-17 significant digits. Implementations SHOULD use monotonic clocks for latency and wall clocks for issuance. JSON canonicalization: params_hash and config_hash depend on deterministic serialization per and . Rule evaluation ordering: DENY short-circuits, so rule_summary MAY differ. config_hash (Level 1+) binds to exact rule set. TOCTOU: runtime_context_hash (Level 2) mitigates environment change between verification and execution. Receipt chaining: not defined. Use sequence field () or external chaining. Causal chain integrity (v1.1): rule_version, tool_call_id, args_digest derive security from Ed25519 scope. Private key MUST be verifier-only. rule_version from canonical config. tool_call_id generated before approval. args_digest from exact execution bytes. params_hash vs args_digest: params_hash = pre-verification (governance view); args_digest = post-approval (executor view). Divergence for same tool_call_id indicates silent-drop attack ().

This document does not request any IANA allocations.

&RFC2119; &RFC7493; &RFC8174; &RFC8785; &I-D.schrock-action-evidence-boundary; &I-D.schrock-ep-authorization-receipts; Ericsson Fraunhofer SIT Nokia China Mobile IETF MITRE

Each conformance test vector is encoded as a JSON object: