Correctover Conformance Shape (CCS): Runtime Verification for AI Agent Tool Calls
draft-correctover-ccs-05
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Correctover | ||
| Last updated | 2026-08-19 (Latest revision 2026-08-17) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-correctover-ccs-05
Network Working Group G. Wang
Internet-Draft Correctover
Intended status: Informational 20 August 2026
Expires: 21 February 2027
Correctover Conformance Shape (CCS): Runtime Verification for AI Agent
Tool Calls
draft-correctover-ccs-05
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 verification outcomes (pass, fail,
unknown), and normative requirements for implementations.
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 21 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang Expires 21 February 2027 [Page 1]
Internet-Draft CCS 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Changes from draft-02 . . . . . . . . . . . . . . . . . . 6
1.4. Changes from draft-03 . . . . . . . . . . . . . . . . . . 6
1.5. Changes from draft-04 . . . . . . . . . . . . . . . . . . 7
1.6. Relationship to CCS Formal Framework (DOI References) . . 9
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Evidence Intake Protocol . . . . . . . . . . . . . . . . . . 12
3.1. Intake Interface . . . . . . . . . . . . . . . . . . . . 12
3.2. Request Normalization . . . . . . . . . . . . . . . . . . 13
3.3. Intake Fail-Closed Semantics . . . . . . . . . . . . . . 14
3.4. Intake Error Responses . . . . . . . . . . . . . . . . . 14
4. CCS Receipt Schema . . . . . . . . . . . . . . . . . . . . . 15
4.1. Field Definitions . . . . . . . . . . . . . . . . . . . . 15
4.2. Signed Bytes . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Receipt JSON Example . . . . . . . . . . . . . . . . . . 18
4.4. Verifier Policy Floor . . . . . . . . . . . . . . . . . . 18
4.5. Verification Outcome States . . . . . . . . . . . . . . . 19
4.5.1. Scope-Comparison Axis . . . . . . . . . . . . . . . . 20
4.5.2. Evidence Completeness (Third Axis) . . . . . . . . . 21
4.6. Verifier Capability Manifest . . . . . . . . . . . . . . 21
4.7. Challenge Loop . . . . . . . . . . . . . . . . . . . . . 22
4.7.1. Substance vs. Form . . . . . . . . . . . . . . . . . 24
4.7.2. Evidence Stack Alignment . . . . . . . . . . . . . . 24
4.7.3. No Disposition Authorises an Action . . . . . . . . . 25
4.8. Structural Test Discipline . . . . . . . . . . . . . . . 26
5. Canonical Configuration . . . . . . . . . . . . . . . . . . . 26
5.1. Canonical Config Fields . . . . . . . . . . . . . . . . . 26
5.2. Canonicalization Algorithm . . . . . . . . . . . . . . . 27
5.3. Config Hash . . . . . . . . . . . . . . . . . . . . . . . 28
6. Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. request_hash Binding . . . . . . . . . . . . . . . . . . 28
6.2. response_hash Binding . . . . . . . . . . . . . . . . . . 29
6.3. runtime_context_hash Binding . . . . . . . . . . . . . . 29
6.4. action Binding . . . . . . . . . . . . . . . . . . . . . 29
6.5. params_hash Binding . . . . . . . . . . . . . . . . . . . 30
Wang Expires 21 February 2027 [Page 2]
Internet-Draft CCS August 2026
6.6. issuer Binding . . . . . . . . . . . . . . . . . . . . . 30
6.7. audience Binding . . . . . . . . . . . . . . . . . . . . 31
6.8. nonce/sequence Binding . . . . . . . . . . . . . . . . . 31
6.9. freshness Binding (issued_at + expires_at +
max_clock_skew) . . . . . . . . . . . . . . . . . . . . 31
6.10. Receipt Time-Binding . . . . . . . . . . . . . . . . . . 32
7. Key Management . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 32
7.2. Key Enrollment . . . . . . . . . . . . . . . . . . . . . 33
7.3. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 33
7.4. Verifier-Operator Separation . . . . . . . . . . . . . . 33
8. Transport Requirements . . . . . . . . . . . . . . . . . . . 33
8.1. Fail-Closed Semantics . . . . . . . . . . . . . . . . . . 34
8.2. Timeout Behavior . . . . . . . . . . . . . . . . . . . . 34
8.3. In-Process vs Out-of-Process Deployment . . . . . . . . . 34
9. Verifier Source Classification . . . . . . . . . . . . . . . 35
9.1. Class A: Self-Built Verifier . . . . . . . . . . . . . . 35
9.2. Class B: Audited Verifier . . . . . . . . . . . . . . . . 35
9.3. Class C: Self-Declared Verifier . . . . . . . . . . . . . 36
10. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 36
10.1. Level 0-3 Definitions . . . . . . . . . . . . . . . . . 36
10.2. Level 4: Evidence Propagation . . . . . . . . . . . . . 37
10.3. Conformance Vectors . . . . . . . . . . . . . . . . . . 38
11. Evidence Propagation . . . . . . . . . . . . . . . . . . . . 39
11.1. Single-Agent Propagation . . . . . . . . . . . . . . . . 39
11.1.1. Zero-Hop Chain Semantics . . . . . . . . . . . . . . 40
11.2. Multi-Agent Chain Propagation . . . . . . . . . . . . . 41
11.3. Cross-Organization Propagation . . . . . . . . . . . . . 42
11.4. Evidence Accumulation . . . . . . . . . . . . . . . . . 43
11.5. Chain Integrity Verification . . . . . . . . . . . . . . 44
12. Enforcement Interface . . . . . . . . . . . . . . . . . . . . 45
12.1. Enforcement Input Contract . . . . . . . . . . . . . . . 45
12.2. Receipt Validation Protocol . . . . . . . . . . . . . . 45
12.3. Verification Failure Signaling . . . . . . . . . . . . . 46
12.4. Outcome Status Mapping . . . . . . . . . . . . . . . . . 47
12.5. One Test, Stated Once . . . . . . . . . . . . . . . . . 48
13. Negative Test Cases . . . . . . . . . . . . . . . . . . . . . 49
13.1. Changed Arguments . . . . . . . . . . . . . . . . . . . 49
13.2. Changed Response . . . . . . . . . . . . . . . . . . . . 50
13.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.4. Stale Evidence . . . . . . . . . . . . . . . . . . . . . 50
13.5. Wrong Audience . . . . . . . . . . . . . . . . . . . . . 51
13.6. Key Substitution . . . . . . . . . . . . . . . . . . . . 51
13.7. Verifier/Runtime Collusion . . . . . . . . . . . . . . . 51
13.8. Missing Transport . . . . . . . . . . . . . . . . . . . 52
13.9. Intake Fail-Closed Bypass . . . . . . . . . . . . . . . 52
13.10. Chain Tampering . . . . . . . . . . . . . . . . . . . . 53
13.11. Cross-Org Missing Self-Verification . . . . . . . . . . 53
Wang Expires 21 February 2027 [Page 3]
Internet-Draft CCS August 2026
14. Security Considerations . . . . . . . . . . . . . . . . . . . 54
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
16.1. Normative References . . . . . . . . . . . . . . . . . . 56
16.2. Informative References . . . . . . . . . . . . . . . . . 57
17. CCS v1.3 Receipt Field Summary Table . . . . . . . . . . . . 57
18. Mapping to draft-feng-agentproto-session-requirements-01 . . 58
19. Mapping to AUDIT BOF / W3C PROV . . . . . . . . . . . . . . . 59
20. Trigger/Scope Audit of the 16 Security Rules . . . . . . . . 60
21. Implementation Notes . . . . . . . . . . . . . . . . . . . . 61
22. Conformance Test Vector Format . . . . . . . . . . . . . . . 63
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 64
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 64
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 [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 an individual submission to the IETF, intended to
initiate discussion within the community. 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.
Wang Expires 21 February 2027 [Page 4]
Internet-Draft CCS August 2026
1.1. Protocol Stack Position
CCS occupies a defined position in the agent runtime protocol stack:
+================================================================+ |
Layer | Responsibility | Specification |
+========================+======================+=================+ |
Transport | Message routing and | MCP, A2A | | (MCP/A2A) |
serialization between| | | | agents and tools | |
+------------------------+----------------------+-----------------+ |
Evidence Protocol (CCS) | Evidence generation, | This document | | |
standardization, | | | | propagation, delivery| |
+------------------------+----------------------+-----------------+ |
Enforcement | Policy decision | AEB | | (AEB) | consumption and |
[I-D.schrock- | | | action gating | action-evidence-| | | |
boundary] |
+------------------------+----------------------+-----------------+ |
Tool Execution | Actual tool | Tool-specific | | | invocation
and | | | | outcome reporting | |
+========================+======================+=================+
Figure 1
CCS is responsible for:
* 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
Wang Expires 21 February 2027 [Page 5]
Internet-Draft CCS August 2026
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). * 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
[I-D.schrock-ep-authorization-receipts]. 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). * 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:
Wang Expires 21 February 2027 [Page 6]
Internet-Draft CCS August 2026
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. This
prevents infinite routing loops and enables downstream retry with a
larger set.
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. A relying party MUST verify that the
manifest's current profiles_digest matches the digest recorded in the
receipt before accepting a verdict. This prevents stale- but-valid
manifests where the signature has not expired but the profile list
has changed.
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.5.3): A verifier's
internal implementation details (thresholds, rule weights, heuristic
labels) 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. This resolves
recurring confusion about how much of the rule engine must be
exposed.
2. CCS to draft-feng-agentproto-session-requirements-01 requirement
mapping (Appendix C): Explicit mapping table showing how CCS receipts
satisfy REQ-5 (verifiable authorization binding) and REQ-7 (action
evidence non-repudiation) in the session requirements draft.
Wang Expires 21 February 2027 [Page 7]
Internet-Draft CCS August 2026
3. AUDIT BOF receipt mapping (Appendix D): Mapping of CCS receipt
fields to the W3C PROV data model used by the proposed Agent Use of
Delegation and Interaction Traceability (AUDIT) BoF. CCS is
positioned as a runtime supply-side source of audit records, not as
an audit mechanism itself.
4. Evidence stack alignment (Section 4.5.4): Clarification that the
CCS receipt occupies the evidence layer between transport
attestations (TLS, WIMSE) and enforcement decisions (AEB). Seven
collision sites identified on-list have been eliminated by explicitly
stating which layer provides each property.
5. No disposition authorises an action (Section 4.5.5): Explicit
normative statement that all verification outcome states (allow/deny/
escalate, UNDECIDED, INDETERMINATE) are evidence statements about
what the verifier observed, NOT authorization for the relying party
to act. A relying party MAY refuse an action on ALLOW and MUST be
able to refuse on INDETERMINATE. This follows the Anton/Sumit
"disposition != authorization" convergence on the principal-binding
thread.
6. Trigger/scope double-position audit (Section 4.8 and Appendix D):
Every conformance rule in the 16-rule security set (SEC-001..008,
OUT-001..008) has been reviewed to ensure that neither its trigger
condition nor its scope clause contains "implementer judgement"
language. Each rule is now expressed as a structural existence test,
not a qualitative assessment. This applies the "affectedness"
structural test lesson from the principal-binding-06 discussion.
7. One test, stated once (Section 12.5): L1 receipt validation and
runtime enforcement reference the same set of structural tests. A
property tested at intake is not re-tested with a weaker or
differently worded test at enforcement. The previous draft had an
instance where ยง15 exclusions were governed by a weaker second test;
that has been eliminated.
8. Zero-hop chain semantics (Section 11.1.1): When delegation chain
length is zero (an agent acting on its own behalf with no upstream
principal), the CCS receipt's own issuance event serves as the root
of trust. Chain length 0 is not an error and does not require an
upstream receipt; the self-issued receipt carries the full
verification burden. This addresses Blake Morrison's zero-hop
observation on the delegation-chain evidence thread.
9. Shipped implementation notes (Appendix E): Two concrete
deployment forms are referenced: (a) the dsh-ccs-security runtime
plugin for the DeepSeek Harness agent framework, and (b) correctover-
mcp-gateway, an MCP proxy. These are source- available reference
Wang Expires 21 February 2027 [Page 8]
Internet-Draft CCS August 2026
deployments that exercised the evidence plane/enforcement plane
separation in production. The tool-aware enforcement pattern
(execution tools scanned at threshold 6, data tools at raised
thresholds or audit-only) and the output-side scan classification
(trusted local read vs. untrusted network fetch) are documented as
implementation experience, not as normative requirements.
10. Unknown outcome state (Section 4.5): A fourth outcome_status
value, "unknown", has been added for the case where an invocation was
recorded and the receipt was durably persisted, but the tool
execution was interrupted before its result could be recorded
(process crash, watchdog restart, hot-reload). This is structurally
distinct from "indeterminate" (which means the verifier lacks post-
invocation visibility by design): unknown means the verifier has
positive evidence that the execution did not complete. Enforcement
behaviour for unknown requires an idempotency key before retry and
surfaces non-idempotent actions to the relying party for explicit
resolution. This addition is grounded in shipped implementation
experience in which a watchdog hot-reload interrupted active tool
calls, producing receipts whose outcome could not be reconciled.
1.6. 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, the transition model, and the
formal proof that fail-closed enforcement satisfies the governance
criterion. This I-D does not reproduce the formal framework; it
specifies the wire-level receipt and binding mechanisms that
implement it.
* *DOI: 10.5281/zenodo.21603250* -- "Action Receipts." This paper
defines the concept of an action receipt as a tamper-evident record
binding a decision to a specific action invocation. The CCS receipt
in this I-D is a concrete instantiation of that concept, specialized
for tool-invocation governance in agent runtimes.
* *DOI: 10.5281/zenodo.21234580* -- "CCS Standard v1.0." The
overarching standard that defines the three pillars (Conformance,
model (Structure, Schema, Latency, Cost, Identity, Integrity,
Security)).
* *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. Seven-dimensional verification
Wang Expires 21 February 2027 [Page 9]
Internet-Draft CCS August 2026
model. This record consolidates the protocol specification, formal
framework, and reference implementation into a single verifiable
package.
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 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.
Wang Expires 21 February 2027 [Page 10]
Internet-Draft CCS August 2026
*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
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.
Wang Expires 21 February 2027 [Page 11]
Internet-Draft CCS August 2026
*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.
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:*
Wang Expires 21 February 2027 [Page 12]
Internet-Draft CCS August 2026
* For in-process deployment, intake MUST be synchronous: the caller
blocks until the intake completes or fails. * 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=True,
allow_nan=False ).encode("utf-8")
*Unicode normalization:* All string fields in the Command MUST be
normalized to Unicode Normalization Form C (NFC) before processing.
This prevents visually identical but byte-distinct inputs from
producing different evidence.
*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.
The params_hash is computed over the canonical bytes including the
base64-encoded binary data.
*Maximum input size:*
The intake interface MUST enforce the following size limits:
+========================+==========+============================+ |
Component | Max Size | Behavior on Overflow |
+========================+==========+============================+ |
params (canonical | 64 KB | INTAKE_OVERFLOW error | | bytes) | | |
+------------------------+----------+----------------------------+ |
Wang Expires 21 February 2027 [Page 13]
Internet-Draft CCS August 2026
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 |
+========================+==========+============================+
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:
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:*
Wang Expires 21 February 2027 [Page 14]
Internet-Draft CCS August 2026
{ "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 size | | | NOT |
limit. |
+-----------------------+------+-----------------------------------+ |
INTAKE_TIMEOUT | MAY | Processing exceeded the timeout. |
+-----------------------+------+-----------------------------------+ |
INTAKE_VERSION_UN- | MUST | The intake_version is not | | SUPPORTED |
NOT | supported. |
+=======================+======+===================================+
Figure 3
*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. This prevents error-response-as-receipt
attacks. * 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-char| | |time.time_ns(), | | |hex) | | |truncated to
16 | | | | | |hex chars. | | | | | |Uniquely | | | | | |identifies
this | | | | | |verification | | | | | |event. |
Wang Expires 21 February 2027 [Page 15]
Internet-Draft CCS August 2026
+--------------------+--------+-----------+-----------+-----------------+ |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-char| | |canonical JSON
of| | |hex) | | |Command.params, | | | | | |truncated to
16 | | | | | |hex chars. |
+--------------------+--------+-----------+-----------+-----------------+ |rule_summary |string |Implemented|MUST
|Pipe-delimited | | | | | |list
of | | | | | |rule_name=verdict| | | | | |pairs. |
+--------------------+--------+-----------+-----------+-----------------+ |receipt |string |Implemented|MUST
|HMAC-SHA256 over | | |(32-char| | |signed
bytes | | |hex) | | |(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). |
+--------------------+--------+-----------+-----------+-----------------+ |audience |string |Implemented|MUST |Intended
consumer| | |(URI) | | |URI (Section 6.7)|
+--------------------+--------+-----------+-----------+-----------------+ |nonce |string |Implemented|MUST
|Single-use value | | |(hex) | | |for replay
prev. | | | | | |(Section 6.8). |
+--------------------+--------+-----------+-----------+-----------------+ |sequence |integer |Implemented|SHOULD |Monotonically | | | | | |increasing
ctr. | | | | | |(Section 6.8). |
+--------------------+--------+-----------+-----------+-----------------+ |issued_at |float |Implemented|MUST |Receipt
Wang Expires 21 February 2027 [Page 16]
Internet-Draft CCS August 2026
issue | | | | | |timestamp (Sec. | | | | | |6.9). |
+--------------------+--------+-----------+-----------+-----------------+ |expires_at |float |Implemented|MUST |Receipt
expiry | | | | | |timestamp (Sec. | | | | | |6.9). |
+--------------------+--------+-----------+-----------+-----------------+ |max_clock_skew |float |Implemented|SHOULD |Max
clock skew | | | | | |in seconds. | | | | | |Default: 30.0. |
+--------------------+--------+-----------+-----------+-----------------+ |signature |string |Implemented|MUST |Ed25519
signature| | |(128-char| | |over canonical | | |hex) | | |JSON (RFC
8785). |
+--------------------+--------+-----------+-----------+-----------------+
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}"
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}"
The extended receipt MUST use HMAC-SHA256 with the same truncation
(32 hex chars) or MUST use Ed25519 as specified in Section 7, with
the full 64-byte hex digest. The signature field (field 22) is
computed over the canonical JSON (RFC 8785) of all receipt fields.
Wang Expires 21 February 2027 [Page 17]
Internet-Draft CCS August 2026
*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.
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..." }
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.
Wang Expires 21 February 2027 [Page 18]
Internet-Draft CCS August 2026
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. * *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. The verifier knows that the invocation
started, knows that it did not complete, and knows that the outcome
is not merely unobserved but actively lost. The verifier MUST mark
the receipt with outcome_status=unknown, MUST NOT infer success or
failure, and the relying party MUST NOT issue a blind retry without
an idempotency guarantee (Section 12.4).
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; the execution may have completed
Wang Expires 21 February 2027 [Page 19]
Internet-Draft CCS August 2026
successfully or unsuccessfully, but the verifier cannot tell.
Unknown means the verifier knows the execution was interrupted before
producing a durable result; the invocation did not complete under the
verifier's observation. A watchdog that kills a running tool process
during a hot-reload produces unknown, not indeterminate, because the
verifier has positive evidence of interruption (the process
terminated before the result channel closed), not merely an absence
of evidence.
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:
{ "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:
Wang Expires 21 February 2027 [Page 20]
Internet-Draft CCS August 2026
{ "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
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.
Wang Expires 21 February 2027 [Page 21]
Internet-Draft CCS August 2026
* profiles: Array of profiles the verifier can evaluate. Each
profile declares its comparison scope.
* challenge_policy: Parameters for the challenge loop (Section 4.7).
- expected_response_duration: Declared expected time (seconds) for an
issuer to respond to a challenge. MUST be falsifiable against
operational workload. - deadline_multiplier: Multiplier applied to
expected_response_duration to derive the challenge deadline.
Following OSPF (dead_interval = 4x hello) and BGP (holdtime = 3x
keepalive) convention. Default: 3. - max_deadline: Absolute upper
bound to prevent unbounded waits.
* 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. A relying party MUST compare
this digest against the profiles_digest recorded in the CCS receipt
to detect manifest staleness (i.e., signature still valid but profile
list changed). 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. If the verifier returns
UNDECIDED(PROFILE_NOT_HELD), the relying party checks other
verifiers' manifests to find one that holds the requested profile.
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 between what the verifier claimed it
could verify and what it actually verified.
4.7. Challenge Loop
When a verifier lacks sufficient evidence to evaluate a dimension, it
issues a deny verdict with a structured challenge field:
Wang Expires 21 February 2027 [Page 22]
Internet-Draft CCS August 2026
{ "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." The third axis is answered without introducing
authorization-layer ambiguity.
* Actionable: The challenge field specifies exactly what evidence is
missing and in what format.
* Derivation-based deadline with absolute binding: The challenge
carries both issued_at (when the challenge was created) and
expires_at (the absolute deadline), where expires_at is derived as
issued_at + (base_duration x deadline_multiplier). The derivation
parameters (base_duration, deadline_multiplier) come from the
verifier's published capability manifest and are checkable before
runtime. The absolute expires_at is bound to each challenge instance
and checkable per-case. This follows OSPF (dead_interval = 4x hello)
and BGP (holdtime = 3x keepalive) convention where timing parameters
are expressed as multiples of declared base values, while the
instantiated absolute time is carried in each protocol message. This
makes every parameter falsifiable at two levels: - Manifest-level
(pre-runtime): expected_response_duration and deadline_multiplier are
declared and checkable against operational workload and design
intent. - Instance-level (per-case): expires_at is an absolute
timestamp bound to the specific challenge, verifiable by any party
without needing to re-derive.
* max_deadline cap: Prevents unbounded waits when
expected_response_duration is set unreasonably high. The effective
deadline is min(derived_deadline, max_deadline).
Protocol:
1. Issuer submits verification request. 2. Verifier determines
evidence is insufficient. 3. Verifier returns deny + challenge
specifying missing evidence, with issued_at and expires_at derived
from manifest parameters. 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.
Wang Expires 21 February 2027 [Page 23]
Internet-Draft CCS August 2026
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. Two conforming
verifiers may use completely different internal mechanisms to produce
the same verdict over the same inputs.
*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 (which binds the exact rule
set version that was active), 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: a verifier publishes
the canonical config it used, and the receipt binds to its hash. A
relying party that trusts the issuer can verify that the same config
was applied without needing to understand or execute every rule. A
relying party that does not trust the issuer can request independent
verification under a Class A or Class B verifier (Section 9).
This distinction applies throughout the document. Where a field is
normative, the word MUST is used. Where an implementation choice is
described, it is non-normative.
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. These establish who is talking to
whom over which channel.
Layer 2 - CCS evidence (this document): what was requested, what was
verified, what verdict was issued, under which canonical
configuration, bound to Layer 1 identities and to Layer 3 actions.
Wang Expires 21 February 2027 [Page 24]
Internet-Draft CCS August 2026
Layer 3 - Enforcement: the Action Evidence Boundary (AEB) or
equivalent gate that consumes the receipt and allows, denies, or
escalates the action. CCS does not itself enforce; it supplies
evidence that enforcement consumes.
Each layer provides distinct properties. Collision occurs when a
receipt appears to assert a property that is actually provided by a
different layer, causing double-accounting or ambiguity of
responsibility. The following properties are assigned explicitly:
* Channel confidentiality and server authentication: Layer 1. CCS
does not assert TLS properties. * Workload/machine identity: Layer 1.
The issuer field names the CCS verifier; the underlying workload
identity attested to Layer 1 is referenced via the
runtime_context_hash binding, not restated. * 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. The receipt states a verdict;
enforcement decides whether to act on it. * 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. A receipt that says "channel was
secure" without binding to a specific TLS channel binding is over-
reaching; the correct form is to include the channel binding value
via runtime_context_hash and let Layer 1 attest its validity.
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. The receipt states that the verifier found no
failing dimension under its configuration; it does not command the
relying party to proceed. 2. A relying party MUST be able to refuse
an action when the receipt is UNDECIDED or INDETERMINATE.
Specifically, INDETERMINATE with missing input is an evidence gap,
not a provisional permission. The verifier records what it could not
determine; the relying party decides whether the gap is acceptable.
Wang Expires 21 February 2027 [Page 25]
Internet-Draft CCS August 2026
3. A deny verdict is an evidence statement that at least one
dimension failed under the stated configuration. It does not by
itself require the relying party to take any particular remediation;
the relying party chooses remediation. 4. Enforcement policy (Layer
3) is external to CCS. Mapping a CCS disposition to an effect is the
enforcement layer's responsibility and is outside the conformance
target of this document.
This resolves a recurring ambiguity in earlier revisions 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.
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 such as "looks suspicious," "appears
malicious," or "the implementer considers."
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. If a
rule cannot be expressed without such language, it is not yet a CCS
conformance rule and belongs in the verifier's substance
(Section 4.5.3), not on the wire.
Appendix E lists the trigger and scope for each of the 16 rules and
records the result of the double-position audit performed for this
revision. The audit removed two instances of qualitative wording
from SEC-006 and OUT-003 that had been identified in review.
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 21 February 2027 [Page 26]
Internet-Draft CCS August 2026
+==================+==========+==========+=======================+ |
Field | Type | Required | Description |
+==================+==========+==========+=======================+ |
rules | array of | MUST | Ordered list of rule | | | strings | |
names as registered. |
+------------------+----------+----------+-----------------------+ |
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. |
+------------------+----------+----------+-------------------------+
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..." }
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=True, allow_nan=False ).encode("utf-8")
Key properties:
Wang Expires 21 February 2027 [Page 27]
Internet-Draft CCS August 2026
* Keys are sorted lexicographically. * No whitespace between tokens
(compact form). * ASCII-only encoding with \uXXXX escapes for non-
ASCII. * 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.
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. An attacker who modifies the request after
verification will produce a different request_hash, breaking the
binding.
*Status:* Implemented in ccs-verifier 0.4.1.
Wang Expires 21 February 2027 [Page 28]
Internet-Draft CCS August 2026
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. It is a post-hoc binding.
*Status:* Implemented in ccs-verifier 0.4.1.
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.). The
runtime_context_hash is computed as:
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:*
Wang Expires 21 February 2027 [Page 29]
Internet-Draft CCS August 2026
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 via a relying-party-pinned mapping profile.
The mapping profile MUST specify:
* The source media type: "application/x-ccs-receipt+json" * The
target action type: the CAID action-type definition * The material
fields: tool, params (via params_hash)
*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]
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.
Wang Expires 21 February 2027 [Page 30]
Internet-Draft CCS August 2026
*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:*
* 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.
Wang Expires 21 February 2027 [Page 31]
Internet-Draft CCS August 2026
*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.
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 with the new
evidence 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.
Wang Expires 21 February 2027 [Page 32]
Internet-Draft CCS August 2026
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
(e.g., configuration management system, secrets manager). 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. 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. The signing key is held in the verifier's memory. 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, file descriptors, and crash
domain. 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
Wang Expires 21 February 2027 [Page 33]
Internet-Draft CCS August 2026
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:*
The govern() wrapper in the CCS SDK intercepts the tool function call
and calls verifier.verify() before invoking the original function.
If verify() raises any exception, the wrapper catches it and raises a
PermissionError, blocking the tool invocation.
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. A receipt that has expired MUST be
rejected even if all other fields are valid.
*Combined:* 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 boundary | None (shared | Full (separate | | | address
space) | process) |
+------------------+------------------+-----------------------+ |
Signing key | Vulnerable to | Protected | | exposure | agent
compromise | |
Wang Expires 21 February 2027 [Page 34]
Internet-Draft CCS August 2026
+------------------+------------------+-----------------------+ |
Crash isolation | None (shared | Full (verifier | | | crash domain) |
survives agent crash) |
+------------------+------------------+-----------------------+ |
Latency | 7.5us P50 | OOP Unix-socket | | | (measured, | P50~133us /
TCP+TLS | | | 1000 iterations) | P50~200us (measured) |
+------------------+------------------+-----------------------+ |
Implementation | Implemented + | Implemented + tested | | status |
tested (0.4.1) | (0.4.1) |
+------------------+------------------+-----------------------+ |
Conformance | Level 0-1 | Level 2-3 | | level | | |
+==================+==================+=======================+
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.
*Properties:* * Full visibility into source code, rule definitions,
and key mgmt. * 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.
*Properties:* * 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.
Wang Expires 21 February 2027 [Page 35]
Internet-Draft CCS August 2026
*Assurance:* High, contingent on audit scope and freshness.
9.3. Class C: Self-Declared Verifier
A verifier whose operator claims conformance to CCS but has not
submitted to independent audit.
*Properties:* * 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:*
Wang Expires 21 February 2027 [Page 36]
Internet-Draft CCS August 2026
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.
A Level 2 implementation provides process isolation, key protection,
and all bindings necessary for the receipt to be consumed as a native
artifact by an AEB.
*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. The verifier policy floor
(Section 4.4) is non-negotiable from the server side.
A Level 3 implementation provides the strongest single-domain
security guarantees: process isolation, key protection, distributed
replay prevention, and multi-hop chain-of-custody verification.
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: evidence
generation, cross-domain propagation, chain integrity, and
standardized enforcement consumption. This is the level required for
inter-organization agent interoperability.
Backward compatibility: All Level 0-3 implementations remain
conformant. Level 4 is additive; it does not change the requirements
for lower levels.
Wang Expires 21 February 2027 [Page 37]
Internet-Draft CCS August 2026
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 rule_summary: contains all
registered rules with verdict=allow
*CV-002: Basic DENY receipt (Level 0)*
Input Command: agent_id: "test-agent" tool: "shell_exec" params:
{"command": "rm -rf /"} Expected: verdict: "deny" block_reason: non-
empty, describes the RCE pattern receipt: valid HMAC-SHA256 covering
the deny verdict rule_summary: contains rce_protection=deny
*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
(audience mismatch).
*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 (missing required field), when the
message is submitted to the intake interface, then the verifier MUST
return an INTAKE_MISSING_FIELD error, and no receipt MUST be
produced.
*CV-008: Evidence Envelope propagation (Level 4)*
Wang Expires 21 February 2027 [Page 38]
Internet-Draft CCS August 2026
Given a valid receipt from Agent A, when Agent A delegates to Agent
B, then Agent B MUST receive an Evidence Envelope containing the
original receipt and chain metadata, and Agent B MUST produce its own
receipt referencing the original receipt's hash.
*CV-009: Cross-org self-contained verification (Level 4)*
Given an Evidence Envelope for cross-org propagation, when the
envelope is received by an external organization, then the envelope
MUST contain all data necessary for verification without external
lookups, and the receiver MUST be able to verify chain integrity
offline.
*CV-010: EC summary hash (Level 4)*
Given an Evidence Chain with N receipts, when the summary hash is
computed, then the summary hash MUST be the SHA-256 digest of the
concatenation of all receipt hashes in insertion order, and any
change to any receipt in the chain MUST produce a different summary
hash.
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" -- the right of the the
CCS evidence protocol to define evidence flow standards.
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:
* *Append-only:* Receipts, once written, MUST NOT be modified or
deleted. The store is a write-once log. * *Indexed:* Receipts MUST
be indexed by trace_id for retrieval. * *Durable:* Receipts MUST be
persisted to stable storage before the tool invocation proceeds. If
the agent crashes after emitting a receipt but before executing the
tool, the receipt MUST survive.
*Query interface:*
Wang Expires 21 February 2027 [Page 39]
Internet-Draft CCS August 2026
The local evidence store MUST support querying by:
* trace_id: Retrieve a specific receipt. * tool: Retrieve all
receipts for a specific tool. * verdict: Retrieve all receipts with a
specific verdict. * time_range: Retrieve all receipts within a time
window.
*Ordering guarantee:*
Receipts MUST be durable within the agent's local store before the
tool invocation proceeds. This ensures that even if the tool
execution fails or the agent crashes, the evidence of the
verification decision persists.
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. This is the common
case for an agent that invokes one of its own tools in service of its
own task, without any cross-agent or cross-org delegation.
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. The receipt is self-anchored: its signature by the
verifier's own key, its freshness fields, and its binding to the
canonical request and configuration carry the full verification
burden. There is no inherited authority and no delegated scope to
validate against.
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, since the chain consists of exactly this
receipt. * The verifier MUST evaluate every requested dimension on
the request itself; it cannot defer any check to an upstream hop. *
The "No disposition authorises an action" rule (Section 4.5.5)
applies unchanged: the self-issued verdict is evidence, not a self-
authorisation.
Wang Expires 21 February 2027 [Page 40]
Internet-Draft CCS August 2026
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. The self-issued receipt thereby becomes the root of
a longer chain, and subsequent hops inherit its bindings through the
normal chain integrity mechanism (Section 11.5).
11.2. Multi-Agent Chain Propagation
When Agent A delegates a task to Agent B, evidence MUST propagate
with the delegation. This section defines the mechanism.
*Evidence Envelope:*
The Evidence Envelope is a wrapper structure that carries the
original receipt plus chain metadata:
{ "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. This creates the cryptographic chain
linkage.
*Chain linkage requirement:*
Each hop MUST produce its own receipt. The chain is a linked list of
receipts where each receipt references the previous hop's
receipt_hash via the previous_receipt_hash field in the Evidence
Envelope.
*Propagation protocol:*
1. Agent A receives a tool invocation request. 2. Agent A's
verifier evaluates the request and produces Receipt_A. 3. Agent A
delegates to Agent B, wrapping Receipt_A in an Evidence Envelope. 4.
Agent B receives the envelope, extracts the delegation request, and
submits it through its own intake (Section 3). 5. Agent B's verifier
Wang Expires 21 February 2027 [Page 41]
Internet-Draft CCS August 2026
evaluates and produces Receipt_B, with previous_receipt_hash set to
hash(Receipt_A). 6. Agent B MAY further delegate, creating another
envelope.
*Maximum chain depth:*
Implementations SHOULD enforce a maximum hop_count of 16. A chain
exceeding 16 hops MUST be flagged for review. This limit prevents
unbounded delegation chains that could exhaust verification
resources.
11.3. Cross-Organization Propagation
When evidence crosses organizational boundaries, additional
requirements apply to ensure the receiving organization can validate
the evidence independently.
*Cross-Organization Evidence Profile:*
Cross-org evidence MUST include all of the following fields in
addition to the standard Evidence Envelope:
{ "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. The receiving organization MUST have pre-enrolled this
trust anchor. * self_contained: MUST be true. Indicates that all
verification data is included in the envelope; no external lookups
are required.
*Self-containment requirement:*
Cross-org evidence MUST be self-validating. All data necessary for
signature verification, chain linkage verification, and freshness
checking MUST be included in the envelope. The receiving
organization MUST NOT need to make network calls to the sending
organization to validate the evidence.
Wang Expires 21 February 2027 [Page 42]
Internet-Draft CCS August 2026
This requirement ensures that cross-org evidence remains valid even
if the sending organization becomes unreachable.
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 of receipts is
permitted. The first receipt (hop 0) is always the origin; each
subsequent receipt references its predecessor via
previous_receipt_hash.
*Pruning:*
EC MUST support pruning -- the removal of intermediate receipts while
preserving chain integrity. When an intermediate receipt is pruned:
* The chain linkage MUST be preserved: the receipt after the pruned
receipt MUST update its previous_receipt_hash to point to the receipt
before the pruned one. * The summary hash MUST be recomputed. * The
pruned receipt MUST be stored in a separate pruned_receipts array for
audit purposes.
*Summary hash computation:*
The summary hash is a single hash that represents the entire chain:
summary_input = receipt_hash_0 || receipt_hash_1 || ... ||
receipt_hash_n summary_hash = SHA-256(summary_input)
Where || denotes concatenation and receipt hashes are in insertion
order. Any change to any receipt in the chain produces a different
summary hash.
Wang Expires 21 February 2027 [Page 43]
Internet-Draft CCS August 2026
11.5. Chain Integrity Verification
This section defines algorithms for verifying chain integrity at any
point.
*Full verification:*
To verify the entire chain:
1. For each receipt in the chain (starting from hop 0): a. Verify
the receipt's signature (HMAC or Ed25519). b. Verify the receipt's
freshness (issued_at, expires_at). c. If hop > 0, verify that
previous_receipt_hash matches the hash of the receipt at hop-1. 2.
Verify that the summary hash matches the computed value. 3. Return
{chain_valid: true, total_hops: N}.
*Spot verification:*
To verify a subset of the chain (for performance):
1. Verify the receipt at the specified hop. 2. Verify the chain
linkage at that hop (previous_receipt_hash). 3. Verify the summary
hash (which covers the entire chain). 4. Return {chain_valid: true/
false, broken_at: hop or null}.
*Chain Verification Result:*
{ "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). All data necessary for verification MUST be present in
the EC structure. This is consistent with the self-containment
requirement for cross-org evidence (Section 11.3).
Wang Expires 21 February 2027 [Page 44]
Internet-Draft CCS August 2026
12. Enforcement Interface
This section defines how evidence is consumed by enforcement systems
(such as AEB). It establishes "ecosystem sovereignty" -- the right
of the the CCS evidence protocol to define how its evidence is
consumed.
12.1. Enforcement Input Contract
The enforcement input contract specifies the standard interface
through which enforcement systems consume CCS evidence.
*Single receipt input:*
When consuming a single CCS receipt, the enforcement system can
expect the following fields:
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. * 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: Single hash representing the entire chain. *
total_hops: Number of hops in the chain. * All individual receipts
with their chain linkages.
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.*
Wang Expires 21 February 2027 [Page 45]
Internet-Draft CCS August 2026
Verify that the receipt is within its temporal validity window:
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.*
Verify that the receipt is intended for this consumer:
if receipt.audience != self.identity: return
REJECT("AUDIENCE_MISMATCH")
*Step 3: Signature verification.*
Verify the cryptographic signature:
if not verify_signature(receipt, trusted_keys[receipt.issuer]):
return REJECT("SIGNATURE_INVALID")
*Step 4: Replay check.*
Verify that the receipt has not been previously consumed:
if (receipt.issuer, receipt.nonce) in replay_cache: return
REJECT("REPLAY_DETECTED") replay_cache.add((receipt.issuer,
receipt.nonce))
*Step 5: Binding verification.*
Verify that the receipt bindings match the current request:
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.*
Map the outcome status to enforcement behavior (Section 12.4).
If all steps pass, the receipt is accepted as valid evidence.
12.3. Verification Failure Signaling
When validation fails, the enforcement system signals the failure
using a defined taxonomy.
Wang Expires 21 February 2027 [Page 46]
Internet-Draft CCS August 2026
*Failure categories and severity:*
+========================+==========+==============================+ |
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. |
+========================+==========+==============================+
Figure 7
*Failure Report format:*
{ "failure_category": "FRESHNESS_EXPIRED", "severity": "CRITICAL",
"receipt_trace_id": "a1b2c3d4e5f67890", "timestamp": 1722384061.0 }
*Security requirements:*
* Failure signaling MUST NOT leak internal verification details
beyond the defined categories. * Failure reports MUST be logged for
audit purposes. * Repeated failures from the same issuer SHOULD
trigger an alert.
12.4. Outcome Status Mapping
This section defines how CCS outcome statuses map to enforcement
decisions.
+==================+===============================================+ |
Outcome Status | Enforcement Behavior |
+==================+===============================================+ |
confirmed | Enforcement MAY proceed with the action. |
+------------------+-----------------------------------------------+ |
Wang Expires 21 February 2027 [Page 47]
Internet-Draft CCS August 2026
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. The
action is known to have been | | | interrupted before completion.
Retry is | | | permitted only with an idempotency key; | | | non-
idempotent actions MUST be surfaced to | | | the relying party for
explicit resolution. |
+==================+===============================================+
Figure 8
*Combined verdict and outcome_status mapping:*
+==========+==============+==========================+============+ |
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 authority| Verifier | | | | |
cannot | | | | | decide |
+==========+==============+==========================+============+
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.
Wang Expires 21 February 2027 [Page 48]
Internet-Draft CCS August 2026
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, turning the second test
into the vulnerability. This is the "weak test governs exclusions"
anti-pattern identified in the principal-binding-06 discussion.
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. 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
(for example, deny on UNDECIDED rather than escalate), 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 -- one for X and one for Y --
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. Each test case specifies the
attack scenario, the expected receipt change, the expected verdict,
and the detection condition.
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.
Wang Expires 21 February 2027 [Page 49]
Internet-Draft CCS August 2026
*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.
*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.
Wang Expires 21 February 2027 [Page 50]
Internet-Draft CCS August 2026
*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.
*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.
Wang Expires 21 February 2027 [Page 51]
Internet-Draft CCS August 2026
*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)
*Mitigation:* 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:* A conforming implementation MUST block the tool
invocation (fail-closed).
*Detection condition:*
try: result = await verifier_client.verify(command) except
ConnectionError: raise PermissionError("Verifier unreachable")
*Binding defeated if removed:* Fail-closed semantics (Section 8.1).
13.9. Intake Fail-Closed Bypass
*Scenario:* An attacker submits a malformed intake message and
attempts to proceed with the tool invocation despite the intake
failure.
*Expected behavior:* The intake returns an error (Section 3.4). No
receipt is produced. The tool invocation MUST be blocked.
*Detection condition:*
result = intake(malformed_command) assert isinstance(result,
IntakeError) assert no_receipt_produced() assert
tool_invocation_blocked()
Wang Expires 21 February 2027 [Page 52]
Internet-Draft CCS August 2026
*Protocol defeated if removed:* Evidence Intake Protocol
(Section 3.3).
*New test vector:*
{ "vector_id": "NV-009", "description": "Intake fail-closed bypass
attempt", "level": 4, "category": "negative", "attack": { "type":
"intake_fail_closed_bypass", "modification": "Remove required 'tool'
field from intake" }, "expected": { "detection_point": "intake
validation", "error_code": "INTAKE_MISSING_FIELD",
"receipt_produced": false, "tool_blocked": true } }
13.10. Chain Tampering
*Scenario:* An attacker intercepts an Evidence Chain and attempts to
insert a forged receipt or remove an existing one.
*Expected behavior:* The chain integrity verification (Section 11.5)
detects the tampering. The previous_receipt_hash linkage is broken,
and the summary hash does not match.
*Detection condition (insertion):*
for i in range(1, len(aec.receipts)): prev_hash =
compute_hash(aec.receipts[i-1].receipt) assert
aec.receipts[i].previous_receipt_hash == prev_hash assert
compute_summary_hash(aec) == aec.summary_hash
*Detection condition (removal):*
assert compute_summary_hash(modified_aec) != original_summary_hash
*Protocol defeated if removed:* Evidence Propagation (Section 11).
*New test vector:*
{ "vector_id": "NV-010", "description": "Evidence chain tampering by
receipt insertion", "level": 4, "category": "negative", "attack": {
"type": "chain_tampering", "modification": "Insert forged receipt at
hop 1" }, "expected": { "detection_point": "chain integrity
verification", "chain_valid": false, "broken_at": 2, "summary_match":
false } }
13.11. Cross-Org Missing Self-Verification
*Scenario:* An attacker presents a cross-org Evidence Envelope that
is missing critical verification data.
Wang Expires 21 February 2027 [Page 53]
Internet-Draft CCS August 2026
*Expected behavior:* The receiving organization MUST reject the
envelope because it is not self-contained.
*Detection condition:*
if not envelope.cross_org.self_contained: return
REJECT("CROSS_ORG_NOT_SELF_CONTAINED") if
envelope.cross_org.trust_anchor_reference not in local_trust_store:
return REJECT("UNKNOWN_TRUST_ANCHOR")
*Protocol defeated if removed:* Cross-Organization Propagation
(Section 11.3).
*New test vector:*
{ "vector_id": "NV-011", "description": "Cross-org evidence missing
self-verification data", "level": 4, "category": "negative",
"attack": { "type": "cross_org_incomplete", "modification": "Remove
signature from cross-org envelope" }, "expected": {
"detection_point": "self-containment check", "rejected": true,
"failure_category": "CROSS_ORG_NOT_SELF_CONTAINED" } }
14. Security Considerations
This section extends the security considerations from draft-02 with
new considerations for the Evidence Intake Protocol, Evidence
Propagation, and Enforcement Interface.
*Truncated hashes.* The 0.4.1 implementation truncates params_hash to
16 hex characters (64 bits) and receipt to 32 hex characters (128
bits). While sufficient for audit uniqueness within a single
deployment, these truncation levels provide reduced collision
resistance compared to full SHA-256 outputs. 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 and forge receipts. 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.
Wang Expires 21 February 2027 [Page 54]
Internet-Draft CCS August 2026
*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.
*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 including internal details (tool names, parameters, rule
summaries). Implementations SHOULD consider data minimization: the
cross-org profile MAY omit fields that are not necessary for the
receiving organization's enforcement decision. However, any omitted
field MUST NOT break the signature verification.
*Cross-org replay.* A receipt issued for organization A might be
replayed against organization B if both accept the same issuer.
Mitigation: the audience binding (Section 6.7) MUST be enforced at
each organizational boundary. Each organization SHOULD maintain an
independent replay cache.
*Chain integrity attacks.* An attacker may attempt to insert, remove,
or modify receipts in an Evidence Chain. The chain linkage
(previous_receipt_hash) and summary hash provide defense: insertion
breaks the linkage at the insertion point; removal changes the
summary hash; modification invalidates the receipt's signature.
However, an attacker who controls the verifier at a single hop can
produce a valid receipt for that hop. The chain will be
cryptographically valid, but the evidence at that hop is fraudulent.
Mitigation: Class B or Class A verification at every hop.
*Intake fail-closed bypass.* An attacker may attempt to circumvent
the intake validation by submitting malformed input and then
proceeding with the tool invocation despite the intake failure. The
fail-closed invariant (Section 3.3) ensures that no receipt is
produced on failure, and the caller MUST treat the absence of a
Wang Expires 21 February 2027 [Page 55]
Internet-Draft CCS August 2026
receipt as a denial. Implementations MUST ensure that the intake
error handling code path does not contain any fallback that allows
the invocation to proceed.
*Enforcement interface confusion.* An attacker may attempt to map CCS
outcome statuses incorrectly, treating "indeterminate" as "confirmed"
to bypass enforcement. 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.* An attacker may attempt to create
an extremely long chain to exhaust verification resources. The
maximum hop_count (recommended: 16, Section 11.2) limits chain
length. Implementations SHOULD enforce this limit at every hop and
SHOULD reject chains that exceed the limit without attempting to
verify them.
*Trust anchor compromise in cross-org scenarios.* If a trust anchor
(public key) used for cross-org evidence verification is compromised,
all evidence signed by the corresponding private key is suspect.
Implementations MUST support revocation of trust anchors and MUST re-
validate in-flight evidence when a trust anchor is revoked. The key
rotation protocol (Section 7.3) applies to cross-org trust anchors
with the additional requirement that revocation MUST be propagated to
all receiving organizations within the maximum receipt lifetime.
15. IANA Considerations
This document does not request any IANA allocations.
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI
10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/
rfc7493>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
Wang Expires 21 February 2027 [Page 56]
Internet-Draft CCS August 2026
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June
2020, <https://www.rfc-editor.org/info/rfc8785>.
16.2. Informative References
[CCS-FORMAL] Wang, G., "CCS Formal Framework", DOI 10.5281/
zenodo.21271910, 2026, <https://doi.org/10.5281/zenodo.21271910>.
[CWE-636] MITRE, M., "CWE-636: Not Failing Securely (Fail Open)",
2026, <https://cwe.mitre.org/data/definitions/636.html>.
[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.
[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.
17. 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 |
+--+--------------------+-------+-----+-----------+------+------------+ |13|runtime_context_hash|hex |1 |Implemented|Yes |SHA-256
of | | | |string | | | |runtime | | | | | | | |context |
+--+--------------------+-------+-----+-----------+------+------------+ |14|action |string |1 |Implemented|Yes |CAID- | | | | | | | |compatible | | | | | | | |action
Wang Expires 21 February 2027 [Page 57]
Internet-Draft CCS August 2026
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 |
+--+--------------------+-------+-----+-----------+------+------------+
Figure 10
18. 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 ("Agent Protocol Session Requirements"). The mapping
is provided to assist reviewers evaluating the two documents
together; it is informative, not normative on either document.
C.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.
A receipt presented for a different action or parameters fails the
params_hash check. * 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, so authorization policy cannot be
silently changed and replayed against old requests. * The freshness
binding (Section 6.9): issued_at, expires_at, and max_clock_skew
prevent long-term replay of an old authorization.
C.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, including the canonical config reference and the full chain,
is present in the EC structure. A third party can verify without
Wang Expires 21 February 2027 [Page 58]
Internet-Draft CCS August 2026
contacting the issuer. * Verifier source classification (Section 9):
third parties can distinguish self-built (Class A), audited (Class
B), and self-declared (Class C) verifiers when assigning trust to
non-repudiable evidence. * The capability manifest (Section 4.6) and
its profiles_digest binding: a verifier cannot retroactively claim to
have held a profile it did not hold at issuance time. * Audit-grade
signatures: conforming deployments at Level 2 and above use Ed25519
rather than HMAC, so the signing key cannot be shared between issuer
and verifier and non-repudiation is cryptographic rather than
symmetric.
C.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.
19. Mapping to AUDIT BOF / W3C PROV
The proposed Agent Use of Delegation and Interaction Traceability
(AUDIT) BoF is considering how agent delegations and interactions are
recorded for audit. This appendix maps CCS receipt fields to the W3C
PROV vocabulary, which is the leading candidate data model for such
records. The mapping is informative.
D.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 prov:wasDerivedFrom Chain linkage in (chain)
multi-agent propagation. Ed25519 signature (signature envelope)
Integrity and non-repudiation over the entity.
D.2. Positioning
Wang Expires 21 February 2027 [Page 59]
Internet-Draft CCS August 2026
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.
20. 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 (8 input
rules SEC-001..SEC-008, 8 output rules OUT-001..OUT-008) is stated
with its trigger and its scope, and the single location of its
authoritative test per Section 12.5.
E.1. Input Rules
Rule Trigger (structural) Scope (closed set) Test -----
----------------------------- ----------------------- ------ SEC-001
request contains an absolute URL-valued arguments of Sec 3.3 URL
whose host resolves to any tool argument a private/link-local/
loopback address or to an IPv4-mapped IPv6 loopback SEC-002 argument
string matches arguments of tools in Sec 4.7 command-injection
structural COMMAND_EXECUTION_TOOL pattern with chain score at set
(closed list) or above threshold SEC-003 argument contains a value
network-facing tools Sec 4.7 matching a deployed secret (name matches
network pattern destined for a tool regex) network-facing tool
SEC-004 argument path contains a path-valued arguments Sec 4.7
traversal sequence targeting of any tool a blocked absolute path
SEC-005 tool name is in destructive tool name Sec 4.7 set and request
lacks an explicit human-approval attestation SEC-006 argument string,
when arguments of command- Sec 4.7 parsed as a shell command,
execution tools contains a non-heredoc download-to-execute chain
SEC-007 request omits a required presence of required Sec 3.2
canonical field field in canonical request SEC-008 canonical config
hash does config_hash value Sec 5.3 not match a pinned value compared
to pinned set
E.2. Output Rules
Rule Trigger (structural) Scope (closed set) Test -----
----------------------------- ----------------------- ------ OUT-001
output content contains a output text from Sec 12.2 credential
pattern destined network-facing tools for a network sink OUT-002
output content matches output text from any Sec 12.2 prompt-injection
structural tool pattern above threshold OUT-003 output from a
network-fetch output of tools in the Sec 12.2 tool contains a literal
Wang Expires 21 February 2027 [Page 60]
Internet-Draft CCS August 2026
NETWORK_FETCH_TOOL set instruction pattern that addresses the agent
system prompt OUT-004 output content length output metadata Sec 3.4
exceeds declared max_size OUT-005 output content_type does output
metadata Sec 3.4 not match declared schema OUT-006 output contains a
chain output text from any Sec 12.2 linkage that does not verify tool
against previous_receipt_hash OUT-007 output carries an outcome_
output metadata Sec 12.4 status outside the closed enum OUT-008
output signature does not signature field Sec 4.2 verify under issuer
key
E.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.
21. Implementation Notes
This appendix is informative. It documents implementation experience
from two source-available deployments of CCS that were used to
validate the design choices in this revision.
F.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.5.5: the plugin produces CCS receipts for every tool call
(evidence plane) and independently decides whether to allow or block
based on policy (enforcement plane).
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 (bash, shell, exec,
powershell, ...) are scanned at the strict threshold; data tools
Wang Expires 21 February 2027 [Page 61]
Internet-Draft CCS August 2026
(write, edit, read) are scanned at a raised threshold or, for long
payloads, audited only. This is an instance of the structural scope
discipline in Section 4.8: the rule's scope names the exact tool set.
2. Output-side source classification. Scanning every tool's output
for prompt-injection patterns blocked reads of the plugin's own test
fixtures, which intentionally contain injection samples. The fix
distinguishes outputs that originate from a trusted local read (file
contents the developer asked for) from outputs that originate from an
untrusted network fetch (web content that may be adversarial). The
former is recorded as evidence without blocking; the latter continues
to be enforced. This matches Section 4.5.4's evidence stack
layering: a local read is already inside the trust boundary being
defended; a network fetch is at the boundary.
F.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.
F.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 (the evidence is blocked before it is recorded
cleanly). Separating the two, with the evidence plane fail-closed (a
receipt is always produced, even for blocked actions) and the
enforcement plane policy-driven, yields a system that is both
auditable and usable.
F.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 for those
invocations had already been persisted (the evidence plane writes
before the enforcement plane acts), but the post-execution outcome
was lost. The receipts showed verdict=allow with no result, and the
upper-layer agent could not determine whether the tool had succeeded,
partially executed, or failed.
Wang Expires 21 February 2027 [Page 62]
Internet-Draft CCS August 2026
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. If the receipt write and the tool execution share a
process that can be killed, the evidence guarantee is weaker than it
appears. 2. A watchdog or hot-reload mechanism MUST implement
graceful shutdown for active tool calls. Terminating an in-flight
invocation without recording its outcome produces a receipt that is
auditable but not reconcilable, which is strictly worse than either
blocking the call upfront or letting it complete. 3. The distinction
between indeterminate and unknown is not academic. An indeterminate
receipt may resolve on its own when the verifier regains visibility;
an unknown receipt requires explicit action (idempotent retry or
human resolution) because the verifier has positive evidence that the
execution did not complete. Conflating the two would cause
enforcement to either over-retry (risking double execution of non-
idempotent actions) or under-retry (leaving failed actions
unaddressed).
22. Conformance Test Vector Format
Each conformance test vector is encoded as a JSON object:
{ "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 21 February 2027 [Page 63]
Internet-Draft CCS 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
} }
23. References
Author's Address
Guigui Wang
Correctover
Email: wgg234114134@163.com
Wang Expires 21 February 2027 [Page 64]