Network Working Group G. Wang
Internet-Draft Correctover
Intended status: Experimental 26 August 2026
Expires: 27 February 2027
Correctover Conformance Shape (CCS): Runtime Verification for AI Agent
Tool Calls
draft-correctover-ccs-08
Abstract
This document defines the Correctover Conformance Shape (CCS), a
runtime verification framework for AI agent tool calls. CCS
specifies seven verification dimensions (Structure, Schema, Latency,
Cost, Identity, Integrity, Security) that tool calls and results must
conform to at runtime. The framework defines a receipt format with
Ed25519 signatures, three verdict values (allow, deny, escalate) and
four executor lifecycle states (confirmed, dispatched, indeterminate,
unknown), and normative requirements for implementations.
This revision promotes AEB and CAID to Normative References,
specifies the detached Ed25519 signature construction over RFC 8785
canonical JSON, clarifies receipt lifecycle and signing-algorithm
conformance, and documents two independent interoperable
implementations (Section 21).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang Expires 27 February 2027 [Page 1]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Protocol Stack Position . . . . . . . . . . . . . . . . . 5
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Changes from draft-02 . . . . . . . . . . . . . . . . . . 7
1.4. Changes from draft-03 . . . . . . . . . . . . . . . . . . 8
1.5. Changes from draft-04 . . . . . . . . . . . . . . . . . . 8
1.6. Changes from draft-05 . . . . . . . . . . . . . . . . . . 9
1.7. Relationship to CCS Formal Framework (DOI References) . . 10
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Evidence Intake Protocol . . . . . . . . . . . . . . . . . . 12
3.1. Intake Interface . . . . . . . . . . . . . . . . . . . . 13
3.2. Request Normalization . . . . . . . . . . . . . . . . . . 14
3.3. Intake Fail-Closed Semantics . . . . . . . . . . . . . . 15
3.4. Intake Error Responses . . . . . . . . . . . . . . . . . 16
4. CCS Receipt Schema . . . . . . . . . . . . . . . . . . . . . 17
4.1. Field Definitions . . . . . . . . . . . . . . . . . . . . 17
4.2. Signed Bytes . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Receipt JSON Example . . . . . . . . . . . . . . . . . . 22
4.4. Verifier Policy Floor . . . . . . . . . . . . . . . . . . 23
4.5. Verification Outcome States . . . . . . . . . . . . . . . 23
4.5.1. Scope-Comparison Axis . . . . . . . . . . . . . . . . 24
4.5.2. Evidence Completeness (Third Axis) . . . . . . . . . 25
4.6. Verifier Capability Manifest . . . . . . . . . . . . . . 26
4.7. Challenge Loop . . . . . . . . . . . . . . . . . . . . . 27
4.7.1. Substance vs. Form . . . . . . . . . . . . . . . . . 28
4.7.2. Evidence Stack Alignment . . . . . . . . . . . . . . 28
4.7.3. No Disposition Authorises an Action . . . . . . . . . 29
4.8. Structural Test Discipline . . . . . . . . . . . . . . . 30
5. Canonical Configuration . . . . . . . . . . . . . . . . . . . 30
5.1. Canonical Config Fields . . . . . . . . . . . . . . . . . 30
5.2. Canonicalization Algorithm . . . . . . . . . . . . . . . 32
5.3. Config Hash . . . . . . . . . . . . . . . . . . . . . . . 32
6. Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. request_hash Binding . . . . . . . . . . . . . . . . . . 33
6.2. response_hash Binding . . . . . . . . . . . . . . . . . . 33
6.3. runtime_context_hash Binding . . . . . . . . . . . . . . 34
6.4. action Binding . . . . . . . . . . . . . . . . . . . . . 34
Wang Expires 27 February 2027 [Page 2]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
6.5. params_hash Binding . . . . . . . . . . . . . . . . . . . 34
6.6. issuer Binding . . . . . . . . . . . . . . . . . . . . . 35
6.7. audience Binding . . . . . . . . . . . . . . . . . . . . 35
6.8. nonce/sequence Binding . . . . . . . . . . . . . . . . . 35
6.9. freshness Binding (issued_at + expires_at +
max_clock_skew) . . . . . . . . . . . . . . . . . . . . 36
6.10. Receipt Time-Binding . . . . . . . . . . . . . . . . . . 36
7. Key Management . . . . . . . . . . . . . . . . . . . . . . . 37
7.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 37
7.2. Key Enrollment . . . . . . . . . . . . . . . . . . . . . 37
7.3. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 37
7.4. Verifier-Operator Separation . . . . . . . . . . . . . . 38
8. Transport Requirements . . . . . . . . . . . . . . . . . . . 38
8.1. Fail-Closed Semantics . . . . . . . . . . . . . . . . . . 38
8.2. Timeout Behavior . . . . . . . . . . . . . . . . . . . . 39
8.3. In-Process vs Out-of-Process Deployment . . . . . . . . . 39
9. Verifier Source Classification . . . . . . . . . . . . . . . 40
9.1. Class A: Self-Built Verifier . . . . . . . . . . . . . . 40
9.2. Class B: Audited Verifier . . . . . . . . . . . . . . . . 40
9.3. Class C: Self-Declared Verifier . . . . . . . . . . . . . 41
10. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 41
10.1. Level 0-3 Definitions . . . . . . . . . . . . . . . . . 41
10.2. Level 4: Evidence Propagation . . . . . . . . . . . . . 42
10.3. Conformance Vectors . . . . . . . . . . . . . . . . . . 42
11. Evidence Propagation . . . . . . . . . . . . . . . . . . . . 43
11.1. Single-Agent Propagation . . . . . . . . . . . . . . . . 43
11.1.1. Zero-Hop Chain Semantics . . . . . . . . . . . . . . 44
11.2. Multi-Agent Chain Propagation . . . . . . . . . . . . . 45
11.3. Cross-Organization Propagation . . . . . . . . . . . . . 46
11.4. Evidence Accumulation . . . . . . . . . . . . . . . . . 47
11.5. Chain Integrity Verification . . . . . . . . . . . . . . 47
12. Enforcement Interface . . . . . . . . . . . . . . . . . . . . 48
12.1. Enforcement Input Contract . . . . . . . . . . . . . . . 48
12.2. Receipt Validation Protocol . . . . . . . . . . . . . . 49
12.3. Verification Failure Signaling . . . . . . . . . . . . . 50
12.4. Outcome Status Mapping . . . . . . . . . . . . . . . . . 51
12.5. One Test, Stated Once . . . . . . . . . . . . . . . . . 52
13. Negative Test Cases . . . . . . . . . . . . . . . . . . . . . 53
13.1. Changed Arguments . . . . . . . . . . . . . . . . . . . 53
13.2. Changed Response . . . . . . . . . . . . . . . . . . . . 53
13.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.4. Stale Evidence . . . . . . . . . . . . . . . . . . . . . 54
13.5. Wrong Audience . . . . . . . . . . . . . . . . . . . . . 54
13.6. Key Substitution . . . . . . . . . . . . . . . . . . . . 55
13.7. Verifier/Runtime Collusion . . . . . . . . . . . . . . . 55
13.8. Missing Transport . . . . . . . . . . . . . . . . . . . 56
13.9. Intake Fail-Closed Bypass . . . . . . . . . . . . . . . 56
13.10. Chain Tampering . . . . . . . . . . . . . . . . . . . . 56
Wang Expires 27 February 2027 [Page 3]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
13.11. Cross-Org Missing Self-Verification . . . . . . . . . . 57
14. Security Considerations . . . . . . . . . . . . . . . . . . . 57
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
16. CCS v1.3 Receipt Field Summary Table . . . . . . . . . . . . 59
17. Mapping to draft-feng-agentproto-session-requirements-01 . . 60
17.1. REQ-5: Verifiable Authorization Binding . . . . . . . . 61
17.2. REQ-7: Action Evidence Non-Repudiation . . . . . . . . . 61
17.3. Out-of-Scope Items . . . . . . . . . . . . . . . . . . . 61
18. Mapping to AUDIT BOF / W3C PROV . . . . . . . . . . . . . . . 62
18.1. Field Mapping . . . . . . . . . . . . . . . . . . . . . 62
18.2. Positioning . . . . . . . . . . . . . . . . . . . . . . 63
19. Trigger/Scope Audit of the 16 Security Rules . . . . . . . . 63
19.1. Input Rules . . . . . . . . . . . . . . . . . . . . . . 63
19.2. Output Rules . . . . . . . . . . . . . . . . . . . . . . 64
19.3. Audit Notes . . . . . . . . . . . . . . . . . . . . . . 65
20. Implementation Notes . . . . . . . . . . . . . . . . . . . . 65
20.1. dsh-ccs-security (DeepSeek Harness Plugin) . . . . . . . 66
20.2. correctover-mcp-gateway . . . . . . . . . . . . . . . . 66
20.3. Lessons . . . . . . . . . . . . . . . . . . . . . . . . 66
20.4. Watchdog Interruption and Outcome=Unknown . . . . . . . 67
20.5. EMILIA Protocol Independent Interoperability Profile . . 67
21. Conformance Test Vector Format . . . . . . . . . . . . . . . 68
22. Normative References . . . . . . . . . . . . . . . . . . . . 70
23. Informative References . . . . . . . . . . . . . . . . . . . 71
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 71
1. Introduction
The Correctover Conformance Shape (CCS) defines the evidence protocol
for the agent runtime protocol stack. It produces a single, tamper-
evident, cryptographically bound artifact -- a CCS Receipt -- 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 not a policy language, an authorization framework, or a
transport protocol. It is the evidence that a verifier produces when
it finishes evaluating a command, together with the protocols for how
that evidence enters the system, propagates across boundaries, and is
delivered to enforcement consumers.
The initial reference implementation (ccs-verifier 0.4.1) provides an
in-process verifier with HMAC-SHA256 receipt signing covering the
verification context (trace_id, verdict, timestamp, tool,
params_hash, rule_summary). This document specifies extensions to
that baseline to cover the full set of bindings that
Wang Expires 27 February 2027 [Page 4]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
[I-D.schrock-action-evidence-boundary] Section 5.2 requires from a
native artifact: request binding, response binding, runtime context
binding, issuer/audience, freshness, nonce, and canonical
configuration. It further defines the Evidence Intake Protocol,
Evidence Propagation mechanisms, and the Enforcement Interface.
This document is published as an Experimental protocol. Two
independent interoperable implementations are documented in
Section 21. The proposals herein are offered for review and
refinement through the standard IETF process. The author welcomes
feedback on all aspects of this specification, including the protocol
architecture, evidence chain structure, and integration points with
existing and emerging agent protocols.
1.1. Protocol Stack Position
CCS occupies a defined position in the agent runtime protocol stack:
+===========+================+======================================+
|Layer |Responsibility | Specification |
+===========+================+======================================+
|Transport |Message routing | MCP, A2A |
|(MCP/A2A) |and | |
| |serialization | |
| |between agents | |
| |and tools | |
+-----------+----------------+--------------------------------------+
|Evidence |Evidence | This document |
|Protocol |generation, | |
|(CCS) |standardization,| |
| |propagation, | |
| |delivery | |
+-----------+----------------+--------------------------------------+
|Enforcement|Policy decision | AEB [I-D.schrock-action-evidence- |
|(AEB) |consumption and | boundary] |
| |action gating | |
+-----------+----------------+--------------------------------------+
|Tool |Actual tool | Tool-specific |
|Execution |invocation and | |
| |outcome | |
| |reporting | |
+-----------+----------------+--------------------------------------+
Table 1: Protocol Stack Position
CCS is responsible for:
Wang Expires 27 February 2027 [Page 5]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
* Evidence generation: creating tamper-evident receipts from
verification decisions.
* Evidence standardization: defining schemas, bindings, and
canonicalization rules.
* Evidence propagation: ensuring evidence integrity across multi-
agent chains and organizational boundaries.
* Evidence delivery: providing standardized interfaces for
enforcement consumers to validate and consume evidence.
CCS is NOT responsible for:
* Transport message routing (MCP/A2A layer).
* Policy decisions or enforcement logic (AEB layer).
* Identity handshakes or authentication (identity layer).
1.2. Scope
CCS specifies:
* An Evidence Intake Protocol (Section 3) that governs how evidence
legally enters the CCS system.
* A receipt schema (Section 4) that binds a verdict to the exact
invocation context.
* A canonical configuration model (Section 5) that binds the receipt
to the exact rule set and policy under which verification
occurred.
* Nine binding mechanisms (Section 6) 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 (Section 7).
* Transport requirements (Section 8) including fail-closed
semantics.
* Verifier source classification (Section 9).
* Conformance levels and test vectors (Section 10), including Level
4 (Evidence Propagation).
Wang Expires 27 February 2027 [Page 6]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
* Evidence Propagation across multi-agent chains and organizational
boundaries (Section 11).
* The Enforcement Interface for standardized evidence consumption
(Section 12).
* Negative test cases (Section 13), extended for propagation and
enforcement scenarios.
CCS does NOT define:
* A new authorization receipt format that replaces or competes with
. CCS is a
verifier-side evidence 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.
* A universal evidence taxonomy. CCS defines one artifact shape for
one class of decision (tool-invocation governance).
* Enforcement policy decisions. CCS delivers evidence; it does not
decide what to do with it.
1.3. Changes from draft-02
This document (draft-03) introduces the following changes from draft-
02:
* Title changed from "A Receipt and Binding Specification" to "An
Evidence Protocol Specification" to reflect the protocol stack
positioning.
* Terminology refinement: "Accumulated Evidence Chain (AEC)" renamed
to "Evidence Chain (EC)" to avoid abbreviation collision with
concurrent IETF work. "Evidence Layer" references softened to
"evidence protocol" throughout.
* New Section 3: Evidence Intake Protocol.
* New Section 11: Evidence Propagation.
* New Section 12: Enforcement Interface.
* New conformance Level 4: Evidence Propagation (Section 10.2).
Wang Expires 27 February 2027 [Page 7]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
* New negative test cases (Section 13.9-13.11).
* Extended Security Considerations (Section 14).
* All existing sections renumbered accordingly.
1.4. Changes from draft-03
This draft (draft-04) introduces the following changes from draft-03:
This draft adds three mechanisms to address IETF discussion feedback:
1. UNDECIDED with reason codes on the scope-comparison axis
(Section 4.5.1). UNDECIDED is a per-comparison result, not a new
top-level verdict.
2. Verifier Capability Manifest (Section 4.6). A signed, versioned
declaration of which profiles a verifier can evaluate, used for
routing when UNDECIDED(PROFILE_NOT_HELD) is returned.
3. Challenge Loop for Evidence Completeness (Section 4.7). The
third axis is implemented as fail-closed refusal + structured
challenge, not as a new verdict token. Deadline uses derivation
(multiplier x expected_response_duration), following OSPF/BGP
convention.
4. Reachable-Set Exhaustion Report (Section 4.5.1). When a relying
party consults multiple verifiers and receives PROFILE_NOT_HELD
from all reachable verifiers, the result is a terminal state
(SET_EXHAUSTED) with a trace of which verifiers were consulted.
5. Manifest Profiles Digest (Section 4.6). The manifest includes a
profiles_digest (SHA-256 of the canonical profiles array) that is
hash-bound in the receipt.
1.5. Changes from draft-04
This draft (draft-05) introduces the following changes from draft-04,
addressing IETF mailing list discussion feedback from agent2agent and
SCITT WG threads (August 2026):
1. Substance vs. Form distinction (Section 4.7.1): A verifier's
internal implementation details are substance and are out of
scope for wire interoperability. The receipt fields required
for another verifier to independently reproduce the result are
form and are normative.
Wang Expires 27 February 2027 [Page 8]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
2. CCS to draft-feng-agentproto-session-requirements-01 requirement
mapping (Section 18): Explicit mapping table showing how CCS
receipts satisfy REQ-5 and REQ-7.
3. AUDIT BOF receipt mapping (Section 19): Mapping of CCS receipt
fields to the W3C PROV data model.
4. Evidence stack alignment (Section 4.7.2): Clarification that the
CCS receipt occupies the evidence layer between transport
attestations and enforcement decisions.
5. No disposition authorises an action (Section 4.7.3): Explicit
normative statement that all verification outcome states are
evidence statements, NOT authorization.
6. Trigger/scope double-position audit (Section 4.8 and
Section 20): Every conformance rule in the 16-rule security set
is expressed as a structural existence test.
7. One test, stated once (Section 12.5): L1 receipt validation and
runtime enforcement reference the same set of structural tests.
8. Zero-hop chain semantics (Section 11.1.1): When delegation chain
length is zero, the CCS receipt's own issuance event serves as
the root of trust.
9. Shipped implementation notes (Section 21): dsh-ccs-security and
correctover-mcp-gateway.
10. Unknown outcome state (Section 4.5): A fourth outcome_status
value, "unknown", for interrupted execution.
1.6. Changes from draft-05
This draft (draft-06) introduces the following changes from draft-05,
addressing interoperability verification and IETF list discussion
feedback:
1. Intended status changed from Informational to Experimental. Two
independent interoperable implementations exist (Section 21).
2. AEB and CAID promoted to Normative References (Section 16.1).
3. Detached Ed25519 signature construction specified normatively
(Section 4.2).
4. Receipt lifecycle clarified (Sections 4.2, 6.2, 11).
Wang Expires 27 February 2027 [Page 9]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
5. Signing algorithm conformance clarified (Sections 4.1, 4.2, 7).
6. Python canonicalization examples corrected to produce RFC 8785
compliant output (ensure_ascii=False).
7. Implementation report added (Section 21).
8. Authorization Receipts remains Informative (Section 16.2).
1.7. Relationship to CCS Formal Framework (DOI References)
This Internet-Draft is a protocol specification derived from and
complementary to the following academic publications:
* DOI: 10.5281/zenodo.21271910 -- "CCS Formal Framework." This
paper defines the mathematical foundation: the Required(T) subset
of Supported(T) conformance criterion.
* 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.
* DOI: 10.5281/zenodo.21234580 -- "CCS Standard v1.0." The
overarching standard that defines the three pillars and the seven-
dimensional verification model.
* DOI: 10.5281/zenodo.21783723 -- "CCS 7-Dimensional Framework
Three-Endpoint Closed Loop." Contains: IETF Internet-Draft +
Zenodo DOI + PyPI ccs-verifier v1.1.0.
2. Terminology
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 [RFC2119] [RFC8174] 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
Wang Expires 27 February 2027 [Page 10]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
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 truncated HMAC-SHA256 (or Ed25519, per Section 7) digest
that binds the verification context to a shared secret or 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.
Outcome status The epistemic state of a verification result
regarding the action's outcome. One of: confirmed, dispatched,
indeterminate, unknown. Orthogonal to the verdict (allow/deny/
escalate). "unknown" indicates that the invocation was recorded
but execution was interrupted (process crash, watchdog restart,
hot-reload) before a result was durably persisted.
Verifier policy floor The minimum security requirements enforced by
a CCS verifier, regardless of the server's self-declared profile.
Non-negotiable from the server side.
Reconcilability The property of an action whereby the effecting side
can attest to what actually occurred after execution. Independent
from severity.
Evidence Intake The process by which an agent runtime submits tool
Wang Expires 27 February 2027 [Page 11]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
invocation data to the CCS layer for evidence generation. The
intake is the controlled entry point for all evidence entering the
CCS system.
Evidence Envelope A wrapper structure that carries a CCS receipt
plus chain metadata for propagation across agent boundaries. The
envelope preserves the original receipt and adds propagation
context.
Evidence Chain (EC) An ordered list of CCS receipts linked by chain
integrity hashes. Each receipt in the chain cryptographically
references its predecessor.
Chain Integrity The property that each receipt in a chain
cryptographically references its predecessor via a receipt_hash
linkage, preventing insertion, removal, or modification of chain
members.
Enforcement Consumer A system that validates CCS evidence and maps
it to enforcement decisions. The AEB is a canonical enforcement
consumer.
Intake Fail-Closed The property that any failure in evidence intake
results in no receipt being produced and a denial of the tool
invocation. The system MUST NOT fall back to fail-open behavior.
Cross-Organization Evidence Evidence that propagates across
organizational boundaries, requiring self-contained verification
data so that the receiving organization can validate the evidence
without external lookups.
Summary Hash A single cryptographic hash that represents the entire
Evidence Chain, computed over all receipt hashes in insertion
order.
Contributors: The distinction between evidence sufficiency and
executor lifecycle was developed through discussion with Iman Schrock
(AEB-03) and Blake Morrison (CAE 3.3/3.4, executor lifecycle, B3-y).
3. Evidence Intake Protocol
This section defines how evidence legally enters the CCS system. The
Evidence Intake Protocol establishes "entry sovereignty" -- the right
of the CCS evidence protocol to control what constitutes valid input.
All evidence in the CCS system originates through this protocol;
there is no other path.
Wang Expires 27 February 2027 [Page 12]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
3.1. Intake Interface
The intake interface is the standard interface through which agent
runtimes submit tool invocation data for evidence generation.
Input contract:
The Command object submitted to the intake interface MUST contain the
following fields:
{
"intake_version": "1.3",
"agent_id": "agent-001",
"tool": "search_web",
"params": {"query": "weather in Tokyo"},
"timestamp": 1722384000.0,
"trace_id": "a1b2c3d4e5f67890"
}
Required fields:
* intake_version: The CCS schema version. MUST be "1.3" for this
specification.
* agent_id: Identifier of the invoking agent.
* tool: Name of the tool being invoked.
* params: Structured parameters for the tool invocation.
* timestamp: Unix timestamp of the invocation request.
* trace_id: Unique identifier for this verification event.
Optional fields:
* runtime_context: JSON object containing caller_identity, tenant,
environment, and other execution environment fields.
* delegation_chain: If this invocation is part of a multi-agent
delegation, the parent receipt information.
Synchronicity requirements:
* For in-process deployment, intake MUST be synchronous: the caller
blocks until the intake completes or fails.
Wang Expires 27 February 2027 [Page 13]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
* For out-of-process deployment, intake MAY be asynchronous, but the
caller MUST block until a receipt or error response is received
before proceeding with the tool invocation.
Versioning:
The intake_version field ensures that the verifier and the caller
agree on the expected field set and normalization rules. If the
verifier receives an intake_version it does not support, it MUST
return an INTAKE_MALFORMED error (Section 3.4).
3.2. Request Normalization
Before evidence generation, the intake interface normalizes the
incoming request to ensure deterministic processing.
JSON canonicalization: The params field MUST be serialized using JSON
Canonicalization Scheme (JCS) as defined in [RFC8785]:
def canonical_params(params: dict) -> bytes:
return json.dumps(
params,
sort_keys=True,
separators=(",", ":"),
ensure_ascii=False,
allow_nan=False
).encode("utf-8")
Note: The Python snippet above uses ensure_ascii=False so that non-
ASCII characters are emitted as their UTF-8 encoding, matching the
normative RFC 8785 JCS output. Earlier revisions used
ensure_ascii=True, which produced \uXXXX escapes for non-ASCII code
points and therefore different signed bytes. Implementations MUST
treat RFC 8785 JCS output as the canonical byte sequence; language-
specific convenience serializers that deviate from JCS (including
default ascii escaping) are not compliant.
Unicode normalization: All string fields in the Command MUST be
normalized to Unicode Normalization Form C (NFC) before processing.
Timestamp normalization: All timestamps MUST be converted to UTC
before processing. Implementations MUST reject timestamps with
timezone offsets other than UTC.
Binary data handling: Any binary data in the params MUST be encoded
as base64 (standard encoding, with padding) before canonicalization.
Maximum input size:
Wang Expires 27 February 2027 [Page 14]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
The intake interface MUST enforce the following size limits:
+==========================+===========+=======================+
| Component | Max Size | Behavior on Overflow |
+==========================+===========+=======================+
| params (canonical bytes) | 64 KB | INTAKE_OVERFLOW error |
+--------------------------+-----------+-----------------------+
| tool name | 256 bytes | INTAKE_OVERFLOW error |
+--------------------------+-----------+-----------------------+
| agent_id | 512 bytes | INTAKE_OVERFLOW error |
+--------------------------+-----------+-----------------------+
| runtime_context | 16 KB | INTAKE_OVERFLOW error |
+--------------------------+-----------+-----------------------+
| total intake message | 128 KB | INTAKE_OVERFLOW error |
+--------------------------+-----------+-----------------------+
Table 2: Figure 2
3.3. Intake Fail-Closed Semantics
The intake protocol enforces fail-closed semantics at the entry
point. If intake fails for ANY reason, the system MUST NOT produce a
receipt and the caller MUST treat this as a denial.
Failure conditions:
* Malformed input: The intake message is not valid JSON, or required
fields are missing, or field types are incorrect.
* Normalization failure: The params contain values that cannot be
canonicalized (e.g., NaN, Infinity, circular references).
* Size overflow: Any component exceeds its maximum size limit.
* Timeout: The intake processing does not complete within the
configured timeout.
* Version mismatch: The intake_version is not supported.
Invariant: Under no circumstances MAY the system fall back to fail-
open behavior. If the verifier cannot process the intake, the tool
invocation MUST be blocked. This is the fundamental security
guarantee of the CCS evidence protocol: no evidence, no execution.
The fail-closed invariant is enforced at the intake boundary:
Wang Expires 27 February 2027 [Page 15]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
def intake(command: Command) -> Union[Receipt, IntakeError]:
try:
normalized = normalize(command)
if not validate(normalized):
return IntakeError("INTAKE_MALFORMED")
receipt = generate_receipt(normalized)
return receipt
except Exception:
return IntakeError("INTAKE_FAILED")
Any exception in the intake path produces an IntakeError, which the
caller MUST treat as a denial.
3.4. Intake Error Responses
When intake fails, the verifier returns a structured error response.
Error response format:
{
"error_code": "INTAKE_MALFORMED",
"error_message": "Required field 'tool' is missing",
"retry_after": null,
"trace_id": "a1b2c3d4e5f67890"
}
Error taxonomy:
+============================+=======+=============================+
| Error Code | Retry | Description |
+============================+=======+=============================+
| INTAKE_MALFORMED | MAY | Input is not valid JSON, or |
| | | field types are incorrect. |
+----------------------------+-------+-----------------------------+
| INTAKE_MISSING_FIELD | MAY | A required field is absent. |
+----------------------------+-------+-----------------------------+
| INTAKE_OVERFLOW | MUST | A component exceeds its |
| | NOT | size limit. |
+----------------------------+-------+-----------------------------+
| INTAKE_TIMEOUT | MAY | Processing exceeded the |
| | | timeout. |
+----------------------------+-------+-----------------------------+
| INTAKE_VERSION_UNSUPPORTED | MUST | The intake_version is not |
| | NOT | supported. |
+----------------------------+-------+-----------------------------+
Table 3: Figure 3
Wang Expires 27 February 2027 [Page 16]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
Security requirements for error responses:
* Error responses MUST NOT leak internal implementation details
(stack traces, internal paths, key identifiers).
* Error responses MUST be structurally distinguishable from valid
receipts. An error response MUST NOT contain a receipt field, and
a receipt MUST NOT contain an error_code field.
* The trace_id in the error response (if available) allows
correlation with the original intake attempt.
4. CCS Receipt Schema
4.1. Field Definitions
A conforming CCS Receipt is a JSON object conforming to I-JSON
[RFC7493]. The following table defines each field. All 22 fields
are implemented in ccs-verifier 0.4.1.
+====================+=========+===========+===========+=================+
|Field |Type |Status |Required |Description |
+====================+=========+===========+===========+=================+
|trace_id |string |Implemented|MUST |SHA-256 of |
| |(16-hex) | | |time.time_ns(), |
| | | | |truncated to 16 |
| | | | |hex chars. |
| | | | |Uniquely |
| | | | |identifies this |
| | | | |verification |
| | | | |event. |
+--------------------+---------+-----------+-----------+-----------------+
|verdict |string |Implemented|MUST |One of: "allow", |
| |(enum) | | |"deny", |
| | | | |"escalate". |
+--------------------+---------+-----------+-----------+-----------------+
|timestamp |float |Implemented|MUST |Unix timestamp at|
| | | | |which the verdict|
| | | | |was finalized. |
+--------------------+---------+-----------+-----------+-----------------+
|tool |string |Implemented|MUST |The tool name |
| | | | |from the Command.|
+--------------------+---------+-----------+-----------+-----------------+
|params_hash |string |Implemented|MUST |SHA-256 of |
| |(16-hex) | | |canonical JSON of|
| | | | |Command.params, |
| | | | |truncated to 16 |
| | | | |hex chars. |
Wang Expires 27 February 2027 [Page 17]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
+--------------------+---------+-----------+-----------+-----------------+
|rule_summary |string |Implemented|MUST |Pipe-delimited |
| | | | |list of |
| | | | |rule_name=verdict|
| | | | |pairs. |
+--------------------+---------+-----------+-----------+-----------------+
|receipt |string |Implemented|MUST |HMAC-SHA256 over |
| |(32-hex) | | |signed bytes |
| | | | |(Section 4.2), |
| | | | |truncated to 32 |
| | | | |hex chars. |
+--------------------+---------+-----------+-----------+-----------------+
|verified_at |float |Implemented|MUST |Unix timestamp of|
| | | | |verification. |
+--------------------+---------+-----------+-----------+-----------------+
|block_reason |string |Implemented|Conditional|Human-readable |
| | | | |reason for deny/ |
| | | | |escalate. MUST |
| | | | |be empty for |
| | | | |allow. |
+--------------------+---------+-----------+-----------+-----------------+
|request_hash |string |Implemented|MUST |SHA-256 of the |
| |(hex) | | |canonical bytes |
| | | | |of the original |
| | | | |request |
| | | | |(Section 6.1). |
+--------------------+---------+-----------+-----------+-----------------+
|response_hash |string |Implemented|SHOULD |SHA-256 of the |
| |(hex) | | |tool response |
| | | | |bytes |
| | | | |(Section 6.2). |
+--------------------+---------+-----------+-----------+-----------------+
|runtime_context_hash|string |Implemented|SHOULD |SHA-256 of |
| |(hex) | | |canonical JSON of|
| | | | |runtime context |
| | | | |(Section 6.3). |
+--------------------+---------+-----------+-----------+-----------------+
|action |string |Implemented|MUST |CAID-compatible |
| | | | |action ident. 14 |
| | | | |enum values |
| | | | |(Section 6.4). |
+--------------------+---------+-----------+-----------+-----------------+
|config_hash |string |Implemented|MUST |SHA-256 of the |
| |(hex) | | |canonical config |
| | | | |(Section 5). |
+--------------------+---------+-----------+-----------+-----------------+
|issuer |string |Implemented|MUST |Verifier URI |
| |(URI) | | |(Section 6.6). |
Wang Expires 27 February 2027 [Page 18]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
+--------------------+---------+-----------+-----------+-----------------+
|audience |string |Implemented|MUST |Intended consumer|
| |(URI) | | |URI |
| | | | |(Section 6.7). |
+--------------------+---------+-----------+-----------+-----------------+
|nonce |string |Implemented|MUST |Single-use value |
| |(hex) | | |for replay |
| | | | |prevention |
| | | | |(Section 6.8). |
+--------------------+---------+-----------+-----------+-----------------+
|sequence |integer |Implemented|SHOULD |Monotonically |
| | | | |increasing |
| | | | |counter |
| | | | |(Section 6.8). |
+--------------------+---------+-----------+-----------+-----------------+
|issued_at |float |Implemented|MUST |Receipt issue |
| | | | |timestamp |
| | | | |(Section 6.9). |
+--------------------+---------+-----------+-----------+-----------------+
|expires_at |float |Implemented|MUST |Receipt expiry |
| | | | |timestamp |
| | | | |(Section 6.9). |
+--------------------+---------+-----------+-----------+-----------------+
|max_clock_skew |float |Implemented|SHOULD |Max clock skew in|
| | | | |seconds. |
| | | | |Default: 30.0. |
+--------------------+---------+-----------+-----------+-----------------+
|signature |string |Implemented|MUST |Ed25519 signature|
| |(128-hex)| | |over RFC 8785 |
| | | | |canonical JSON of|
| | | | |fields 1-21; |
| | | | |Ed25519-only for |
| | | | |v1.3. |
+--------------------+---------+-----------+-----------+-----------------+
Table 4: Figure 4
4.2. Signed Bytes
The receipt field in the 0.4.1 reference implementation is computed
by the sign_receipt function as follows:
Signing payload construction (0.4.1, Implemented):
payload = "{trace_id}:{verdict}:{timestamp}:{tool}:{params_hash}:{rule_summary}"
Wang Expires 27 February 2027 [Page 19]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
Each field is interpolated using its string representation. The
timestamp is the Python float from time.time(). The payload is then
encoded as UTF-8.
Algorithm (0.4.1, Implemented):
receipt = HMAC-SHA256(secret, payload.encode("utf-8")).hexdigest()[:32]
Where secret is a 32-byte key (generated via secrets.token_bytes(32)
if not provided). The output is truncated to the first 32
hexadecimal characters of the full 64-character hex digest.
Extended signing payload (Implemented, for EC mapping): When the
extended fields (Section 4.1) are present, the signing payload MUST
be extended to include them:
extended_payload = "{trace_id}:{verdict}:{timestamp}:{tool}:{params_hash}:{rule_summary}:{request_hash}:{response_hash}:{runtime_context_hash}:{action}:{config_hash}:{issuer}:{audience}:{nonce}:{sequence}:{issued_at}:{expires_at}"
Signing algorithm conformance (Normative):
The 22-field v1.3 receipt (Level 1 and above) uses Ed25519
exclusively for field 22. The field contains 128 lowercase
hexadecimal characters (64-byte Ed25519 signature). HMAC-SHA256
truncation (32 hex chars) applies only to the legacy 7-field Level 0
receipt (field 7); it MUST NOT be used in field 22 of a v1.3 receipt.
Detached Ed25519 signature construction (Normative):
The signature field (field 22) is a detached Ed25519 signature
computed as follows:
1. Construct a JSON object containing receipt fields 1-21, excluding
field 22 itself.
2. Apply RFC 8785 JSON Canonicalization Scheme (JCS) to produce the
canonical byte sequence. All non-ASCII characters are emitted as
UTF-8 per JCS; implementations MUST NOT apply ASCII-only
escaping.
3. Sign the canonical bytes using the Ed25519 private key
corresponding to the issuer's published public key.
4. Encode the signature as 128 lowercase hexadecimal characters (64
bytes).
Wang Expires 27 February 2027 [Page 20]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
The signature is detached: field 22 is not included in its own signed
bytes. A verifier MUST reconstruct the canonical JSON from fields
1-21 (excluding field 22), apply RFC 8785, and verify the Ed25519
signature over those bytes. Any field not included in the canonical
JSON is not covered by the signature.
This construction was validated by an independent implementation
(Section 21.5) which achieved 14/14 conformance checks using this
exact signing procedure.
Receipt lifecycle (Normative):
The 22-field v1.3 receipt is a post-execution evidence record. It is
finalized after the tool invocation completes and response_hash
(field 12) is computed. The durability requirement in Section 11
applies in two phases:
(a) Pre-execution: the admission decision (verdict, trace_id,
timestamp, tool, params_hash, rule_summary, request_hash,
config_hash, action, issuer, audience, nonce, issued_at, and policy
context) MUST be durably persisted before enforcement permits the
invocation to proceed. A crash between admission and execution MUST
leave an auditable admission record.
(b) Post-execution: after the tool returns, the verifier (or a post-
invocation hook) computes response_hash, determines outcome_status,
and finalizes the 22-field receipt with field 22. The final receipt
is the durable post-execution evidence artifact. If execution is
interrupted before response_hash can be computed, the record remains
open with outcome_status=unknown (Section 4.5) and is finalized when
outcome is determined or explicitly resolved.
A deny verdict does not require execution: the receipt is finalized
at admission time with an empty response_hash and
outcome_status=confirmed (the denial itself is the confirmed
outcome). An allow verdict requires post-execution finalization;
until finalized it has outcome_status=dispatched.
This two-phase model resolves the apparent contradiction between the
pre-invocation durability requirement and the post-hoc nature of
response_hash: they apply to different stages of the same evidence
record, identified by a common trace_id.
Critical property: The signed bytes cover the full verification
context. Any change to any signed field -- the tool name, the
parameters, the verdict, the timestamp, the rule summary --
invalidates the receipt. This is what makes the receipt tamper-
evident.
Wang Expires 27 February 2027 [Page 21]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
4.3. Receipt JSON Example
The following is an example CCS receipt as produced by ccs-verifier
0.4.1 (core fields):
{
"trace_id": "a1b2c3d4e5f67890",
"verdict": "deny",
"timestamp": 1722384000.123456,
"tool": "shell_exec",
"params_hash": "f9e8d7c6b5a43210",
"rule_summary": "ssrf_protection=allow|rce_protection=deny",
"receipt": "0123456789abcdef0123456789abcdef",
"verified_at": 1722384000.123890,
"block_reason": "RCE pattern detected"
}
The following example shows the full receipt with all 22 fields:
{
"trace_id": "a1b2c3d4e5f67890",
"verdict": "allow",
"timestamp": 1722384000.123456,
"tool": "search_web",
"params_hash": "1234567890abcdef",
"rule_summary": "ssrf_protection=allow|rce_protection=allow",
"receipt": "fedcba9876543210fedcba9876543210",
"verified_at": 1722384000.123890,
"block_reason": "",
"request_hash": "sha256:e3b0c44298fc1c14...",
"response_hash": "",
"runtime_context_hash": "sha256:7d865e959b246691...",
"action": "ccs:tool-invoke:search_web:sha256:1234567890abcdef",
"config_hash": "sha256:aabbccdd0011223344...",
"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,
"signature": "a1b2c3d4e5f6..."
}
Wang Expires 27 February 2027 [Page 22]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
4.4. Verifier Policy Floor
A conforming CCS verifier enforces a non-negotiable policy floor.
When a server or tool endpoint declares a security profile that is
weaker than the verifier's minimum requirements, the verifier MUST
reject the invocation rather than downgrading to match the server's
declared profile.
This requirement addresses a documented failure mode in the MCP
ecosystem where servers self-declare their security posture, and
relying parties accept the declaration at face value.
The verifier policy floor is enforced at the verification step,
before the tool invocation proceeds. The floor is determined by the
verifier's canonical configuration (Section 5) and is bound into the
receipt via the config_hash field.
Implementation: The verifier's canonical configuration includes a
policy_floor field. During verification, the verifier compares the
server's declared profile against this floor. If the declared
profile is weaker, the verifier MUST return a deny verdict with
block_reason set to "policy_floor_violation".
4.5. Verification Outcome States
A CCS verifier produces one of three verdict values:
* allow: The invocation passed all verification dimensions.
* deny: The invocation failed one or more verification dimensions.
* escalate: The verifier cannot make a definitive determination.
These three verdict values constitute the CCS evidence sufficiency
axis. This axis is independent from the executor lifecycle axis.
In addition to these verdict states, the verifier MAY record an
outcome_status field that captures the epistemic state regarding the
action's outcome:
* confirmed: The outcome is fully observable.
* dispatched: The verifier authorized but has no outcome evidence.
* indeterminate: The outcome cannot be determined. The verifier
MUST keep the record open and MUST NOT permit blind retries.
Wang Expires 27 February 2027 [Page 23]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
* unknown: The invocation was recorded and the receipt was durably
persisted, but the tool execution was interrupted before its
result could be recorded. This is caused by a process crash,
watchdog restart, hot-reload, or similar lifecycle event.
INDETERMINATE and UNKNOWN are not additional verdicts. They are
states on the executor lifecycle axis -- they describe what the
verifier knows about the outcome after the verdict was issued, not
the verdict itself.
The distinction between indeterminate and unknown is structural.
Indeterminate means the verifier lacks post-invocation visibility by
design or by configuration. Unknown means the verifier knows the
execution was interrupted before producing a durable result; the
invocation did not complete under the verifier's observation.
The outcome_status is orthogonal to the verdict. A deny verdict is
always confirmed. An allow verdict MAY be dispatched or
indeterminate if the verifier has no post-invocation visibility.
Severity and reconcilability are independent axes. A destructive
write with authenticated callback is high-severity but reconcilable.
A breaker trip with no telemetry is high-severity and indeterminate.
4.5.1. Scope-Comparison Axis
The scope-comparison axis determines whether a verifier can evaluate
a given profile. When a verifier cannot evaluate a profile, it
produces an UNDECIDED result with a reason code:
* NO_COMPARISON_RELATION: No verifier in the deployment can evaluate
this profile. The relying party MUST halt the comparison.
* PROFILE_NOT_HELD: This verifier does not hold the requested
profile, but another verifier may. The relying party SHOULD
consult other verifiers' capability manifests (Section 4.6) to
find one that holds the profile.
UNDECIDED is NOT a new top-level verdict. The top-level verdict
remains {allow, deny, escalate}. UNDECIDED is a per-comparison result
within the scope-comparison axis.
Example comparison result:
Wang Expires 27 February 2027 [Page 24]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
{
"comparison_axis": {
"verdict": "UNDECIDED",
"reason": "PROFILE_NOT_HELD",
"requested_profile": "mcp-tls-1.3",
"verifier_profiles": ["mcp-plain", "mcp-tls-1.2"]
}
}
Reachable-Set Exhaustion:
When a relying party receives PROFILE_NOT_HELD, it SHOULD consult
other verifiers' manifests. If all reachable verifiers return
PROFILE_NOT_HELD, the relying party MUST produce a SET_EXHAUSTED
result:
{
"comparison_axis": {
"verdict": "UNDECIDED",
"reason": "SET_EXHAUSTED",
"requested_profile": "mcp-tls-1.3",
"queried_verifiers": [
{"verifier_id": "v1", "held_profiles": ["mcp-plain"]},
{"verifier_id": "v2", "held_profiles": ["mcp-tls-1.2"]}
],
"reachable_set_exhausted": true
}
}
SET_EXHAUSTED is a terminal state. A downstream relying party with
access to a larger verifier set MAY retry using the queried_verifiers
trace to avoid redundant queries.
4.5.2. Evidence Completeness (Third Axis)
Evidence completeness is a real axis, but it does not have its own
verdict token. A "provisional" or "revisable" verdict in the
authorization layer is too easily read as "soft allow," creating
authorization-layer ambiguity.
Instead, evidence completeness is implemented via the challenge loop
(Section 4.7): when a verifier lacks sufficient evidence, it issues a
deny verdict with a structured challenge field. This answers the
third axis without introducing a new token.
This also clarifies the boundary with INDETERMINATE: Verifier lacking
records = evidence gap -> fail-closed + challenge; Executor lacking
records = INDETERMINATE on the outcome axis.
Wang Expires 27 February 2027 [Page 25]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
4.6. Verifier Capability Manifest
A conforming verifier publishes a capability manifest declaring which
profiles it can evaluate and what comparison scope it supports. The
manifest is a signed, versioned JSON document.
Manifest structure:
{
"manifest_version": "1.0",
"verifier_id": "ccs-verifier/1.1.7",
"profiles": [
{
"profile_id": "mcp-tls-1.2",
"capabilities": ["compare", "validate"],
"comparison_scope": ["mcp-plain", "mcp-tls-1.2"]
}
],
"profiles_digest": "sha256:e3b0c44298fc1c14...",
"challenge_policy": {
"expected_response_duration": 10,
"deadline_multiplier": 3,
"max_deadline": 120
},
"signing_key_fingerprint": "ad989eaf1bb89fa8",
"published_at": 1786634576,
"expires_at": 1789226576,
"signature": "..."
}
Fields:
* manifest_version: Version of the manifest schema.
* verifier_id: Stable identifier of the verifier.
* profiles: Array of profiles the verifier can evaluate. Each
profile declares its comparison scope.
* challenge_policy: Parameters for the challenge loop (Section 4.7).
* signing_key_fingerprint: SHA-256 fingerprint of the signing key.
* published_at, expires_at: Validity window.
* profiles_digest: SHA-256 digest of the canonical JSON
representation of the profiles array.
Wang Expires 27 February 2027 [Page 26]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
The profiles_digest enables a relying party to detect manifest
staleness. A mismatch indicates the manifest has been updated since
the receipt was issued; the relying party MUST re-query the verifier
and re-evaluate.
Discovery Protocol: A relying party queries the verifier capability
manifest before issuing a comparison request.
Binding: The manifest_hash (SHA-256 of the canonical manifest JSON)
is included in the CCS receipt's canonical configuration
(Section 5.1), creating cryptographic linkage.
4.7. Challenge Loop
When a verifier lacks sufficient evidence to evaluate a dimension, it
issues a deny verdict with a structured challenge field:
{
"verdict": "deny",
"block_reason": "evidence_incomplete",
"challenge": {
"missing": ["server_tls_certificate_chain", "mutual_auth_client_proof"],
"format": "pem",
"issued_at": 1786635000,
"expires_at": 1786635030,
"deadline_multiplier_applied": 3,
"base_duration": 10,
"derivation": "expires_at = issued_at + (base_duration x deadline_multiplier)"
}
}
Properties:
* Fail-closed: Evidence gap = deny. No provisional allow, no
"maybe."
* Actionable: The challenge field specifies exactly what evidence is
missing and in what format.
* Derivation-based deadline with absolute binding: expires_at is
derived as issued_at + (base_duration x deadline_multiplier),
following OSPF/BGP convention.
* max_deadline cap: Prevents unbounded waits. The effective
deadline is min(derived_deadline, max_deadline).
Protocol:
Wang Expires 27 February 2027 [Page 27]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
1. Issuer submits verification request.
2. Verifier determines evidence is insufficient.
3. Verifier returns deny + challenge specifying missing evidence.
4. Issuer supplies missing evidence before expires_at.
5. Verifier re-evaluates with complete evidence.
6. If expires_at passes without response, the deny stands.
4.7.1. Substance vs. Form
A recurring source of confusion in review is how much of a verifier's
internal rule engine must be exposed on the wire. This document
draws an explicit line between substance and form.
Substance refers to the verifier's internal implementation:
individual rule identifiers, numeric thresholds, pattern weights,
heuristic labels, classifier versions, and vendor-specific
classification logic. These are NOT required to appear in the
receipt or to be standardised across implementations.
Form refers to the receipt fields that another verifier needs to
independently reproduce or audit the result: the canonical request
hash, the canonical configuration hash, the verdict, the
outcome_status, the dimension on which the verdict was reached, and
the signature. These are normative.
The config_hash binding (Section 5.3) is the mechanism by which
substance is committed without being disclosed. This distinction
applies throughout the document.
4.7.2. Evidence Stack Alignment
CCS receipts occupy one layer of a larger evidence stack. In
deployment, the layers are:
* Layer 1 - Transport attestation: TLS channel bindings, WIMSE
workload identities, OAuth token proofs.
* Layer 2 - CCS evidence (this document): what was requested, what
was verified, what verdict was issued, under which canonical
configuration.
* Layer 3 - Enforcement: the AEB or equivalent gate that consumes
the receipt.
Wang Expires 27 February 2027 [Page 28]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
Each layer provides distinct properties. The following properties
are assigned explicitly:
* Channel confidentiality and server authentication: Layer 1.
* Workload/machine identity: Layer 1.
* Decision correctness under a stated configuration: Layer 2.
* Non-repudiation of the decision by the verifier: Layer 2 via
Ed25519 signature.
* Allow/deny effect on the action: Layer 3.
* Post-action outcome observability: Layer 3 via outcome_status
recorded back into the Layer 2 receipt.
Implementations MUST NOT produce receipts that claim Layer 1 or Layer
3 properties as CCS assertions.
4.7.3. No Disposition Authorises an Action
Normative statement. Every verification disposition in CCS --
including verdict=allow, verdict=deny, verdict=escalate,
UNDECIDED(any reason), outcome_status=indeterminate, and
outcome_status=unknown -- is an evidence statement about what the
verifier observed given the inputs and configuration it had. None of
these dispositions is, by itself, an authorisation for the relying
party to perform, continue, or abort the action.
Consequences:
1. A relying party MAY refuse an action even when the receipt
verdict is allow.
2. A relying party MUST be able to refuse an action when the receipt
is UNDECIDED or INDETERMINATE.
3. A deny verdict is an evidence statement that at least one
dimension failed; it does not by itself require any particular
remediation.
4. Enforcement policy (Layer 3) is external to CCS.
This resolves the recurring ambiguity in which "verdict=allow" could
be read as "the action is authorised." The verdict is one input into
the relying party's authorisation decision, not the decision itself.
Wang Expires 27 February 2027 [Page 29]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
4.8. Structural Test Discipline
Each conformance rule in the CCS security rule set (the eight input
rules SEC-001 through SEC-008 and the eight output rules OUT-001
through OUT-008) is expressed as a structural existence test. A
structural test is one whose outcome depends only on the presence,
absence, or literal shape of fields and values, and not on a
qualitative judgement.
For each rule, two positions are specified:
* Trigger: the exact structural condition under which the rule
fires, expressed as a literal predicate over the canonical
request.
* Scope: the exact set of inputs to which the rule applies,
expressed as a closed enumeration or a literal membership test.
Both positions MUST be free of implementer-judgement language.
Appendix E lists the trigger and scope for each of the 16 rules.
5. Canonical Configuration
5.1. Canonical Config 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:
Wang Expires 27 February 2027 [Page 30]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
+==================+=========+==========+========================+
| Field | Type | Required | Description |
+==================+=========+==========+========================+
| rules | array | MUST | Ordered list of rule |
| | of | | names as registered. |
| | strings | | |
+------------------+---------+----------+------------------------+
| policy_version | string | MUST | Version identifier of |
| | | | the policy governing |
| | | | rule evaluation. |
+------------------+---------+----------+------------------------+
| signing_key_id | string | MUST | Identifier of the |
| | | | signing key used for |
| | | | this receipt. |
+------------------+---------+----------+------------------------+
| verifier_version | string | MUST | Software version of |
| | | | the verifier. |
+------------------+---------+----------+------------------------+
| schema_version | string | MUST | Version of the CCS |
| | | | receipt schema (e.g., |
| | | | '1.3'). |
+------------------+---------+----------+------------------------+
| deployment_mode | string | MUST | 'in-process' or 'out- |
| | (enum) | | of-process'. |
+------------------+---------+----------+------------------------+
| manifest_hash | string | SHOULD | SHA-256 hash of the |
| | | | verifier capability |
| | | | manifest (Section 4.6) |
| | | | at time of issuance. |
+------------------+---------+----------+------------------------+
Table 5: Figure 5
Example canonical config:
{
"rules": ["ssrf_protection", "rce_protection", "credential_leak"],
"policy_version": "2026-08-01",
"signing_key_id": "key-2026-08-01-primary",
"verifier_version": "0.4.1",
"schema_version": "1.3",
"deployment_mode": "in-process",
"manifest_hash": "a1b2c3d4e5f6..."
}
Wang Expires 27 February 2027 [Page 31]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
5.2. Canonicalization Algorithm
The canonical configuration MUST be serialized using JSON
Canonicalization Scheme (JCS) as defined in [RFC8785]:
import json
def canonical_config(config: dict) -> bytes:
return json.dumps(
config,
sort_keys=True,
separators=(",", ":"),
ensure_ascii=False,
allow_nan=False
).encode("utf-8")
Key properties:
* Keys are sorted lexicographically.
* No whitespace between tokens (compact form).
* Non-ASCII characters are emitted as UTF-8 per RFC 8785 JCS.
* NaN and Infinity are not permitted.
5.3. Config Hash
The config_hash is computed as:
config_hash = hashlib.sha256(canonical_config(config)).hexdigest()
The config_hash MUST be included in the extended signing payload
(Section 4.2) when the extended fields are in use. This binds the
receipt to the exact rule set and policy version, preventing a
verifier from being reconfigured after issuing a receipt and having
the old receipt still validate under the new configuration.
6. Bindings
This section defines the nine binding mechanisms that connect a CCS
receipt to the various elements of the invocation lifecycle. These
bindings are designed to satisfy the native artifact verification
requirements of [I-D.schrock-action-evidence-boundary] Section 5.2.
Wang Expires 27 February 2027 [Page 32]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
6.1. request_hash Binding
Purpose: Bind the receipt to the exact request bytes as received by
the verifier.
Mechanism:
The verifier MUST compute request_hash as the SHA-256 digest of the
canonical bytes of the request that triggered verification:
def canonical_bytes(command) -> 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()
Binding strength: The request_hash changes if any material field of
the request changes.
Status: Implemented in ccs-verifier 0.4.1.
6.2. response_hash Binding
Purpose: Bind the receipt to the exact response produced by the tool
invocation.
Mechanism: After the tool is invoked, the verifier (or a post-
invocation hook) MUST compute:
response_hash = "sha256:" + hashlib.sha256(response_bytes).hexdigest()
Where response_bytes is the exact byte representation of the tool's
response. For structured responses, the canonical JSON serialization
MUST be used.
Timing: The response_hash MUST be computed after the tool invocation
completes. See Section 4.2 (Receipt lifecycle) for the two-phase
durability model.
Status: Implemented in ccs-verifier 0.4.1.
Wang Expires 27 February 2027 [Page 33]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
6.3. runtime_context_hash Binding
Purpose: Bind the receipt to the runtime execution environment.
Mechanism: The runtime context is a JSON object containing
environment-scoped fields (caller_identity, tenant, environment,
etc.).
context_bytes = json.dumps(context, sort_keys=True, separators=(",", ":")).encode("utf-8")
runtime_context_hash = "sha256:" + hashlib.sha256(context_bytes).hexdigest()
Binding strength: Prevents a receipt issued in one environment from
being replayed in another.
Status: Implemented in ccs-verifier 0.4.1.
6.4. action Binding
Purpose: Provide a CAID-compatible action identifier that enables the
CCS receipt to participate in the AEB's CAID matching process.
Mechanism:
action = "ccs:tool-invoke:{tool_name}:{params_hash}"
Where {tool_name} is the tool name from the Command and {params_hash}
is the full SHA-256 hex digest (not truncated) of the canonical
parameters.
For EC integration, this action identifier MUST be mappable to a CAID
action-type definition [I-D.schrock-canonical-action-identifier] via
a relying-party-pinned mapping profile, following the CAID MATCH
processing specified in Section 5.3 of [I-D.schrock-action-evidence-
boundary].
Status: Implemented in ccs-verifier 0.4.1 (14 enum values).
6.5. params_hash Binding
Purpose: Bind the receipt to the exact tool parameters.
Mechanism (Implemented in 0.4.1):
def params_hash(params: dict) -> str:
return hashlib.sha256(
json.dumps(params, sort_keys=True, separators=(",", ":")).encode()
).hexdigest()[:16]
Wang Expires 27 February 2027 [Page 34]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
The 0.4.1 implementation truncates to 16 hex characters (64 bits).
This provides collision resistance of approximately 2^32 under
birthday attack, which is sufficient for audit uniqueness within a
single verifier instance but MAY be insufficient for cross-verifier
replay prevention in high-volume deployments.
Recommendation: Implementations targeting conformance Level 2 or
above SHOULD use the full 64-character SHA-256 hex digest.
Status: Implemented (16-char truncation) in 0.4.1.
6.6. issuer Binding
Purpose: Identify the verifier that produced the receipt.
Mechanism: The issuer field is a URI that identifies the verifier
instance. The URI MUST be stable across key rotations. The issuer
identifier MUST be covered by the signing mechanism so that an
attacker cannot substitute a different issuer without invalidating
the receipt.
Status: Implemented in ccs-verifier 0.4.1.
6.7. audience Binding
Purpose: Identify the intended consumer of the receipt, preventing
receipt misdirection.
Mechanism: The audience field is a URI that identifies the intended
recipient. A receipt whose audience does not match the consumer MUST
be rejected.
Status: Implemented in ccs-verifier 0.4.1.
6.8. nonce/sequence Binding
Purpose: Prevent replay of previously-issued receipts.
Mechanism: The nonce field is a cryptographically random, single-use
value:
nonce = secrets.token_hex(16)
The sequence field is a monotonically increasing integer counter
scoped to the issuer.
Anti-replay enforcement:
Wang Expires 27 February 2027 [Page 35]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
* The consumer MUST maintain a replay cache of seen (issuer, nonce)
pairs.
* A receipt with a previously-seen nonce MUST be rejected.
* The replay cache MUST persist across process restarts.
* The sequence field provides an additional ordering guarantee.
Status: Implemented in ccs-verifier 0.4.1 (UUID4-based nonce).
6.9. freshness Binding (issued_at + expires_at + max_clock_skew)
Purpose: Bound the temporal validity of the receipt.
Mechanism: Three fields work together to enforce freshness:
* issued_at: Unix timestamp when the receipt was issued.
* expires_at: Unix timestamp after which the receipt MUST NOT be
accepted.
* max_clock_skew: Maximum acceptable clock skew in seconds.
Default: 30.0 seconds.
Validation algorithm:
def check_freshness(receipt, local_time, max_clock_skew=30.0):
skew = receipt.max_clock_skew or 30.0
if local_time < receipt.issued_at - skew:
return False
if local_time > receipt.expires_at + skew:
return False
return True
Recommended expiry: For tool-invocation governance, an expires_at of
issued_at + 60 seconds is RECOMMENDED.
Status: Implemented in ccs-verifier 0.4.1.
6.10. Receipt Time-Binding
A CCS receipt captures the verification moment -- not merely "was
this approved" but "when was this verified and what was the evidence
at that moment." The timestamp, verified_at, issued_at, and
expires_at fields together establish a temporal context that enables
retroactive reconciliation.
Wang Expires 27 February 2027 [Page 36]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
This design supports the following temporal authorization properties:
* Verification-moment binding: The receipt attests to the state of
knowledge at the time of verification.
* Post-hoc reconciliation: When new evidence arrives, the receipt
can be correlated using the trace_id and timestamp.
* Durable record: The receipt survives transport, retries, and
principal changes.
7. Key Management
7.1. Key Generation
HMAC-SHA256 (Implemented in 0.4.1): The signing key MUST be generated
using a cryptographically secure random number generator:
signing_key = secrets.token_bytes(32)
The key MUST NOT be derived from predictable sources (timestamps,
process IDs, weak PRNGs).
Ed25519 (Implemented in v0.4.1, for cross-domain verification): For
deployments where the verifier and consumer are in separate trust
domains, Ed25519 key pairs SHOULD be used. The private key signs the
receipt; the public key is distributed out-of-band for verification.
7.2. Key Enrollment
Before a CCS receipt can be verified by a consumer, the consumer MUST
have enrolled the verifier's key:
* HMAC: The shared secret MUST be distributed via a secure channel.
The key MUST NOT be transmitted in-band with the receipt.
* Ed25519: The public key MUST be pinned by the consumer via an out-
of-band mechanism. The key fingerprint (SHA-256 of the raw public
key bytes) SHOULD be used as the signing_key_id.
7.3. Key Rotation
Key rotation MUST follow a phased approach:
1. Announce: The verifier publishes the new key identifier and
effective date.
Wang Expires 27 February 2027 [Page 37]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
2. Dual-sign: During the overlap window, receipts are signed with
both old and new keys.
3. Cutover: After the overlap window, only the new key is used.
4. Retire: The old key is retired after all receipts signed under it
have expired (per expires_at).
The overlap window MUST be at least 2x the maximum receipt lifetime
(expires_at - issued_at).
7.4. Verifier-Operator Separation
A fundamental security property of CCS is the separation between the
verifier (which evaluates rules and signs receipts) and the operator
(the agent runtime that invokes tools).
* In-process (0.4.1): The verifier and operator share the same
address space. A compromised agent process CAN access the signing
key. This is a known limitation.
* Out-of-process (Implemented): The verifier runs in a separate
process with its own memory space. The signing key is held only
in the verifier process. A compromised agent process CANNOT
access the signing key. This is the RECOMMENDED deployment mode
for security-critical applications.
8. Transport Requirements
8.1. Fail-Closed Semantics
CCS enforcement MUST be fail-closed. This is the core security
guarantee, derived from the formal framework [CCS-FORMAL] and
implemented in the reference implementation.
Requirement: If the verifier raises an exception, times out, returns
an ambiguous result, or is unreachable, the tool invocation MUST be
blocked.
Implementation in 0.4.1:
Wang Expires 27 February 2027 [Page 38]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
def govern(fn, policy="default"):
def wrapper(*args, **kwargs):
try:
result = verifier.verify(command)
if not result.allowed:
raise PermissionError(result.block_reason)
except Exception:
raise PermissionError("Verification failed")
return fn(*args, **kwargs)
return wrapper
This is the fundamental difference from observer-pattern hooks (which
fail-open when the observer crashes, as documented in [CWE-636]).
8.2. Timeout Behavior
Verifier timeout: If the verifier does not respond within the
configured timeout (default: 5000ms for out-of-process, unlimited for
in-process), the invocation MUST be blocked.
Receipt timeout: The expires_at field (Section 6.9) provides an upper
bound on receipt validity.
Both timeouts are independent and both MUST be enforced.
8.3. In-Process vs Out-of-Process Deployment
+================+======================+=======================+
| Property | In-Process | Out-of-Process |
+================+======================+=======================+
| Process | None (shared address | Full (separate |
| boundary | space) | process) |
+----------------+----------------------+-----------------------+
| Signing key | Vulnerable to agent | Protected from agent |
| exposure | compromise | compromise |
+----------------+----------------------+-----------------------+
| Crash | None (shared crash | Full (verifier |
| isolation | domain) | survives agent crash) |
+----------------+----------------------+-----------------------+
| Latency | 7.5us P50 (measured, | OOP Unix-socket P50 |
| | 1000 iterations) | ~133us / TCP+TLS P50 |
| | | ~200us (measured) |
+----------------+----------------------+-----------------------+
| Implementation | Implemented + tested | Implemented + tested |
| status | (0.4.1) | (0.4.1) |
+----------------+----------------------+-----------------------+
| Conformance | Level 0-1 | Level 2-3 |
| level | | |
Wang Expires 27 February 2027 [Page 39]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
+----------------+----------------------+-----------------------+
Table 6: Figure 6
Note on performance: The P50/P99 latency figures above are
informational measurements from the reference implementation. They
are not normative requirements.
9. Verifier Source Classification
This section classifies verifiers by their provenance and the level
of assurance a relying party SHOULD place in their verdicts.
9.1. Class A: Self-Built Verifier
A verifier whose rule set, signing key, and configuration are built,
operated, and audited entirely by the relying party's own
organization.
* Full visibility into source code, rule definitions, and key
management.
* Independent verification of fail-closed semantics is possible.
* The signing key is generated and held within the relying party's
infrastructure.
Assurance: Highest.
EC mapping: A Class A verifier's receipt is directly consumable as a
policy-permit evidence component in an EC.
9.2. Class B: Audited Verifier
A verifier built by a third party but subjected to independent audit.
* The source code is available for review.
* An independent audit has verified the implementation matches the
specification, particularly fail-closed semantics.
* The audit report is available to the relying party.
Assurance: High, contingent on audit scope and freshness.
Wang Expires 27 February 2027 [Page 40]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
9.3. Class C: Self-Declared Verifier
A verifier whose operator claims conformance to CCS but has not
submitted to independent audit.
* The operator declares conformance. No independent verification.
* The relying party has no direct evidence of correct fail-closed
semantics.
Assurance: Low.
EC mapping: A Class C verifier's receipt MAY be consumed as evidence,
but the relying party SHOULD weight it lower than Class A or Class B.
10. Conformance Levels
10.1. Level 0-3 Definitions
Level 0 -- Baseline (Implemented in 0.4.1):
The verifier produces a signed receipt covering: trace_id, verdict,
timestamp, tool, params_hash, rule_summary. Fail-closed enforcement
is implemented. In-process deployment only.
A Level 0 implementation satisfies the core tamper-evident audit
requirement but does not provide the bindings necessary for EC
composition.
Level 1 -- Extended Bindings + Ed25519 Signing (Implemented in
v0.4.1):
In addition to Level 0, the verifier produces receipts with all 22
fields: request_hash, config_hash, response_hash,
runtime_context_hash, action (CAID-compatible, 14 enum values),
issuer, audience, nonce (UUID4-based), sequence, issued_at,
expires_at, max_clock_skew, and signature. Ed25519 signing is
supported as the primary signature algorithm alongside HMAC-SHA256.
A Level 1 implementation provides all 22 fields required for EC
composition, with Ed25519 signatures providing non-repudiation.
Level 2 -- Out-of-Process Full Isolation:
In addition to Level 1, the verifier operates out-of-process with
Unix-socket or TCP+TLS transport. The signing key is held only in
the verifier process. Cross-replica replay prevention is implemented
via shared durable state.
Wang Expires 27 February 2027 [Page 41]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
Level 3 -- Multi-Hop Verification:
In addition to Level 2, the verifier supports chain-of-custody
verification across multiple executor hops. Each hop produces its
own receipt with local audience binding.
10.2. Level 4: Evidence Propagation
Level 4 -- Evidence Propagation:
In addition to Level 3, the verifier supports cross-organization
evidence propagation with chain integrity verification. The verifier
produces Evidence Envelopes, maintains Evidence Chains, and supports
offline chain verification.
Level 4 requirements:
* Evidence Intake Protocol compliance (Section 3).
* Evidence Propagation support (Section 11).
* Enforcement Interface compliance (Section 12).
* Cross-org Evidence Profile support.
* Chain integrity verification (full and spot).
* EC summary hash computation.
A Level 4 implementation provides the highest assurance. Backward
compatibility: All Level 0-3 implementations remain conformant.
Level 4 is additive.
10.3. Conformance Vectors
Each conformance vector is a self-contained test case that a
conforming implementation MUST pass.
CV-001: Basic ALLOW receipt (Level 0) Input Command: agent_id:
"test-agent", tool: "search_web", params: {"query": "weather in
Tokyo"}. Expected: verdict: "allow", receipt: valid HMAC-SHA256
over the signed bytes.
CV-002: Basic DENY receipt (Level 0) Input Command: tool:
"shell_exec", params: {"command": "rm -rf /"}. Expected: verdict:
"deny", block_reason: non-empty, receipt: valid HMAC-SHA256
covering the deny verdict.
Wang Expires 27 February 2027 [Page 42]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
CV-003: Config hash binding (Level 1) Given two verifiers with
different rule sets, when they verify the same command, then their
config_hash values MUST differ.
CV-004: Request hash binding (Level 1) Given the same tool and rule
set, when two commands differ only in params, then their
request_hash values MUST differ.
CV-005: Issuer/audience binding (Level 2) Given a receipt with
issuer="A" and audience="B", when consumer "C" receives the
receipt, then consumer "C" MUST reject the receipt.
CV-006: Freshness enforcement (Level 2) Given a receipt with
expires_at=T, when consumer receives the receipt at time T+1, then
the consumer MUST reject the receipt.
CV-007: Intake fail-closed (Level 4) Given a malformed intake
message, when submitted, then the verifier MUST return an
INTAKE_MISSING_FIELD error, and no receipt MUST be produced.
CV-008: Evidence Envelope propagation (Level 4) Given a valid
receipt from Agent A, when Agent A delegates to Agent B, then
Agent B MUST receive an Evidence Envelope and produce its own
receipt.
CV-009: Cross-org self-contained verification (Level 4) The envelope
MUST contain all data necessary for verification without external
lookups.
CV-010: EC summary hash (Level 4) The summary hash MUST be the
SHA-256 digest of the concatenation of all receipt hashes in
insertion order.
11. Evidence Propagation
This section defines how evidence flows through multi-agent chains,
across organizational boundaries, and accumulates across execution
stages. It establishes "chain sovereignty."
11.1. Single-Agent Propagation
Within a single agent, evidence flows through a defined pipeline:
Intake -> Verification -> Receipt Emission -> Local Storage.
Local evidence store interface: The agent MUST maintain a local
evidence store with the following properties:
Wang Expires 27 February 2027 [Page 43]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
* Append-only: Receipts, once written, MUST NOT be modified or
deleted.
* Indexed: Receipts MUST be indexed by trace_id for retrieval.
* Durable: Receipts MUST be persisted to stable storage before the
tool invocation proceeds.
Query interface: The local evidence store MUST support querying by
trace_id, tool, verdict, and time_range.
Ordering guarantee: The admission decision (pre-execution fields and
verdict, as enumerated in Section 4.2, Receipt lifecycle) MUST be
durable within the agent's local store before the tool invocation
proceeds. The full 22-field receipt, including response_hash and
field 22, is finalized after execution and then MUST be durably
persisted.
11.1.1. Zero-Hop Chain Semantics
A delegation chain has length zero when an agent acts on its own
behalf with no upstream principal -- there is no delegator, no
forwarded grant, and no prior receipt to inherit.
Chain length 0 is a valid, non-error state. A conforming
implementation MUST NOT require an upstream receipt at chain length 0
and MUST NOT treat a missing previous_receipt_hash as a verification
failure.
At chain length 0, the CCS receipt's own issuance event serves as the
root of trust. Concretely, for a length-0 receipt:
* previous_receipt_hash MUST be absent or an explicit zero value
agreed by the profile.
* hop_count MUST be 0.
* chain_id MAY equal the receipt's own nonce.
* The verifier MUST evaluate every requested dimension on the
request itself.
* The "No disposition authorises an action" rule (Section 4.7.3)
applies unchanged.
When a length-0 agent later delegates to another agent, the next
receipt has hop_count=1 and previous_receipt_hash set to the length-0
receipt's hash.
Wang Expires 27 February 2027 [Page 44]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
11.2. Multi-Agent Chain Propagation
When Agent A delegates a task to Agent B, evidence MUST propagate
with the delegation.
Evidence Envelope:
{
"envelope_version": "1.3",
"original_receipt": { ... },
"parent_trace_id": "a1b2c3d4e5f67890",
"child_trace_id": "b2c3d4e5f6789012",
"delegation_reason": "search requires domain-specific search",
"hop_count": 1,
"previous_receipt_hash": "sha256:abc123..."
}
Fields:
* envelope_version: The Evidence Envelope schema version. MUST be
"1.3".
* original_receipt: The complete CCS Receipt from the delegating
agent.
* parent_trace_id: The trace_id of the delegating agent's
verification.
* child_trace_id: The trace_id assigned to the receiving agent's
verification.
* delegation_reason: Human-readable reason for the delegation.
* hop_count: The number of hops this evidence has traversed.
* previous_receipt_hash: The SHA-256 hash of the delegating agent's
receipt.
Propagation protocol:
1. Agent A receives a tool invocation request.
2. Agent A's verifier evaluates and produces Receipt_A.
3. Agent A delegates to Agent B, wrapping Receipt_A in an Evidence
Envelope.
4. Agent B submits through its own intake (Section 3).
Wang Expires 27 February 2027 [Page 45]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
5. Agent B's verifier produces Receipt_B with previous_receipt_hash
set to hash(Receipt_A).
6. Agent B MAY further delegate.
Maximum chain depth: Implementations SHOULD enforce a maximum
hop_count of 16.
11.3. Cross-Organization Propagation
When evidence crosses organizational boundaries, additional
requirements apply.
Cross-Organization Evidence Profile: Cross-org evidence MUST include
all of the following fields:
{
"envelope_version": "1.3",
"original_receipt": { ... },
"parent_trace_id": "...",
"child_trace_id": "...",
"delegation_reason": "...",
"hop_count": 2,
"previous_receipt_hash": "sha256:...",
"cross_org": {
"sender_org_id": "https://org-a.example.com",
"receiver_org_id": "https://org-b.example.com",
"trust_anchor_reference": "sha256:key-fingerprint...",
"self_contained": true
}
}
Requirements:
* sender_org_id: Identifier of the sending organization. MUST be a
stable URI.
* receiver_org_id: Identifier of the receiving organization. MUST
be a stable URI.
* trust_anchor_reference: SHA-256 fingerprint of the public key used
to verify the receipt's signature.
* self_contained: MUST be true. All verification data is included
in the envelope; no external lookups are required.
Wang Expires 27 February 2027 [Page 46]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
Self-containment requirement: Cross-org evidence MUST be self-
validating. The receiving organization MUST NOT need to make network
calls to validate the evidence.
11.4. Evidence Accumulation
As evidence propagates through a chain, it accumulates. Each hop
adds its receipt to the chain.
Evidence Chain (EC) structure:
{
"aec_version": "1.3",
"chain_id": "sha256:...",
"receipts": [
{"receipt": {...}, "hop": 0, "receipt_hash": "sha256:..."},
{"receipt": {...}, "hop": 1, "receipt_hash": "sha256:...", "previous_receipt_hash": "sha256:..."},
{"receipt": {...}, "hop": 2, "receipt_hash": "sha256:...", "previous_receipt_hash": "sha256:..."}
],
"summary_hash": "sha256:...",
"total_hops": 2
}
Ordering: EC MUST maintain insertion order. No reordering is
permitted.
Pruning: EC MUST support pruning -- the removal of intermediate
receipts while preserving chain integrity.
Summary hash computation:
summary_input = receipt_hash_0 || receipt_hash_1 || ... || receipt_hash_n
summary_hash = SHA-256(summary_input)
Any change to any receipt in the chain produces a different summary
hash.
11.5. Chain Integrity Verification
Full verification: To verify the entire chain, for each receipt
verify the signature, freshness, and chain linkage (if hop > 0), then
verify the summary hash.
Spot verification: To verify a subset of the chain, verify the
receipt at the specified hop, the chain linkage, and the summary
hash.
Chain Verification Result:
Wang Expires 27 February 2027 [Page 47]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
{
"chain_valid": true,
"broken_at": null,
"missing_hops": [],
"total_hops": 2,
"verification_mode": "full"
}
If the chain is broken:
{
"chain_valid": false,
"broken_at": 1,
"missing_hops": [],
"total_hops": 2,
"verification_mode": "full",
"failure_reason": "previous_receipt_hash mismatch at hop 1"
}
Offline verification: Chain verification MUST be possible offline (no
network calls required). This is consistent with the self-
containment requirement for cross-org evidence (Section 11.3).
12. Enforcement Interface
This section defines how evidence is consumed by enforcement systems
(such as AEB). It establishes "ecosystem sovereignty."
12.1. Enforcement Input Contract
The enforcement input contract specifies the standard interface
through which enforcement systems consume CCS evidence.
Single receipt input -- Required for enforcement consumption:
* verdict: The governance decision (allow/deny/escalate).
* signature: The cryptographic signature (Ed25519 or HMAC).
* action: The CAID-compatible action identifier.
* params_hash: Hash of the tool parameters.
* issuer: Identifier of the producing verifier.
* audience: Identifier of the intended consumer.
* issued_at / expires_at / max_clock_skew: Freshness parameters.
Wang Expires 27 February 2027 [Page 48]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
* nonce: Anti-replay value.
Optional for enforcement consumption:
* response_hash: Hash of the tool response.
* runtime_context_hash: Hash of the execution environment.
* chain_metadata: Evidence Envelope and EC information.
* outcome_status: The epistemic state
(confirmed/dispatched/indeterminate/unknown).
EC input: When consuming an Evidence Chain, the enforcement system
receives the full EC structure (Section 11.4) and can additionally
expect summary_hash and total_hops.
12.2. Receipt Validation Protocol
Enforcement systems MUST follow this step-by-step validation
protocol. Each step is independent; failure at any step produces a
specific rejection reason.
Step 1: Freshness check.
if local_time > receipt.expires_at + receipt.max_clock_skew:
return REJECT("FRESHNESS_EXPIRED")
if local_time < receipt.issued_at - receipt.max_clock_skew:
return REJECT("FRESHNESS_EXPIRED")
Step 2: Audience check.
if receipt.audience != self.identity:
return REJECT("AUDIENCE_MISMATCH")
Step 3: Signature verification.
if not verify_signature(receipt, trusted_keys[receipt.issuer]):
return REJECT("SIGNATURE_INVALID")
Step 4: Replay check.
if (receipt.issuer, receipt.nonce) in replay_cache:
return REJECT("REPLAY_DETECTED")
replay_cache.add((receipt.issuer, receipt.nonce))
Step 5: Binding verification.
Wang Expires 27 February 2027 [Page 49]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
if receipt.action != expected_action:
return REJECT("BINDING_MISMATCH")
if receipt.params_hash != compute_params_hash(current_params):
return REJECT("BINDING_MISMATCH")
Step 6: Outcome status mapping (Section 12.4).
12.3. Verification Failure Signaling
When validation fails, the enforcement system signals the failure
using a defined taxonomy.
+=======================+==========+==============================+
| Failure Category | Severity | Enforcement Action |
+=======================+==========+==============================+
| FRESHNESS_EXPIRED | CRITICAL | MUST deny. Receipt is |
| | | outside its validity window. |
+-----------------------+----------+------------------------------+
| AUDIENCE_MISMATCH | CRITICAL | MUST deny. Receipt is not |
| | | intended for this consumer. |
+-----------------------+----------+------------------------------+
| SIGNATURE_INVALID | CRITICAL | MUST deny. Receipt |
| | | cryptographic integrity is |
| | | compromised. |
+-----------------------+----------+------------------------------+
| REPLAY_DETECTED | CRITICAL | MUST deny. Receipt has been |
| | | previously consumed. |
+-----------------------+----------+------------------------------+
| BINDING_MISMATCH | CRITICAL | MUST deny. Receipt does not |
| | | match the current request. |
+-----------------------+----------+------------------------------+
| OUTCOME_INDETERMINATE | WARNING | MAY escalate. Outcome is |
| | | unknown; apply conservative |
| | | policy. |
+-----------------------+----------+------------------------------+
Table 7: Figure 7
Failure Report format:
{
"failure_category": "FRESHNESS_EXPIRED",
"severity": "CRITICAL",
"receipt_trace_id": "a1b2c3d4e5f67890",
"timestamp": 1722384061.0
}
Wang Expires 27 February 2027 [Page 50]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
12.4. Outcome Status Mapping
This section defines how CCS outcome statuses map to enforcement
decisions.
+===============+===========================================+
| Outcome | Enforcement Behavior |
| Status | |
+===============+===========================================+
| confirmed | Enforcement MAY proceed with the action. |
+---------------+-------------------------------------------+
| dispatched | Enforcement MUST wait for reconciliation |
| | before finalizing. |
+---------------+-------------------------------------------+
| indeterminate | Enforcement MUST treat as unverified and |
| | apply conservative policy. |
+---------------+-------------------------------------------+
| unknown | Enforcement MUST NOT assume success or |
| | failure. Retry is permitted only with an |
| | idempotency key; non-idempotent actions |
| | MUST be surfaced for explicit resolution. |
+---------------+-------------------------------------------+
Table 8: Figure 8
Combined verdict and outcome_status mapping:
Wang Expires 27 February 2027 [Page 51]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
+==========+===============+========================+=============+
| Verdict | Outcome | Enforcement Action | Rationale |
+==========+===============+========================+=============+
| allow | confirmed | Proceed | Full |
| | | | evidence |
+----------+---------------+------------------------+-------------+
| allow | dispatched | Proceed with | Authorized |
| | | reconciliation pending | but |
| | | | unconfirmed |
+----------+---------------+------------------------+-------------+
| allow | indeterminate | Apply conservative | No outcome |
| | | policy; may escalate | visibility |
+----------+---------------+------------------------+-------------+
| deny | confirmed | Block | Blocked |
| | | | locally |
+----------+---------------+------------------------+-------------+
| escalate | * | Defer to higher | Verifier |
| | | authority | cannot |
| | | | decide |
+----------+---------------+------------------------+-------------+
Table 9: Figure 9
This mapping aligns with the AEB draft terminology (INDETERMINATE,
PROVISIONAL, lifecycle boundaries) as discussed with Iman Schrock
(AEB-03).
12.5. One Test, Stated Once
A given security or correctness property MUST be tested by exactly
one structural test across the entire conformance surface. If a
property is checked at intake (Section 3) and again at enforcement
(Section 12), the two checks MUST be the same test: same trigger
predicate, same scope set, same pass/fail condition, same handling of
the indeterminate case.
The motivation is concrete. Earlier drafts contained a case in which
a property was tested one way at L1 receipt validation, and then a
weaker version of the same property governed exclusions at
enforcement. An attacker who could not pass the strong test could
satisfy the weak test via the exclusion path.
Conformance rules for this section:
1. For each property that is checked at more than one point, the
specification names the single authoritative test and all other
check points reference it by section number.
Wang Expires 27 February 2027 [Page 52]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
2. A check point MUST NOT introduce a separate condition, threshold,
or scope that would cause the same input to be accepted at one
point and rejected at another for reasons other than explicitly
stated policy.
3. If an enforcement layer needs to apply a stricter policy than L1
validation, that is an enforcement policy choice and is
permitted, but it MUST be expressed as policy on top of the
shared test, not as a different test.
4. Exclusions and exceptions are themselves tests. A rule that says
"X must hold, unless Y" defines two tests, and Y MUST meet the
same structural-test discipline as X (Section 4.8).
Appendix E records, for each of the 16 rules, where its single
authoritative test lives.
13. Negative Test Cases
This section defines negative test cases that a conforming CCS
implementation MUST detect and reject. These negative cases
demonstrate that the bindings defined in Section 6 are load-bearing:
removing any one binding reopens the corresponding attack.
13.1. Changed Arguments
Scenario: An attacker intercepts a valid receipt for tool invocation
A, modifies the tool parameters, and presents the modified command
with the original receipt.
Expected receipt change: The params_hash (and request_hash at Level
1+) no longer matches the modified parameters.
Expected verdict: DENY.
Detection condition:
recomputed_params_hash = compute_params_hash(modified_params)
assert recomputed_params_hash != receipt.params_hash
Binding defeated if removed: params_hash binding (Section 6.5).
13.2. Changed Response
Scenario: An attacker intercepts the tool's response, modifies it,
and presents the modified response with the original receipt.
Expected receipt change: The response_hash no longer matches.
Wang Expires 27 February 2027 [Page 53]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
Expected verdict: The receipt is still valid for the pre-invocation
decision, but the downstream consumer detects the response mismatch.
Detection condition:
recomputed = hashlib.sha256(modified_response_bytes).hexdigest()
assert recomputed != receipt.response_hash
Binding defeated if removed: response_hash binding (Section 6.2).
13.3. Replay
Scenario: An attacker captures a valid receipt for a one-time action
and replays it to authorize a second invocation.
Expected receipt change: The nonce has already been recorded in the
consumer's replay cache.
Expected verdict: DENY (replay detected).
Detection condition:
if (receipt.issuer, receipt.nonce) in replay_cache:
return DENY
Binding defeated if removed: nonce/sequence binding (Section 6.8).
13.4. Stale Evidence
Scenario: An attacker presents a receipt issued 24 hours ago for a
time-sensitive action.
Expected receipt change: The expires_at field has passed.
Expected verdict: DENY (expired receipt).
Detection condition:
if current_time > receipt.expires_at + receipt.max_clock_skew:
return DENY
Binding defeated if removed: freshness binding (Section 6.9).
13.5. Wrong Audience
Scenario: An attacker obtains a receipt intended for Executor A and
presents it to Executor B.
Wang Expires 27 February 2027 [Page 54]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
Expected receipt change: The audience field identifies Executor A.
Expected verdict: DENY (audience mismatch).
Detection condition:
if receipt.audience != expected_audience:
return DENY
Binding defeated if removed: audience binding (Section 6.7).
13.6. Key Substitution
Scenario: An attacker generates their own signing key, produces a
forged receipt, and presents it with the attacker's public key.
Expected receipt change: The receipt's issuer is not in the
consumer's trust anchor store.
Expected verdict: DENY (untrusted key).
Detection condition:
if receipt.issuer not in trusted_issuers:
return DENY
if not verify_signature(receipt, trusted_public_keys[receipt.issuer]):
return DENY
Binding defeated if removed: issuer binding (Section 6.6).
13.7. Verifier/Runtime Collusion
Scenario: The agent runtime and the verifier are operated by the same
entity. The verifier always returns ALLOW.
Expected receipt change: No change to the receipt. The receipt is
valid but the rule evaluation is trivially permissive.
Expected verdict: The receipt passes cryptographic verification, but
the AEB SHOULD flag the verifier as Class C and apply additional
scrutiny.
Detection condition:
if verifier.deny_rate < 0.001 and verifier.total_receipts > 10000:
flag_for_review(verifier)
Wang Expires 27 February 2027 [Page 55]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
Binding defeated if removed: Independent auditing (Class B) or out-
of-process deployment with independent operator.
13.8. Missing Transport
Scenario: The verifier is configured for out-of-process deployment,
but the transport is unavailable. The agent falls back to allowing
the invocation without verification.
Expected receipt change: No receipt is produced.
Expected verdict: DENY. The fail-closed semantics (Section 8.1)
mandate that the invocation MUST be blocked.
Detection condition:
N/A
Binding defeated if removed: Transport requirements (Section 8).
13.9. Intake Fail-Closed Bypass
Scenario: An attacker submits malformed input to trigger an exception
in the intake parser, hoping the system falls back to fail-open.
Expected receipt change: The intake returns an IntakeError and no
receipt is produced.
Expected verdict: DENY. The caller MUST treat absence of a receipt
as denial.
Detection condition:
N/A
Binding defeated if removed: Intake fail-closed semantics
(Section 3.3).
13.10. Chain Tampering
Scenario: An attacker attempts to insert, remove, or modify a receipt
in an Evidence Chain.
Expected receipt change: The chain linkage (previous_receipt_hash)
breaks at the tampering point; the summary hash changes.
Expected verdict: The chain verification (Section 11.5) detects the
tampering and returns chain_valid=false.
Wang Expires 27 February 2027 [Page 56]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
Detection condition:
N/A
Binding defeated if removed: Chain integrity verification
(Section 11.5).
13.11. Cross-Org Missing Self-Verification
Scenario: An attacker strips the signature from a cross-org envelope,
hoping the receiving organization skips verification.
Expected receipt change: The envelope lacks the data required for
self-contained verification.
Expected verdict: The receiving organization MUST reject the envelope
as not self-contained.
Detection condition:
N/A
Binding defeated if removed: Cross-Organization Propagation
(Section 11.3).
14. Security Considerations
* Truncated hashes. The 0.4.1 implementation truncates params_hash
to 16 hex characters (64 bits) and receipt to 32 hex characters
(128 bits). Implementations targeting cross-deployment
interoperability SHOULD use full-length digests.
* HMAC key exposure in in-process mode. When the verifier runs in
the same process as the agent, a compromised agent can read the
signing key from memory. Out-of-process deployment mitigates
this.
* Float timestamp precision. The timestamp and verified_at fields
use Python floats (IEEE 754 double precision). Implementations
SHOULD use monotonic clocks for latency measurement and wall
clocks only for issuance timestamps.
* JSON canonicalization. The params_hash and config_hash depend on
deterministic JSON serialization. Implementations MUST use the
canonical serialization specified in Section 4.2 and Section 5.2.
* Rule evaluation ordering. The config_hash binding (Level 1+)
addresses this by binding the receipt to the exact rule set.
Wang Expires 27 February 2027 [Page 57]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
* TOCTOU in out-of-process mode. The runtime_context_hash (Level 2)
mitigates this by binding the receipt to the context at
verification time.
* Verifier policy floor degradation. A Class C verifier may declare
a weaker policy floor. Mitigation: independent auditing (Class B)
or out-of-process deployment with independent operator.
* Outcome status confusion. Implementations MUST NOT treat
outcome_status as a verdict or use it to override the verdict
decision.
* Cross-organization evidence leakage. When evidence propagates
across organizational boundaries, the Evidence Envelope contains
the full receipt. Implementations SHOULD consider data
minimization; any omitted field MUST NOT break signature
verification.
* Cross-org replay. A receipt issued for organization A might be
replayed against organization B. Mitigation: the audience binding
(Section 6.7) MUST be enforced at each organizational boundary.
* Chain integrity attacks. An attacker who controls the verifier at
a single hop can produce a valid receipt for that hop, but the
evidence at that hop is fraudulent. Mitigation: Class B or Class
A verification at every hop.
* Intake fail-closed bypass. The fail-closed invariant
(Section 3.3) ensures that no receipt is produced on failure.
Implementations MUST ensure the intake error handling code path
does not contain any fallback that allows the invocation to
proceed.
* Enforcement interface confusion. The Enforcement Interface
(Section 12.4) defines an explicit mapping table that MUST be
followed. Implementations MUST NOT allow custom mappings that
weaken the enforcement guarantees.
* Evidence accumulation overflow. The maximum hop_count
(recommended: 16, Section 11.2) limits chain length.
Implementations SHOULD enforce this limit.
* Trust anchor compromise in cross-org scenarios. Implementations
MUST support revocation of trust anchors and MUST re-validate in-
flight evidence when a trust anchor is revoked.
Wang Expires 27 February 2027 [Page 58]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
15. IANA Considerations
This document does not request any IANA allocations.
16. CCS v1.3 Receipt Field Summary Table
+==+====================+========+=====+===========+======+============+
|# |Field |Type |Level|Status |Signed|Description |
+==+====================+========+=====+===========+======+============+
|1 |trace_id |16-char |0 |Implemented|Yes |Unique event|
| | |hex | | | |identifier |
+--+--------------------+--------+-----+-----------+------+------------+
|2 |verdict |enum |0 |Implemented|Yes |allow / deny|
| | |string | | | |/ escalate |
+--+--------------------+--------+-----+-----------+------+------------+
|3 |timestamp |float |0 |Implemented|Yes |Verification|
| | | | | | |time |
+--+--------------------+--------+-----+-----------+------+------------+
|4 |tool |string |0 |Implemented|Yes |Tool name |
+--+--------------------+--------+-----+-----------+------+------------+
|5 |params_hash |16-char |0 |Implemented|Yes |SHA-256 of |
| | |hex | | | |params, |
| | | | | | |truncated |
+--+--------------------+--------+-----+-----------+------+------------+
|6 |rule_summary |string |0 |Implemented|Yes |Pipe- |
| | | | | | |delimited |
| | | | | | |rule results|
+--+--------------------+--------+-----+-----------+------+------------+
|7 |receipt |32-char |0 |Implemented|N/A |HMAC-SHA256 |
| | |hex | | | |signature |
+--+--------------------+--------+-----+-----------+------+------------+
|8 |verified_at |float |0 |Implemented|No |Verification|
| | | | | | |timestamp |
+--+--------------------+--------+-----+-----------+------+------------+
|9 |block_reason |string |0 |Implemented|No |Deny/ |
| | | | | | |escalate |
| | | | | | |reason |
+--+--------------------+--------+-----+-----------+------+------------+
|10|request_hash |hex |1 |Implemented|Yes |SHA-256 of |
| | |string | | | |full request|
+--+--------------------+--------+-----+-----------+------+------------+
|11|config_hash |hex |1 |Implemented|Yes |SHA-256 of |
| | |string | | | |canonical |
| | | | | | |config |
+--+--------------------+--------+-----+-----------+------+------------+
|12|response_hash |hex |1 |Implemented|Post- |SHA-256 of |
| | |string | | |hoc |response |
+--+--------------------+--------+-----+-----------+------+------------+
Wang Expires 27 February 2027 [Page 59]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
|13|runtime_context_hash|hex |1 |Implemented|Yes |SHA-256 of |
| | |string | | | |runtime |
| | | | | | |context |
+--+--------------------+--------+-----+-----------+------+------------+
|14|action |string |1 |Implemented|Yes |CAID- |
| | | | | | |compatible |
| | | | | | |action ID |
+--+--------------------+--------+-----+-----------+------+------------+
|15|issuer |URI |1 |Implemented|Yes |Verifier |
| | |string | | | |identifier |
+--+--------------------+--------+-----+-----------+------+------------+
|16|audience |URI |1 |Implemented|Yes |Intended |
| | |string | | | |consumer |
+--+--------------------+--------+-----+-----------+------+------------+
|17|nonce |hex |1 |Implemented|Yes |Single-use |
| | |string | | | |anti-replay |
+--+--------------------+--------+-----+-----------+------+------------+
|18|sequence |integer |1 |Implemented|Yes |Monotonic |
| | | | | | |counter |
+--+--------------------+--------+-----+-----------+------+------------+
|19|issued_at |float |1 |Implemented|Yes |Issue |
| | | | | | |timestamp |
+--+--------------------+--------+-----+-----------+------+------------+
|20|expires_at |float |1 |Implemented|Yes |Expiry |
| | | | | | |timestamp |
+--+--------------------+--------+-----+-----------+------+------------+
|21|max_clock_skew |float |1 |Implemented|Yes |Clock |
| | | | | | |tolerance |
| | | | | | |(seconds) |
+--+--------------------+--------+-----+-----------+------+------------+
|22|signature |128-char|1 |Implemented|Yes |Ed25519 |
| | |hex | | | |signature |
| | | | | | |over |
| | | | | | |canonical |
| | | | | | |JSON |
+--+--------------------+--------+-----+-----------+------+------------+
Table 10: CCS v1.3 Receipt Field Summary
17. Mapping to draft-feng-agentproto-session-requirements-01
This appendix maps CCS receipt fields and protocol mechanisms to the
requirements expressed in draft-feng-agentproto-session-requirements-
01. The mapping is informative, not normative on either document.
Wang Expires 27 February 2027 [Page 60]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
17.1. REQ-5: Verifiable Authorization Binding
REQ-5 requires that a session carry verifiable evidence that an
action was authorized, such that the authorization decision cannot be
silently substituted after the fact. CCS satisfies this via:
* The action binding (Section 6.4): the receipt binds the verdict to
the exact CAID-compatible action identifier and canonical
parameters.
* The Ed25519 signature over the canonical signed bytes
(Section 4.2): the verifier that issued the verdict is identified
by the issuer field and cannot repudiate the decision.
* The config_hash (Section 5.3): the exact rule set under which the
verdict was reached is hash-bound.
* The freshness binding (Section 6.9): issued_at, expires_at, and
max_clock_skew prevent long-term replay.
17.2. REQ-7: Action Evidence Non-Repudiation
REQ-7 requires that evidence of an action and its authorization be
non-repudiable and independently verifiable by a party that was not
present at decision time. CCS satisfies this via:
* Offline verification (Section 11.5): all data necessary to verify
a receipt is present in the EC structure.
* Verifier source classification (Section 9): third parties can
distinguish Class A, B, and C verifiers.
* The capability manifest (Section 4.6) and its profiles_digest
binding.
* Audit-grade signatures: conforming deployments at Level 2 and
above use Ed25519 rather than HMAC.
17.3. Out-of-Scope Items
CCS does not itself establish session transport, sequence numbering
at the transport layer, or connection lifecycle; those are the
session requirements draft's domain. CCS supplies the evidence
artifact that a session carries; it does not replace the session.
Wang Expires 27 February 2027 [Page 61]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
18. Mapping to AUDIT BOF / W3C PROV
This appendix maps CCS receipt fields to the W3C PROV vocabulary.
The mapping is informative.
18.1. Field Mapping
+=======================+=======================+===================+
| CCS field | W3C PROV concept | Notes |
+=======================+=======================+===================+
| receipt (signed) | prov:Entity | The evidence |
| | | artifact. |
+-----------------------+-----------------------+-------------------+
| issuer | prov:wasAttributedTo | The verifier |
| | | that produced |
| | | it. |
+-----------------------+-----------------------+-------------------+
| action | prov:wasGeneratedBy | The activity |
| | | (tool |
| | | invocation) |
| | | that generated |
| | | the evidence. |
+-----------------------+-----------------------+-------------------+
| request_hash | prov:specializationOf | Binds the |
| | | evidence to the |
| | | exact request |
| | | entity. |
+-----------------------+-----------------------+-------------------+
| response_hash | prov:wasDerivedFrom | Binds to the |
| | | response |
| | | entity. |
+-----------------------+-----------------------+-------------------+
| issued_at | prov:generatedAtTime | Issue |
| | | timestamp. |
+-----------------------+-----------------------+-------------------+
| expires_at | (provenance validity) | Expiry of the |
| | | evidence as an |
| | | authorization |
| | | input. |
+-----------------------+-----------------------+-------------------+
| previous_receipt_hash | prov:wasDerivedFrom | Chain linkage |
| (chain) | | in multi-agent |
| | | propagation. |
+-----------------------+-----------------------+-------------------+
| Ed25519 signature | (signature) | Integrity and |
| (envelope) | | non-repudiation |
| | | over the |
| | | entity. |
Wang Expires 27 February 2027 [Page 62]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
+-----------------------+-----------------------+-------------------+
Table 11: W3C PROV Field Mapping
18.2. Positioning
CCS is a runtime supply-side source of audit records. A CCS verifier
produces signed evidence at the moment of an action; an AUDIT-
conformant system can ingest these records and assemble them into
longer delegation and interaction traces. CCS does not define the
trace assembly, retention policy, or auditor-facing query language;
those are AUDIT's scope. The two are complementary: CCS provides
trustworthy atoms, AUDIT provides the molecule.
19. Trigger/Scope Audit of the 16 Security Rules
This appendix records the result of the double-position audit
required by Section 4.8. Each of the 16 CCS security rules is stated
with its trigger and its scope, and the single location of its
authoritative test per Section 12.5.
19.1. Input Rules
+=========+=====================+========================+=========+
| Rule | Trigger | Scope (closed set) | Test |
| | (structural) | | |
+=========+=====================+========================+=========+
| SEC-001 | request contains an | arguments of any tool | Section |
| | absolute URL-valued | | 3.3 |
| | argument whose host | | |
| | resolves to a | | |
| | private/link-local/ | | |
| | loopback address | | |
+---------+---------------------+------------------------+---------+
| SEC-002 | argument string | arguments of tools in | Section |
| | matches command- | COMMAND_EXECUTION_TOOL | 4.7 |
| | injection | set (closed list) | |
| | structural pattern | | |
| | with chain score at | | |
| | or above threshold | | |
+---------+---------------------+------------------------+---------+
| SEC-003 | argument contains a | network-facing tool | Section |
| | value matching a | arguments destined for | 4.7 |
| | deployed secret | a network-facing tool | |
| | regex | | |
+---------+---------------------+------------------------+---------+
| SEC-004 | argument path | path-valued arguments | Section |
| | contains a | of any tool | 4.7 |
Wang Expires 27 February 2027 [Page 63]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
| | traversal sequence | | |
| | targeting a blocked | | |
| | absolute path | | |
+---------+---------------------+------------------------+---------+
| SEC-005 | tool name is in | tool name | Section |
| | destructive set and | | 4.7 |
| | request lacks an | | |
| | explicit human- | | |
| | approval | | |
| | attestation | | |
+---------+---------------------+------------------------+---------+
| SEC-006 | argument string, | arguments of command- | Section |
| | when parsed as a | execution tools | 4.7 |
| | shell command, | | |
| | contains a non- | | |
| | heredoc download- | | |
| | to-execute chain | | |
+---------+---------------------+------------------------+---------+
| SEC-007 | request omits a | presence of required | Section |
| | required canonical | field in canonical | 3.2 |
| | field | request | |
+---------+---------------------+------------------------+---------+
| SEC-008 | canonical config | config_hash value | Section |
| | hash does not match | compared to pinned set | 5.3 |
| | a pinned value | | |
+---------+---------------------+------------------------+---------+
Table 12: Input Rules (SEC-001..SEC-008)
19.2. Output Rules
+=========+=========================+====================+=========+
| Rule | Trigger (structural) | Scope (closed set) | Test |
+=========+=========================+====================+=========+
| OUT-001 | output content contains | output text from | Section |
| | a credential pattern | network-facing | 12.2 |
| | destined for a network | tools | |
| | sink | | |
+---------+-------------------------+--------------------+---------+
| OUT-002 | output content matches | output text from | Section |
| | prompt-injection | any tool | 12.2 |
| | structural pattern | | |
| | above threshold | | |
+---------+-------------------------+--------------------+---------+
| OUT-003 | output from a network- | output of tools in | Section |
| | fetch tool contains a | the | 12.2 |
| | literal instruction | NETWORK_FETCH_TOOL | |
| | pattern that addresses | set | |
Wang Expires 27 February 2027 [Page 64]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
| | the agent system prompt | | |
+---------+-------------------------+--------------------+---------+
| OUT-004 | output content length | output metadata | Section |
| | exceeds declared | | 3.4 |
| | max_size | | |
+---------+-------------------------+--------------------+---------+
| OUT-005 | output content_type | output metadata | Section |
| | does not match declared | | 3.4 |
| | schema | | |
+---------+-------------------------+--------------------+---------+
| OUT-006 | output contains a chain | output text from | Section |
| | linkage that does not | any tool | 12.2 |
| | verify against | | |
| | previous_receipt_hash | | |
+---------+-------------------------+--------------------+---------+
| OUT-007 | output carries an | output metadata | Section |
| | outcome_status outside | | 12.4 |
| | the closed enum | | |
+---------+-------------------------+--------------------+---------+
| OUT-008 | output signature does | signature field | Section |
| | not verify under issuer | | 4.2 |
| | key | | |
+---------+-------------------------+--------------------+---------+
Table 13: Output Rules (OUT-001..OUT-008)
19.3. Audit Notes
In the course of the audit for this revision, SEC-006 and OUT-003
were reworded. SEC-006 previously used the phrase "suspicious
download pattern," which required implementer judgement; it now
specifies a structural chain (a fetch primitive followed by an
execution primitive within the same parsed command, outside a
heredoc). OUT-003 previously applied to "any tool output that
appears to address the agent," which was qualitative; it is now
scoped to network-fetching tools and triggered by literal instruction
patterns.
Each rule's authoritative test lives at the section listed. No rule
is tested by a second, weaker test elsewhere; enforcement
(Section 12) references the same structural predicate.
20. Implementation Notes
This appendix is informative. It documents implementation experience
from two source-available deployments of CCS.
Wang Expires 27 February 2027 [Page 65]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
20.1. dsh-ccs-security (DeepSeek Harness Plugin)
dsh-ccs-security is a runtime plugin for the DeepSeek Harness agent
framework that enforces CCS checks in-process. It exercises the
evidence-plane/enforcement-plane separation described in
Section 4.7.3.
Two implementation observations informed this revision:
1. Tool-aware enforcement. Applying a single command-injection
threshold to every tool's string arguments caused false positives
when the agent wrote documentation containing shell examples.
The fix classifies tools: command-execution tools are scanned at
the strict threshold; data tools are scanned at a raised
threshold or audited only.
2. Output-side source classification. Scanning every tool's output
for prompt-injection patterns blocked reads of the plugin's own
test fixtures. The fix distinguishes trusted local read from
untrusted network fetch.
20.2. correctover-mcp-gateway
correctover-mcp-gateway is an out-of-process MCP proxy that enforces
CCS at the transport boundary between an agent and an MCP server. It
exercises the out-of-process deployment model of Section 8.3 and
demonstrates that the same receipt schema can be produced by a
process that is not co-resident with the agent. Performance
measurements on commodity hardware show a median verification latency
in the single-digit-microsecond range for the core check path; exact
figures are version-specific and are not normative.
20.3. Lessons
The two deployments together confirm that the evidence/enforcement
separation is not merely theoretical: when the same component both
records evidence and decides enforcement, false positives become
self-fulfilling. Separating the two, with the evidence plane fail-
closed and the enforcement plane policy-driven, yields a system that
is both auditable and usable.
Wang Expires 27 February 2027 [Page 66]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
20.4. Watchdog Interruption and Outcome=Unknown
During a watchdog-driven hot-reload of the dsh-ccs-security plugin,
the supervising process terminated running tool invocations before
their results could be durably recorded. The CCS receipts had
already been persisted, but the post-execution outcome was lost.
This incident motivated the outcome_status=unknown state added in
Section 4.5.
Three implementation lessons follow:
1. The evidence plane must write the receipt before the enforcement
plane acts, and the write must be independent of the tool process
lifecycle.
2. A watchdog or hot-reload mechanism MUST implement graceful
shutdown for active tool calls.
3. The distinction between indeterminate and unknown is not
academic. An unknown receipt requires explicit action
(idempotent retry or human resolution) because the verifier has
positive evidence that the execution did not complete.
20.5. EMILIA Protocol Independent Interoperability Profile
The EMILIA Protocol project implemented an independent CCS-05 v1.3
AEB interoperability profile, merged as commit
5fb2eae9b20d17685e1ecbe061eb4ced03dbe64e (PGP-signed, verified).
This implementation was developed independently of the Correctover
reference codebase and validates the CCS-05 v1.3 receipt profile
directly against the draft bytes.
The profile exercises 14 conformance checks:
1. Source pin: draft-correctover-ccs-05.txt pinned by SHA-256
digest
c91f0fa31b1b9e5e2dfe79b99f3b554075d3a44d5309406e748b728f86767cb9.
2. Separation from 1.1.14 package shape: the v1.3 receipt is
structurally distinct from the ccs-verifier 1.1.14 receipt
version 1.1 shape.
3. Live response binding: response_hash binds to actual tool
output.
4. Ed25519 verification: signature verifies under an RP-pinned
public key derived from a deterministic test seed.
Wang Expires 27 February 2027 [Page 67]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
5. Exact-action CAID mapping: the signed full parameter digest maps
to the executor-constructed CAID without field guessing.
6. Signature mutation: any modification to the signature bytes
fails verification.
7. Untrusted key: a receipt signed by a key not in the RP pin set
is rejected.
8. Audience binding: receipts issued for a different audience are
rejected.
9. Freshness: expired receipts are rejected.
10. Parameter substitution: changing any parameter value changes the
params_hash and fails verification.
11. Full-digest substitution: the 16-hex params_hash prefix
correctly binds to the full SHA-256 parameter digest.
12. Consumed status: one-time-use receipts cannot be replayed.
13. Unavailable status: receipts for unavailable resources are
handled distinctly from consumed.
14. Native deny non-authorizing: a CCS DENY verdict remains an
evidence statement and does not constitute authorization,
consistent with Section 4.7.3.
The 22-field v1.3 receipt uses a deterministic Ed25519 key pair
derived from the seed 'emilia/ccs-05-v1.3-independent-interop/v1'.
The signature is a detached Ed25519 signature over the RFC 8785
canonical JSON of the other 21 fields, consistent with Section 4.2.
This implementation confirms that the CCS-05 v1.3 receipt
specification is sufficient for independent implementation without
reference to the author's codebase.
21. Conformance Test Vector Format
Each conformance test vector is encoded as a JSON object:
Wang Expires 27 February 2027 [Page 68]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
{
"vector_id": "CV-001",
"description": "Basic ALLOW receipt verification",
"level": 0,
"category": "positive",
"input": {
"command": {
"agent_id": "test-agent",
"tool": "search_web",
"params": {"query": "weather in Tokyo"},
"timestamp": 1722384000.0,
"trace_id": "0000000000000001"
},
"rules": ["ssrf_protection", "rce_protection", "credential_leak"],
"signing_key_hex": "000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f"
},
"expected": {
"verdict": "allow",
"block_reason": "",
"receipt_valid": true,
"rule_summary_pattern": "ssrf_protection=allow|rce_protection=allow|credential_leak=allow"
},
"negative_variant": null
}
For negative test vectors:
{
"vector_id": "NV-001",
"description": "Changed arguments detected by params_hash mismatch",
"level": 0,
"category": "negative",
"attack": {
"type": "changed_arguments",
"modification": "params.query changed from 'weather in Tokyo' to 'weather in Osaka'"
},
"expected": {
"detection_point": "params_hash mismatch",
"verdict": "deny",
"binding_defeated_if_removed": "params_hash (Section 6.5)"
}
}
For Level 4 propagation test vectors:
Wang Expires 27 February 2027 [Page 69]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
{
"vector_id": "CV-008",
"description": "Evidence Envelope propagation",
"level": 4,
"category": "positive",
"input": {
"agent_a_receipt": {
"trace_id": "a1b2c3d4e5f67890",
"verdict": "allow",
"tool": "delegate_search"
},
"delegation": {
"to_agent": "agent-b",
"reason": "domain-specific search"
}
},
"expected": {
"envelope_present": true,
"envelope_version": "1.3",
"hop_count": 1,
"previous_receipt_hash_valid": true,
"agent_b_receipt_produced": true
}
}
22. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
March 2015, .
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
.
[I-D.schrock-action-evidence-boundary]
Schrock, I., "The Action Evidence Boundary for
Consequential Agent Effects", Work in Progress, Internet-
Draft, draft-schrock-action-evidence-boundary-03, 3 August
2026, .
Wang Expires 27 February 2027 [Page 70]
Internet-Draft Correctover Conformance Shape (CCS): Run August 2026
[I-D.schrock-canonical-action-identifier]
Schrock, I., "The Canonical Action Identifier (CAID)",
Work in Progress, Internet-Draft, draft-schrock-canonical-
action-identifier-00, 19 July 2026,
.
23. Informative References
[CCS-FORMAL]
Wang, G., "CCS Formal Framework", 2026,
.
[CWE-636] MITRE, "CWE-636: Not Failing Securely (Fail Open)", 2026,
.
[I-D.schrock-ep-authorization-receipts]
Schrock, I., "Authorization Receipts for High-Risk Agent
Actions", Work in Progress, Internet-Draft, draft-schrock-
ep-authorization-receipts-09, 20 August 2026,
.
[EMILIA-INTEROP]
Schrock, I., "CCS-05 v1.3 AEB Interoperability Profile",
August 2026, .
Author's Address
Guigui Wang
Correctover
Email: wgg234114134@163.com
URI: https://correctover.com
Wang Expires 27 February 2027 [Page 71]