Correctover Conformance Shape (CCS): Runtime Verification for AI Agent Tool Calls

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 Section 5.2 requires from a native artifact: request binding, response binding, runtime context binding, issuer/audience, freshness, nonce, and canonical configuration. It further defines the Evidence Intake Protocol, Evidence Propagation mechanisms, and the Enforcement Interface. This document is published as an Experimental protocol. Two independent interoperable implementations are documented in Section 21. The proposals herein are offered for review and refinement through the standard IETF process. The author welcomes feedback on all aspects of this specification, including the protocol architecture, evidence chain structure, and integration points with existing and emerging agent protocols.

CCS occupies a defined position in the agent runtime protocol stack: Protocol Stack Position

Layer	Responsibility	Specification
Transport (MCP/A2A)	Message routing and serialization between agents and tools	MCP, A2A
Evidence Protocol (CCS)	Evidence generation, standardization, propagation, delivery	This document
Enforcement (AEB)	Policy decision consumption and action gating	AEB [I-D.schrock-action-evidence-boundary]
Tool Execution	Actual tool invocation and outcome reporting	Tool-specific

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).

CCS specifies:

An Evidence Intake Protocol (Section 3) that governs how evidence legally enters the CCS system.
A receipt schema (Section 4) that binds a verdict to the exact invocation context.
A canonical configuration model (Section 5) that binds the receipt to the exact rule set and policy under which verification occurred.
Nine binding mechanisms (Section 6) that connect the receipt to the request bytes, response bytes, runtime context, action identity, parameter identity, issuer, audience, nonce, and freshness window.
Key management requirements (Section 7).
Transport requirements (Section 8) including fail-closed semantics.
Verifier source classification (Section 9).
Conformance levels and test vectors (Section 10), including Level 4 (Evidence Propagation).
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 <xref target="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.

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.

This draft (draft-04) introduces the following changes from draft-03: This draft adds three mechanisms to address IETF discussion feedback:

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.
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.
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.
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.
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.

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):

Substance vs. Form distinction (Section 4.7.1): A verifier's internal implementation details are substance and are out of scope for wire interoperability. The receipt fields required for another verifier to independently reproduce the result are form and are normative.
CCS to draft-feng-agentproto-session-requirements-01 requirement mapping (Section 18): Explicit mapping table showing how CCS receipts satisfy REQ-5 and REQ-7.
AUDIT BOF receipt mapping (Section 19): Mapping of CCS receipt fields to the W3C PROV data model.
Evidence stack alignment (Section 4.7.2): Clarification that the CCS receipt occupies the evidence layer between transport attestations and enforcement decisions.
No disposition authorises an action (Section 4.7.3): Explicit normative statement that all verification outcome states are evidence statements, NOT authorization.
Trigger/scope double-position audit (Section 4.8 and Section 20): Every conformance rule in the 16-rule security set is expressed as a structural existence test.
One test, stated once (Section 12.5): L1 receipt validation and runtime enforcement reference the same set of structural tests.
Zero-hop chain semantics (Section 11.1.1): When delegation chain length is zero, the CCS receipt's own issuance event serves as the root of trust.
Shipped implementation notes (Section 21): dsh-ccs-security and correctover-mcp-gateway.
Unknown outcome state (Section 4.5): A fourth outcome_status value, "unknown", for interrupted execution.

This draft (draft-06) introduces the following changes from draft-05, addressing interoperability verification and IETF list discussion feedback:

Intended status changed from Informational to Experimental. Two independent interoperable implementations exist (Section 21).
AEB and CAID promoted to Normative References (Section 16.1).
Detached Ed25519 signature construction specified normatively (Section 4.2).
Receipt lifecycle clarified (Sections 4.2, 6.2, 11).
Signing algorithm conformance clarified (Sections 4.1, 4.2, 7).
Python canonicalization examples corrected to produce RFC 8785 compliant output (ensure_ascii=False).
Implementation report added (Section 21).
Authorization Receipts remains Informative (Section 16.2).

This Internet-Draft is a protocol specification derived from and complementary to the following academic publications:

DOI: 10.5281/zenodo.21271910 -- "CCS Formal Framework." This paper defines the mathematical foundation: the Required(T) subset of Supported(T) conformance criterion.
DOI: 10.5281/zenodo.21603250 -- "Action Receipts." This paper defines the concept of an action receipt as a tamper-evident record binding a decision to a specific action invocation.
DOI: 10.5281/zenodo.21234580 -- "CCS Standard v1.0." The overarching standard that defines the three pillars and the seven-dimensional verification model.
DOI: 10.5281/zenodo.21783723 -- "CCS 7-Dimensional Framework Three-Endpoint Closed Loop." Contains: IETF Internet-Draft + Zenodo DOI + PyPI ccs-verifier v1.1.0.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. CCS-specific terms:

Command: An immutable, structured representation of a tool invocation request, comprising at minimum: agent_id, tool name, parameters, timestamp, and trace_id. The Command is the input to verification.
Verifier: A component that evaluates a Command against a set of Rules and produces a VerificationResult. The verifier MAY run in-process (same address space as the agent) or out-of-process (separate address space, separate crash domain).
Rule: A pluggable unit of policy evaluation. A Rule accepts a Command and returns a RuleResult with a verdict (allow, deny, escalate), an optional reason string, and a latency measurement.
VerificationResult: The output of a verification. Contains the verdict, signed receipt, rule results, and metadata.
Receipt: A truncated HMAC-SHA256 (or Ed25519, per Section 7) digest that binds the verification context to a shared secret or signing key, providing tamper-evident audit.
Config Hash: A SHA-256 digest of the canonical JSON representation of the verifier's configuration (rule set, policy version, signing key identifier). Binds the receipt to the exact policy under which verification occurred.
Fail-closed: A property of the enforcement mechanism whereby any failure in the verification path -- exception, timeout, missing input, ambiguous state -- results in the tool invocation being blocked, not allowed. This is the opposite of fail-open (CWE-636).
Conformance Shape: The complete set of fields, bindings, and semantic constraints that a CCS receipt MUST satisfy to be considered conformant at a given level.
Outcome status: The epistemic state of a verification result regarding the action's outcome. One of: confirmed, dispatched, indeterminate, unknown. Orthogonal to the verdict (allow/deny/escalate). "unknown" indicates that the invocation was recorded but execution was interrupted (process crash, watchdog restart, hot-reload) before a result was durably persisted.
Verifier policy floor: The minimum security requirements enforced by a CCS verifier, regardless of the server's self-declared profile. Non-negotiable from the server side.
Reconcilability: The property of an action whereby the effecting side can attest to what actually occurred after execution. Independent from severity.
Evidence Intake: The process by which an agent runtime submits tool invocation data to the CCS layer for evidence generation. The intake is the controlled entry point for all evidence entering the CCS system.
Evidence Envelope: A wrapper structure that carries a CCS receipt plus chain metadata for propagation across agent boundaries. The envelope preserves the original receipt and adds propagation context.
Evidence Chain (EC): An ordered list of CCS receipts linked by chain integrity hashes. Each receipt in the chain cryptographically references its predecessor.
Chain Integrity: The property that each receipt in a chain cryptographically references its predecessor via a receipt_hash linkage, preventing insertion, removal, or modification of chain members.
Enforcement Consumer: A system that validates CCS evidence and maps it to enforcement decisions. The AEB is a canonical enforcement consumer.
Intake Fail-Closed: The property that any failure in evidence intake results in no receipt being produced and a denial of the tool invocation. The system MUST NOT fall back to fail-open behavior.
Cross-Organization Evidence: Evidence that propagates across organizational boundaries, requiring self-contained verification data so that the receiving organization can validate the evidence without external lookups.
Summary Hash: A single cryptographic hash that represents the entire Evidence Chain, computed over all receipt hashes in insertion order.

Contributors: The distinction between evidence sufficiency and executor lifecycle was developed through discussion with Iman Schrock (AEB-03) and Blake Morrison (CAE 3.3/3.4, executor lifecycle, B3-y).

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.

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: Required fields:

intake_version: The CCS schema version. MUST be "1.3" for this specification.
agent_id: Identifier of the invoking agent.
tool: Name of the tool being invoked.
params: Structured parameters for the tool invocation.
timestamp: Unix timestamp of the invocation request.
trace_id: Unique identifier for this verification event.

Optional fields:

runtime_context: JSON object containing caller_identity, tenant, environment, and other execution environment fields.
delegation_chain: If this invocation is part of a multi-agent delegation, the parent receipt information.

Synchronicity requirements:

For in-process deployment, intake MUST be synchronous: the caller blocks until the intake completes or fails.
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).

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]: bytes: return json.dumps( params, sort_keys=True, separators=(",", ":"), ensure_ascii=False, allow_nan=False ).encode("utf-8") ]]> Note: The Python snippet above uses ensure_ascii=False so that non-ASCII characters are emitted as their UTF-8 encoding, matching the normative RFC 8785 JCS output. Earlier revisions used ensure_ascii=True, which produced \uXXXX escapes for non-ASCII code points and therefore different signed bytes. Implementations MUST treat RFC 8785 JCS output as the canonical byte sequence; language-specific convenience serializers that deviate from JCS (including default ascii escaping) are not compliant. Unicode normalization: All string fields in the Command MUST be normalized to Unicode Normalization Form C (NFC) before processing. Timestamp normalization: All timestamps MUST be converted to UTC before processing. Implementations MUST reject timestamps with timezone offsets other than UTC. Binary data handling: Any binary data in the params MUST be encoded as base64 (standard encoding, with padding) before canonicalization. Maximum input size: The intake interface MUST enforce the following size limits: Figure 2

Component	Max Size	Behavior on Overflow
params (canonical bytes)	64 KB	INTAKE_OVERFLOW error
tool name	256 bytes	INTAKE_OVERFLOW error
agent_id	512 bytes	INTAKE_OVERFLOW error
runtime_context	16 KB	INTAKE_OVERFLOW error
total intake message	128 KB	INTAKE_OVERFLOW error

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: 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.

When intake fails, the verifier returns a structured error response. Error response format: Error taxonomy: Figure 3

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 NOT	A component exceeds its size limit.
INTAKE_TIMEOUT	MAY	Processing exceeded the timeout.
INTAKE_VERSION_UNSUPPORTED	MUST NOT	The intake_version is not supported.

Security requirements for error responses:

Error responses MUST NOT leak internal implementation details (stack traces, internal paths, key identifiers).
Error responses MUST be structurally distinguishable from valid receipts. An error response MUST NOT contain a receipt field, and a receipt MUST NOT contain an error_code field.
The trace_id in the error response (if available) allows correlation with the original intake attempt.

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. Figure 4

Field	Type	Status	Required	Description
trace_id	string (16-hex)	Implemented	MUST	SHA-256 of time.time_ns(), truncated to 16 hex chars. Uniquely identifies this verification event.
verdict	string (enum)	Implemented	MUST	One of: "allow", "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 (16-hex)	Implemented	MUST	SHA-256 of canonical JSON of Command.params, truncated to 16 hex chars.
rule_summary	string	Implemented	MUST	Pipe-delimited list of rule_name=verdict pairs.
receipt	string (32-hex)	Implemented	MUST	HMAC-SHA256 over signed bytes (Section 4.2), truncated to 32 hex chars.
verified_at	float	Implemented	MUST	Unix timestamp of verification.
block_reason	string	Implemented	Conditional	Human-readable reason for deny/escalate. MUST be empty for allow.
request_hash	string (hex)	Implemented	MUST	SHA-256 of the canonical bytes of the original request (Section 6.1).
response_hash	string (hex)	Implemented	SHOULD	SHA-256 of the tool response bytes (Section 6.2).
runtime_context_hash	string (hex)	Implemented	SHOULD	SHA-256 of 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 (hex)	Implemented	MUST	SHA-256 of the canonical config (Section 5).
issuer	string (URI)	Implemented	MUST	Verifier URI (Section 6.6).
audience	string (URI)	Implemented	MUST	Intended consumer URI (Section 6.7).
nonce	string (hex)	Implemented	MUST	Single-use value for replay prevention (Section 6.8).
sequence	integer	Implemented	SHOULD	Monotonically increasing counter (Section 6.8).
issued_at	float	Implemented	MUST	Receipt issue timestamp (Section 6.9).
expires_at	float	Implemented	MUST	Receipt expiry timestamp (Section 6.9).
max_clock_skew	float	Implemented	SHOULD	Max clock skew in seconds. Default: 30.0.
signature	string (128-hex)	Implemented	MUST	Ed25519 signature over RFC 8785 canonical JSON of fields 1-21; Ed25519-only for v1.3.

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): 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): 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: Signing algorithm conformance (Normative): The 22-field v1.3 receipt (Level 1 and above) uses Ed25519 exclusively for field 22. The field contains 128 lowercase hexadecimal characters (64-byte Ed25519 signature). HMAC-SHA256 truncation (32 hex chars) applies only to the legacy 7-field Level 0 receipt (field 7); it MUST NOT be used in field 22 of a v1.3 receipt. Detached Ed25519 signature construction (Normative): The signature field (field 22) is a detached Ed25519 signature computed as follows:

Construct a JSON object containing receipt fields 1-21, excluding field 22 itself.
Apply RFC 8785 JSON Canonicalization Scheme (JCS) to produce the canonical byte sequence. All non-ASCII characters are emitted as UTF-8 per JCS; implementations MUST NOT apply ASCII-only escaping.
Sign the canonical bytes using the Ed25519 private key corresponding to the issuer's published public key.
Encode the signature as 128 lowercase hexadecimal characters (64 bytes).

The signature is detached: field 22 is not included in its own signed bytes. A verifier MUST reconstruct the canonical JSON from fields 1-21 (excluding field 22), apply RFC 8785, and verify the Ed25519 signature over those bytes. Any field not included in the canonical JSON is not covered by the signature. This construction was validated by an independent implementation (Section 21.5) which achieved 14/14 conformance checks using this exact signing procedure. Receipt lifecycle (Normative): The 22-field v1.3 receipt is a post-execution evidence record. It is finalized after the tool invocation completes and response_hash (field 12) is computed. The durability requirement in Section 11 applies in two phases: (a) Pre-execution: the admission decision (verdict, trace_id, timestamp, tool, params_hash, rule_summary, request_hash, config_hash, action, issuer, audience, nonce, issued_at, and policy context) MUST be durably persisted before enforcement permits the invocation to proceed. A crash between admission and execution MUST leave an auditable admission record. (b) Post-execution: after the tool returns, the verifier (or a post-invocation hook) computes response_hash, determines outcome_status, and finalizes the 22-field receipt with field 22. The final receipt is the durable post-execution evidence artifact. If execution is interrupted before response_hash can be computed, the record remains open with outcome_status=unknown (Section 4.5) and is finalized when outcome is determined or explicitly resolved. A deny verdict does not require execution: the receipt is finalized at admission time with an empty response_hash and outcome_status=confirmed (the denial itself is the confirmed outcome). An allow verdict requires post-execution finalization; until finalized it has outcome_status=dispatched. This two-phase model resolves the apparent contradiction between the pre-invocation durability requirement and the post-hoc nature of response_hash: they apply to different stages of the same evidence record, identified by a common trace_id. Critical property: The signed bytes cover the full verification context. Any change to any signed field -- the tool name, the parameters, the verdict, the timestamp, the rule summary -- invalidates the receipt. This is what makes the receipt tamper-evident.

The following is an example CCS receipt as produced by ccs-verifier 0.4.1 (core fields): The following example shows the full receipt with all 22 fields:

A conforming CCS verifier enforces a non-negotiable policy floor. When a server or tool endpoint declares a security profile that is weaker than the verifier's minimum requirements, the verifier MUST reject the invocation rather than downgrading to match the server's declared profile. This requirement addresses a documented failure mode in the MCP ecosystem where servers self-declare their security posture, and relying parties accept the declaration at face value. The verifier policy floor is enforced at the verification step, before the tool invocation proceeds. The floor is determined by the verifier's canonical configuration (Section 5) and is bound into the receipt via the config_hash field. Implementation: The verifier's canonical configuration includes a policy_floor field. During verification, the verifier compares the server's declared profile against this floor. If the declared profile is weaker, the verifier MUST return a deny verdict with block_reason set to "policy_floor_violation".

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.

INDETERMINATE and UNKNOWN are not additional verdicts. They are states on the executor lifecycle axis -- they describe what the verifier knows about the outcome after the verdict was issued, not the verdict itself. The distinction between indeterminate and unknown is structural. Indeterminate means the verifier lacks post-invocation visibility by design or by configuration. Unknown means the verifier knows the execution was interrupted before producing a durable result; the invocation did not complete under the verifier's observation. The outcome_status is orthogonal to the verdict. A deny verdict is always confirmed. An allow verdict MAY be dispatched or indeterminate if the verifier has no post-invocation visibility. Severity and reconcilability are independent axes. A destructive write with authenticated callback is high-severity but reconcilable. A breaker trip with no telemetry is high-severity and indeterminate.

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: 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: 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.

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.

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: Fields:

manifest_version: Version of the manifest schema.
verifier_id: Stable identifier of the verifier.
profiles: Array of profiles the verifier can evaluate. Each profile declares its comparison scope.
challenge_policy: Parameters for the challenge loop (Section 4.7).
signing_key_fingerprint: SHA-256 fingerprint of the signing key.
published_at, expires_at: Validity window.
profiles_digest: SHA-256 digest of the canonical JSON representation of the profiles array.

The profiles_digest enables a relying party to detect manifest staleness. A mismatch indicates the manifest has been updated since the receipt was issued; the relying party MUST re-query the verifier and re-evaluate. Discovery Protocol: A relying party queries the verifier capability manifest before issuing a comparison request. Binding: The manifest_hash (SHA-256 of the canonical manifest JSON) is included in the CCS receipt's canonical configuration (Section 5.1), creating cryptographic linkage.

When a verifier lacks sufficient evidence to evaluate a dimension, it issues a deny verdict with a structured challenge field: Properties:

Fail-closed: Evidence gap = deny. No provisional allow, no "maybe."
Actionable: The challenge field specifies exactly what evidence is missing and in what format.
Derivation-based deadline with absolute binding: expires_at is derived as issued_at + (base_duration x deadline_multiplier), following OSPF/BGP convention.
max_deadline cap: Prevents unbounded waits. The effective deadline is min(derived_deadline, max_deadline).

Protocol:

Issuer submits verification request.
Verifier determines evidence is insufficient.
Verifier returns deny + challenge specifying missing evidence.
Issuer supplies missing evidence before expires_at.
Verifier re-evaluates with complete evidence.
If expires_at passes without response, the deny stands.

A recurring source of confusion in review is how much of a verifier's internal rule engine must be exposed on the wire. This document draws an explicit line between substance and form. Substance refers to the verifier's internal implementation: individual rule identifiers, numeric thresholds, pattern weights, heuristic labels, classifier versions, and vendor-specific classification logic. These are NOT required to appear in the receipt or to be standardised across implementations. Form refers to the receipt fields that another verifier needs to independently reproduce or audit the result: the canonical request hash, the canonical configuration hash, the verdict, the outcome_status, the dimension on which the verdict was reached, and the signature. These are normative. The config_hash binding (Section 5.3) is the mechanism by which substance is committed without being disclosed. This distinction applies throughout the document.

CCS receipts occupy one layer of a larger evidence stack. In deployment, the layers are:

Layer 1 - Transport attestation: TLS channel bindings, WIMSE workload identities, OAuth token proofs.
Layer 2 - CCS evidence (this document): what was requested, what was verified, what verdict was issued, under which canonical configuration.
Layer 3 - Enforcement: the AEB or equivalent gate that consumes the receipt.

Each layer provides distinct properties. The following properties are assigned explicitly:

Channel confidentiality and server authentication: Layer 1.
Workload/machine identity: Layer 1.
Decision correctness under a stated configuration: Layer 2.
Non-repudiation of the decision by the verifier: Layer 2 via Ed25519 signature.
Allow/deny effect on the action: Layer 3.
Post-action outcome observability: Layer 3 via outcome_status recorded back into the Layer 2 receipt.

Implementations MUST NOT produce receipts that claim Layer 1 or Layer 3 properties as CCS assertions.

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:

A relying party MAY refuse an action even when the receipt verdict is allow.
A relying party MUST be able to refuse an action when the receipt is UNDECIDED or INDETERMINATE.
A deny verdict is an evidence statement that at least one dimension failed; it does not by itself require any particular remediation.
Enforcement policy (Layer 3) is external to CCS.

This resolves the recurring ambiguity in which "verdict=allow" could be read as "the action is authorised." The verdict is one input into the relying party's authorisation decision, not the decision itself.

Each conformance rule in the CCS security rule set (the eight input rules SEC-001 through SEC-008 and the eight output rules OUT-001 through OUT-008) is expressed as a structural existence test. A structural test is one whose outcome depends only on the presence, absence, or literal shape of fields and values, and not on a qualitative judgement. For each rule, two positions are specified:

Trigger: the exact structural condition under which the rule fires, expressed as a literal predicate over the canonical request.
Scope: the exact set of inputs to which the rule applies, expressed as a closed enumeration or a literal membership test.

Both positions MUST be free of implementer-judgement language. Appendix E lists the trigger and scope for each of the 16 rules.

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: Figure 5

Field	Type	Required	Description
rules	array of strings	MUST	Ordered list of rule 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 (enum)	MUST	'in-process' or 'out-of-process'.
manifest_hash	string	SHOULD	SHA-256 hash of the verifier capability manifest (Section 4.6) at time of issuance.

Example canonical config:

The canonical configuration MUST be serialized using JSON Canonicalization Scheme (JCS) as defined in [RFC8785]: bytes: return json.dumps( config, sort_keys=True, separators=(",", ":"), ensure_ascii=False, allow_nan=False ).encode("utf-8") ]]> Key properties:

Keys are sorted lexicographically.
No whitespace between tokens (compact form).
Non-ASCII characters are emitted as UTF-8 per RFC 8785 JCS.
NaN and Infinity are not permitted.

The config_hash is computed as: 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.

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.

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: bytes: return json.dumps({ "agent_id": command.agent_id, "tool": command.tool, "params": command.params, "timestamp": command.timestamp, "trace_id": command.trace_id, }, sort_keys=True, separators=(",", ":")).encode("utf-8") request_hash = "sha256:" + hashlib.sha256(canonical_bytes(command)).hexdigest() ]]> Binding strength: The request_hash changes if any material field of the request changes. Status: Implemented in ccs-verifier 0.4.1.

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: Where response_bytes is the exact byte representation of the tool's response. For structured responses, the canonical JSON serialization MUST be used. Timing: The response_hash MUST be computed after the tool invocation completes. See Section 4.2 (Receipt lifecycle) for the two-phase durability model. Status: Implemented in ccs-verifier 0.4.1.

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.). Binding strength: Prevents a receipt issued in one environment from being replayed in another. Status: Implemented in ccs-verifier 0.4.1.

Purpose: Provide a CAID-compatible action identifier that enables the CCS receipt to participate in the AEB's CAID matching process. Mechanism: Where {tool_name} is the tool name from the Command and {params_hash} is the full SHA-256 hex digest (not truncated) of the canonical parameters. For EC integration, this action identifier MUST be mappable to a CAID action-type definition [I-D.schrock-canonical-action-identifier] via a relying-party-pinned mapping profile, following the CAID MATCH processing specified in Section 5.3 of [I-D.schrock-action-evidence-boundary]. Status: Implemented in ccs-verifier 0.4.1 (14 enum values).

Purpose: Bind the receipt to the exact tool parameters. Mechanism (Implemented in 0.4.1): 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.

Purpose: Identify the verifier that produced the receipt. Mechanism: The issuer field is a URI that identifies the verifier instance. The URI MUST be stable across key rotations. The issuer identifier MUST be covered by the signing mechanism so that an attacker cannot substitute a different issuer without invalidating the receipt. Status: Implemented in ccs-verifier 0.4.1.

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.

Purpose: Prevent replay of previously-issued receipts. Mechanism: The nonce field is a cryptographically random, single-use value: 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).

Purpose: Bound the temporal validity of the receipt. Mechanism: Three fields work together to enforce freshness:

issued_at: Unix timestamp when the receipt was issued.
expires_at: Unix timestamp after which the receipt MUST NOT be accepted.
max_clock_skew: Maximum acceptable clock skew in seconds. Default: 30.0 seconds.

Validation algorithm: 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.

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 using the trace_id and timestamp.
Durable record: The receipt survives transport, retries, and principal changes.

HMAC-SHA256 (Implemented in 0.4.1): The signing key MUST be generated using a cryptographically secure random number generator: 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.

Before a CCS receipt can be verified by a consumer, the consumer MUST have enrolled the verifier's key:

HMAC: The shared secret MUST be distributed via a secure channel. The key MUST NOT be transmitted in-band with the receipt.
Ed25519: The public key MUST be pinned by the consumer via an out-of-band mechanism. The key fingerprint (SHA-256 of the raw public key bytes) SHOULD be used as the signing_key_id.

Key rotation MUST follow a phased approach:

Announce: The verifier publishes the new key identifier and effective date.
Dual-sign: During the overlap window, receipts are signed with both old and new keys.
Cutover: After the overlap window, only the new key is used.
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).

A fundamental security property of CCS is the separation between the verifier (which evaluates rules and signs receipts) and the operator (the agent runtime that invokes tools).

In-process (0.4.1): The verifier and operator share the same address space. A compromised agent process CAN access the signing key. This is a known limitation.
Out-of-process (Implemented): The verifier runs in a separate process with its own memory space. The signing key is held only in the verifier process. A compromised agent process CANNOT access the signing key. This is the RECOMMENDED deployment mode for security-critical applications.

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: This is the fundamental difference from observer-pattern hooks (which fail-open when the observer crashes, as documented in [CWE-636]).

Verifier timeout: If the verifier does not respond within the configured timeout (default: 5000ms for out-of-process, unlimited for in-process), the invocation MUST be blocked. Receipt timeout: The expires_at field (Section 6.9) provides an upper bound on receipt validity. Both timeouts are independent and both MUST be enforced.

Figure 6

Property	In-Process	Out-of-Process
Process boundary	None (shared address space)	Full (separate process)
Signing key exposure	Vulnerable to agent compromise	Protected from agent compromise
Crash isolation	None (shared crash domain)	Full (verifier survives agent crash)
Latency	7.5us P50 (measured, 1000 iterations)	OOP Unix-socket P50 ~133us / TCP+TLS P50 ~200us (measured)
Implementation status	Implemented + tested (0.4.1)	Implemented + tested (0.4.1)
Conformance level	Level 0-1	Level 2-3

Note on performance: The P50/P99 latency figures above are informational measurements from the reference implementation. They are not normative requirements.

This section classifies verifiers by their provenance and the level of assurance a relying party SHOULD place in their verdicts.

A verifier whose rule set, signing key, and configuration are built, operated, and audited entirely by the relying party's own organization.

Full visibility into source code, rule definitions, and key management.
Independent verification of fail-closed semantics is possible.
The signing key is generated and held within the relying party's infrastructure.

Assurance: Highest. EC mapping: A Class A verifier's receipt is directly consumable as a policy-permit evidence component in an EC.

A verifier built by a third party but subjected to independent audit.

The source code is available for review.
An independent audit has verified the implementation matches the specification, particularly fail-closed semantics.
The audit report is available to the relying party.

Assurance: High, contingent on audit scope and freshness.

A verifier whose operator claims conformance to CCS but has not submitted to independent audit.

The operator declares conformance. No independent verification.
The relying party has no direct evidence of correct fail-closed semantics.

Assurance: Low. EC mapping: A Class C verifier's receipt MAY be consumed as evidence, but the relying party SHOULD weight it lower than Class A or Class B.

Level 0 -- Baseline (Implemented in 0.4.1): The verifier produces a signed receipt covering: trace_id, verdict, timestamp, tool, params_hash, rule_summary. Fail-closed enforcement is implemented. In-process deployment only. A Level 0 implementation satisfies the core tamper-evident audit requirement but does not provide the bindings necessary for EC composition. Level 1 -- Extended Bindings + Ed25519 Signing (Implemented in v0.4.1): In addition to Level 0, the verifier produces receipts with all 22 fields: request_hash, config_hash, response_hash, runtime_context_hash, action (CAID-compatible, 14 enum values), issuer, audience, nonce (UUID4-based), sequence, issued_at, expires_at, max_clock_skew, and signature. Ed25519 signing is supported as the primary signature algorithm alongside HMAC-SHA256. A Level 1 implementation provides all 22 fields required for EC composition, with Ed25519 signatures providing non-repudiation. Level 2 -- Out-of-Process Full Isolation: In addition to Level 1, the verifier operates out-of-process with Unix-socket or TCP+TLS transport. The signing key is held only in the verifier process. Cross-replica replay prevention is implemented via shared durable state. 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.

Level 4 -- Evidence Propagation: In addition to Level 3, the verifier supports cross-organization evidence propagation with chain integrity verification. The verifier produces Evidence Envelopes, maintains Evidence Chains, and supports offline chain verification. Level 4 requirements:

Evidence Intake Protocol compliance (Section 3).
Evidence Propagation support (Section 11).
Enforcement Interface compliance (Section 12).
Cross-org Evidence Profile support.
Chain integrity verification (full and spot).
EC summary hash computation.

A Level 4 implementation provides the highest assurance. Backward compatibility: All Level 0-3 implementations remain conformant. Level 4 is additive.

Each conformance vector is a self-contained test case that a conforming implementation MUST pass.

CV-001: Basic ALLOW receipt (Level 0): Input Command: agent_id: "test-agent", tool: "search_web", params: {"query": "weather in Tokyo"}. Expected: verdict: "allow", receipt: valid HMAC-SHA256 over the signed bytes.
CV-002: Basic DENY receipt (Level 0): Input Command: tool: "shell_exec", params: {"command": "rm -rf /"}. Expected: verdict: "deny", block_reason: non-empty, receipt: valid HMAC-SHA256 covering the deny verdict.
CV-003: Config hash binding (Level 1): Given two verifiers with different rule sets, when they verify the same command, then their config_hash values MUST differ.
CV-004: Request hash binding (Level 1): Given the same tool and rule set, when two commands differ only in params, then their request_hash values MUST differ.
CV-005: Issuer/audience binding (Level 2): Given a receipt with issuer="A" and audience="B", when consumer "C" receives the receipt, then consumer "C" MUST reject the receipt.
CV-006: Freshness enforcement (Level 2): Given a receipt with expires_at=T, when consumer receives the receipt at time T+1, then the consumer MUST reject the receipt.
CV-007: Intake fail-closed (Level 4): Given a malformed intake message, when submitted, then the verifier MUST return an INTAKE_MISSING_FIELD error, and no receipt MUST be produced.
CV-008: Evidence Envelope propagation (Level 4): Given a valid receipt from Agent A, when Agent A delegates to Agent B, then Agent B MUST receive an Evidence Envelope and produce its own receipt.
CV-009: Cross-org self-contained verification (Level 4): The envelope MUST contain all data necessary for verification without external lookups.
CV-010: EC summary hash (Level 4): The summary hash MUST be the SHA-256 digest of the concatenation of all receipt hashes in insertion order.

This section defines how evidence flows through multi-agent chains, across organizational boundaries, and accumulates across execution stages. It establishes "chain sovereignty."

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.
Indexed: Receipts MUST be indexed by trace_id for retrieval.
Durable: Receipts MUST be persisted to stable storage before the tool invocation proceeds.

Query interface: The local evidence store MUST support querying by trace_id, tool, verdict, and time_range. Ordering guarantee: The admission decision (pre-execution fields and verdict, as enumerated in Section 4.2, Receipt lifecycle) MUST be durable within the agent's local store before the tool invocation proceeds. The full 22-field receipt, including response_hash and field 22, is finalized after execution and then MUST be durably persisted.

A delegation chain has length zero when an agent acts on its own behalf with no upstream principal -- there is no delegator, no forwarded grant, and no prior receipt to inherit. Chain length 0 is a valid, non-error state. A conforming implementation MUST NOT require an upstream receipt at chain length 0 and MUST NOT treat a missing previous_receipt_hash as a verification failure. At chain length 0, the CCS receipt's own issuance event serves as the root of trust. Concretely, for a length-0 receipt:

previous_receipt_hash MUST be absent or an explicit zero value agreed by the profile.
hop_count MUST be 0.
chain_id MAY equal the receipt's own nonce.
The verifier MUST evaluate every requested dimension on the request itself.
The "No disposition authorises an action" rule (Section 4.7.3) applies unchanged.

When a length-0 agent later delegates to another agent, the next receipt has hop_count=1 and previous_receipt_hash set to the length-0 receipt's hash.

When Agent A delegates a task to Agent B, evidence MUST propagate with the delegation. Evidence Envelope: Fields:

envelope_version: The Evidence Envelope schema version. MUST be "1.3".
original_receipt: The complete CCS Receipt from the delegating agent.
parent_trace_id: The trace_id of the delegating agent's verification.
child_trace_id: The trace_id assigned to the receiving agent's verification.
delegation_reason: Human-readable reason for the delegation.
hop_count: The number of hops this evidence has traversed.
previous_receipt_hash: The SHA-256 hash of the delegating agent's receipt.

Propagation protocol:

Agent A receives a tool invocation request.
Agent A's verifier evaluates and produces Receipt_A.
Agent A delegates to Agent B, wrapping Receipt_A in an Evidence Envelope.
Agent B submits through its own intake (Section 3).
Agent B's verifier produces Receipt_B with previous_receipt_hash set to hash(Receipt_A).
Agent B MAY further delegate.

Maximum chain depth: Implementations SHOULD enforce a maximum hop_count of 16.

When evidence crosses organizational boundaries, additional requirements apply. Cross-Organization Evidence Profile: Cross-org evidence MUST include all of the following fields: Requirements:

sender_org_id: Identifier of the sending organization. MUST be a stable URI.
receiver_org_id: Identifier of the receiving organization. MUST be a stable URI.
trust_anchor_reference: SHA-256 fingerprint of the public key used to verify the receipt's signature.
self_contained: MUST be true. All verification data is included in the envelope; no external lookups are required.

Self-containment requirement: Cross-org evidence MUST be self-validating. The receiving organization MUST NOT need to make network calls to validate the evidence.

As evidence propagates through a chain, it accumulates. Each hop adds its receipt to the chain. Evidence Chain (EC) structure: Ordering: EC MUST maintain insertion order. No reordering is permitted. Pruning: EC MUST support pruning -- the removal of intermediate receipts while preserving chain integrity. Summary hash computation: Any change to any receipt in the chain produces a different summary hash.

Full verification: To verify the entire chain, for each receipt verify the signature, freshness, and chain linkage (if hop > 0), then verify the summary hash. Spot verification: To verify a subset of the chain, verify the receipt at the specified hop, the chain linkage, and the summary hash. Chain Verification Result: If the chain is broken: Offline verification: Chain verification MUST be possible offline (no network calls required). This is consistent with the self-containment requirement for cross-org evidence (Section 11.3).

This section defines how evidence is consumed by enforcement systems (such as AEB). It establishes "ecosystem sovereignty."

The enforcement input contract specifies the standard interface through which enforcement systems consume CCS evidence. Single receipt input -- Required for enforcement consumption:

verdict: The governance decision (allow/deny/escalate).
signature: The cryptographic signature (Ed25519 or HMAC).
action: The CAID-compatible action identifier.
params_hash: Hash of the tool parameters.
issuer: Identifier of the producing verifier.
audience: Identifier of the intended consumer.
issued_at / expires_at / max_clock_skew: Freshness parameters.
nonce: Anti-replay value.

Optional for enforcement consumption:

response_hash: Hash of the tool response.
runtime_context_hash: Hash of the execution environment.
chain_metadata: Evidence Envelope and EC information.
outcome_status: The epistemic state (confirmed/dispatched/indeterminate/unknown).

EC input: When consuming an Evidence Chain, the enforcement system receives the full EC structure (Section 11.4) and can additionally expect summary_hash and total_hops.

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. 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. Step 3: Signature verification. Step 4: Replay check. Step 5: Binding verification. Step 6: Outcome status mapping (Section 12.4).

When validation fails, the enforcement system signals the failure using a defined taxonomy. Figure 7

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.

Failure Report format:

This section defines how CCS outcome statuses map to enforcement decisions. Figure 8

Outcome Status	Enforcement Behavior
confirmed	Enforcement MAY proceed with the action.
dispatched	Enforcement MUST wait for reconciliation before finalizing.
indeterminate	Enforcement MUST treat as unverified and apply conservative policy.
unknown	Enforcement MUST NOT assume success or failure. Retry is permitted only with an idempotency key; non-idempotent actions MUST be surfaced for explicit resolution.

Combined verdict and outcome_status mapping: Figure 9

Verdict	Outcome	Enforcement Action	Rationale
allow	confirmed	Proceed	Full evidence
allow	dispatched	Proceed with reconciliation pending	Authorized but unconfirmed
allow	indeterminate	Apply conservative policy; may escalate	No outcome visibility
deny	confirmed	Block	Blocked locally
escalate	*	Defer to higher authority	Verifier cannot decide

This mapping aligns with the AEB draft terminology (INDETERMINATE, PROVISIONAL, lifecycle boundaries) as discussed with Iman Schrock (AEB-03).

A given security or correctness property MUST be tested by exactly one structural test across the entire conformance surface. If a property is checked at intake (Section 3) and again at enforcement (Section 12), the two checks MUST be the same test: same trigger predicate, same scope set, same pass/fail condition, same handling of the indeterminate case. The motivation is concrete. Earlier drafts contained a case in which a property was tested one way at L1 receipt validation, and then a weaker version of the same property governed exclusions at enforcement. An attacker who could not pass the strong test could satisfy the weak test via the exclusion path. Conformance rules for this section:

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.
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.
If an enforcement layer needs to apply a stricter policy than L1 validation, that is an enforcement policy choice and is permitted, but it MUST be expressed as policy on top of the shared test, not as a different test.
Exclusions and exceptions are themselves tests. A rule that says "X must hold, unless Y" defines two tests, and Y MUST meet the same structural-test discipline as X (Section 4.8).

Appendix E records, for each of the 16 rules, where its single authoritative test lives.

This section defines negative test cases that a conforming CCS implementation MUST detect and reject. These negative cases demonstrate that the bindings defined in Section 6 are load-bearing: removing any one binding reopens the corresponding attack.

Scenario: An attacker intercepts a valid receipt for tool invocation A, modifies the tool parameters, and presents the modified command with the original receipt. Expected receipt change: The params_hash (and request_hash at Level 1+) no longer matches the modified parameters. Expected verdict: DENY. Detection condition: Binding defeated if removed: params_hash binding (Section 6.5).

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: Binding defeated if removed: response_hash binding (Section 6.2).

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: Binding defeated if removed: nonce/sequence binding (Section 6.8).

Scenario: An attacker presents a receipt issued 24 hours ago for a time-sensitive action. Expected receipt change: The expires_at field has passed. Expected verdict: DENY (expired receipt). Detection condition: receipt.expires_at + receipt.max_clock_skew: return DENY ]]> Binding defeated if removed: freshness binding (Section 6.9).

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: Binding defeated if removed: audience binding (Section 6.7).

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: Binding defeated if removed: issuer binding (Section 6.6).

Scenario: The agent runtime and the verifier are operated by the same entity. The verifier always returns ALLOW. Expected receipt change: No change to the receipt. The receipt is valid but the rule evaluation is trivially permissive. Expected verdict: The receipt passes cryptographic verification, but the AEB SHOULD flag the verifier as Class C and apply additional scrutiny. Detection condition: 10000: flag_for_review(verifier) ]]> Binding defeated if removed: Independent auditing (Class B) or out-of-process deployment with independent operator.

Scenario: The verifier is configured for out-of-process deployment, but the transport is unavailable. The agent falls back to allowing the invocation without verification. Expected receipt change: No receipt is produced. Expected verdict: DENY. The fail-closed semantics (Section 8.1) mandate that the invocation MUST be blocked. Detection condition: Binding defeated if removed: Transport requirements (Section 8).

Scenario: An attacker submits malformed input to trigger an exception in the intake parser, hoping the system falls back to fail-open. Expected receipt change: The intake returns an IntakeError and no receipt is produced. Expected verdict: DENY. The caller MUST treat absence of a receipt as denial. Detection condition: Binding defeated if removed: Intake fail-closed semantics (Section 3.3).

Scenario: An attacker attempts to insert, remove, or modify a receipt in an Evidence Chain. Expected receipt change: The chain linkage (previous_receipt_hash) breaks at the tampering point; the summary hash changes. Expected verdict: The chain verification (Section 11.5) detects the tampering and returns chain_valid=false. Detection condition: Binding defeated if removed: Chain integrity verification (Section 11.5).

Scenario: An attacker strips the signature from a cross-org envelope, hoping the receiving organization skips verification. Expected receipt change: The envelope lacks the data required for self-contained verification. Expected verdict: The receiving organization MUST reject the envelope as not self-contained. Detection condition: Binding defeated if removed: Cross-Organization Propagation (Section 11.3).

Truncated hashes. The 0.4.1 implementation truncates params_hash to 16 hex characters (64 bits) and receipt to 32 hex characters (128 bits). Implementations targeting cross-deployment interoperability SHOULD use full-length digests.
HMAC key exposure in in-process mode. When the verifier runs in the same process as the agent, a compromised agent can read the signing key from memory. Out-of-process deployment mitigates this.
Float timestamp precision. The timestamp and verified_at fields use Python floats (IEEE 754 double precision). Implementations SHOULD use monotonic clocks for latency measurement and wall clocks only for issuance timestamps.
JSON canonicalization. The params_hash and config_hash depend on deterministic JSON serialization. Implementations MUST use the canonical serialization specified in Section 4.2 and Section 5.2.
Rule evaluation ordering. The config_hash binding (Level 1+) addresses this by binding the receipt to the exact rule set.
TOCTOU in out-of-process mode. The runtime_context_hash (Level 2) mitigates this by binding the receipt to the context at verification time.
Verifier policy floor degradation. A Class C verifier may declare a weaker policy floor. Mitigation: independent auditing (Class B) or out-of-process deployment with independent operator.
Outcome status confusion. Implementations MUST NOT treat outcome_status as a verdict or use it to override the verdict decision.
Cross-organization evidence leakage. When evidence propagates across organizational boundaries, the Evidence Envelope contains the full receipt. Implementations SHOULD consider data minimization; any omitted field MUST NOT break signature verification.
Cross-org replay. A receipt issued for organization A might be replayed against organization B. Mitigation: the audience binding (Section 6.7) MUST be enforced at each organizational boundary.
Chain integrity attacks. An attacker who controls the verifier at a single hop can produce a valid receipt for that hop, but the evidence at that hop is fraudulent. Mitigation: Class B or Class A verification at every hop.
Intake fail-closed bypass. The fail-closed invariant (Section 3.3) ensures that no receipt is produced on failure. Implementations MUST ensure the intake error handling code path does not contain any fallback that allows the invocation to proceed.
Enforcement interface confusion. The Enforcement Interface (Section 12.4) defines an explicit mapping table that MUST be followed. Implementations MUST NOT allow custom mappings that weaken the enforcement guarantees.
Evidence accumulation overflow. The maximum hop_count (recommended: 16, Section 11.2) limits chain length. Implementations SHOULD enforce this limit.
Trust anchor compromise in cross-org scenarios. Implementations MUST support revocation of trust anchors and MUST re-validate in-flight evidence when a trust anchor is revoked.

This document does not request any IANA allocations.

CCS v1.3 Receipt Field Summary

#	Field	Type	Level	Status	Signed	Description
1	trace_id	16-char hex	0	Implemented	Yes	Unique event identifier
2	verdict	enum string	0	Implemented	Yes	allow / deny / escalate
3	timestamp	float	0	Implemented	Yes	Verification time
4	tool	string	0	Implemented	Yes	Tool name
5	params_hash	16-char hex	0	Implemented	Yes	SHA-256 of params, truncated
6	rule_summary	string	0	Implemented	Yes	Pipe-delimited rule results
7	receipt	32-char hex	0	Implemented	N/A	HMAC-SHA256 signature
8	verified_at	float	0	Implemented	No	Verification timestamp
9	block_reason	string	0	Implemented	No	Deny/escalate reason
10	request_hash	hex string	1	Implemented	Yes	SHA-256 of full request
11	config_hash	hex string	1	Implemented	Yes	SHA-256 of canonical config
12	response_hash	hex string	1	Implemented	Post-hoc	SHA-256 of response
13	runtime_context_hash	hex string	1	Implemented	Yes	SHA-256 of runtime context
14	action	string	1	Implemented	Yes	CAID-compatible action ID
15	issuer	URI string	1	Implemented	Yes	Verifier identifier
16	audience	URI string	1	Implemented	Yes	Intended consumer
17	nonce	hex string	1	Implemented	Yes	Single-use 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 hex	1	Implemented	Yes	Ed25519 signature over canonical JSON

This appendix maps CCS receipt fields and protocol mechanisms to the requirements expressed in draft-feng-agentproto-session-requirements-01. The mapping is informative, not normative on either document.

REQ-5 requires that a session carry verifiable evidence that an action was authorized, such that the authorization decision cannot be silently substituted after the fact. CCS satisfies this via:

The action binding (Section 6.4): the receipt binds the verdict to the exact CAID-compatible action identifier and canonical parameters.
The Ed25519 signature over the canonical signed bytes (Section 4.2): the verifier that issued the verdict is identified by the issuer field and cannot repudiate the decision.
The config_hash (Section 5.3): the exact rule set under which the verdict was reached is hash-bound.
The freshness binding (Section 6.9): issued_at, expires_at, and max_clock_skew prevent long-term replay.

REQ-7 requires that evidence of an action and its authorization be non-repudiable and independently verifiable by a party that was not present at decision time. CCS satisfies this via:

Offline verification (Section 11.5): all data necessary to verify a receipt is present in the EC structure.
Verifier source classification (Section 9): third parties can distinguish Class A, B, and C verifiers.
The capability manifest (Section 4.6) and its profiles_digest binding.
Audit-grade signatures: conforming deployments at Level 2 and above use Ed25519 rather than HMAC.

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.

This appendix maps CCS receipt fields to the W3C PROV vocabulary. The mapping is informative.

W3C PROV Field Mapping

CCS field	W3C PROV concept	Notes
receipt (signed)	prov:Entity	The evidence artifact.
issuer	prov:wasAttributedTo	The verifier that produced it.
action	prov:wasGeneratedBy	The activity (tool invocation) that generated the evidence.
request_hash	prov:specializationOf	Binds the evidence to the exact request entity.
response_hash	prov:wasDerivedFrom	Binds to the response entity.
issued_at	prov:generatedAtTime	Issue timestamp.
expires_at	(provenance validity)	Expiry of the evidence as an authorization input.
previous_receipt_hash (chain)	prov:wasDerivedFrom	Chain linkage in multi-agent propagation.
Ed25519 signature (envelope)	(signature)	Integrity and non-repudiation over the entity.

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.

This appendix records the result of the double-position audit required by Section 4.8. Each of the 16 CCS security rules is stated with its trigger and its scope, and the single location of its authoritative test per Section 12.5.

Input Rules (SEC-001..SEC-008)

Rule	Trigger (structural)	Scope (closed set)	Test
SEC-001	request contains an absolute URL-valued argument whose host resolves to a private/link-local/loopback address	arguments of any tool	Section 3.3
SEC-002	argument string matches command-injection structural pattern with chain score at or above threshold	arguments of tools in COMMAND_EXECUTION_TOOL set (closed list)	Section 4.7
SEC-003	argument contains a value matching a deployed secret regex	network-facing tool arguments destined for a network-facing tool	Section 4.7
SEC-004	argument path contains a traversal sequence targeting a blocked absolute path	path-valued arguments of any tool	Section 4.7
SEC-005	tool name is in destructive set and request lacks an explicit human-approval attestation	tool name	Section 4.7
SEC-006	argument string, when parsed as a shell command, contains a non-heredoc download-to-execute chain	arguments of command-execution tools	Section 4.7
SEC-007	request omits a required canonical field	presence of required field in canonical request	Section 3.2
SEC-008	canonical config hash does not match a pinned value	config_hash value compared to pinned set	Section 5.3

Output Rules (OUT-001..OUT-008)

Rule	Trigger (structural)	Scope (closed set)	Test
OUT-001	output content contains a credential pattern destined for a network sink	output text from network-facing tools	Section 12.2
OUT-002	output content matches prompt-injection structural pattern above threshold	output text from any tool	Section 12.2
OUT-003	output from a network-fetch tool contains a literal instruction pattern that addresses the agent system prompt	output of tools in the NETWORK_FETCH_TOOL set	Section 12.2
OUT-004	output content length exceeds declared max_size	output metadata	Section 3.4
OUT-005	output content_type does not match declared schema	output metadata	Section 3.4
OUT-006	output contains a chain linkage that does not verify against previous_receipt_hash	output text from any tool	Section 12.2
OUT-007	output carries an outcome_status outside the closed enum	output metadata	Section 12.4
OUT-008	output signature does not verify under issuer key	signature field	Section 4.2

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.

This appendix is informative. It documents implementation experience from two source-available deployments of CCS.

dsh-ccs-security is a runtime plugin for the DeepSeek Harness agent framework that enforces CCS checks in-process. It exercises the evidence-plane/enforcement-plane separation described in Section 4.7.3. Two implementation observations informed this revision:

Tool-aware enforcement. Applying a single command-injection threshold to every tool's string arguments caused false positives when the agent wrote documentation containing shell examples. The fix classifies tools: command-execution tools are scanned at the strict threshold; data tools are scanned at a raised threshold or audited only.
Output-side source classification. Scanning every tool's output for prompt-injection patterns blocked reads of the plugin's own test fixtures. The fix distinguishes trusted local read from untrusted network fetch.

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.

The two deployments together confirm that the evidence/enforcement separation is not merely theoretical: when the same component both records evidence and decides enforcement, false positives become self-fulfilling. Separating the two, with the evidence plane fail-closed and the enforcement plane policy-driven, yields a system that is both auditable and usable.

During a watchdog-driven hot-reload of the dsh-ccs-security plugin, the supervising process terminated running tool invocations before their results could be durably recorded. The CCS receipts had already been persisted, but the post-execution outcome was lost. This incident motivated the outcome_status=unknown state added in Section 4.5. Three implementation lessons follow:

The evidence plane must write the receipt before the enforcement plane acts, and the write must be independent of the tool process lifecycle.
A watchdog or hot-reload mechanism MUST implement graceful shutdown for active tool calls.
The distinction between indeterminate and unknown is not academic. An unknown receipt requires explicit action (idempotent retry or human resolution) because the verifier has positive evidence that the execution did not complete.

The EMILIA Protocol project implemented an independent CCS-05 v1.3 AEB interoperability profile, merged as commit 5fb2eae9b20d17685e1ecbe061eb4ced03dbe64e (PGP-signed, verified). This implementation was developed independently of the Correctover reference codebase and validates the CCS-05 v1.3 receipt profile directly against the draft bytes. The profile exercises 14 conformance checks:

Source pin: draft-correctover-ccs-05.txt pinned by SHA-256 digest c91f0fa31b1b9e5e2dfe79b99f3b554075d3a44d5309406e748b728f86767cb9.
Separation from 1.1.14 package shape: the v1.3 receipt is structurally distinct from the ccs-verifier 1.1.14 receipt version 1.1 shape.
Live response binding: response_hash binds to actual tool output.
Ed25519 verification: signature verifies under an RP-pinned public key derived from a deterministic test seed.
Exact-action CAID mapping: the signed full parameter digest maps to the executor-constructed CAID without field guessing.
Signature mutation: any modification to the signature bytes fails verification.
Untrusted key: a receipt signed by a key not in the RP pin set is rejected.
Audience binding: receipts issued for a different audience are rejected.
Freshness: expired receipts are rejected.
Parameter substitution: changing any parameter value changes the params_hash and fails verification.
Full-digest substitution: the 16-hex params_hash prefix correctly binds to the full SHA-256 parameter digest.
Consumed status: one-time-use receipts cannot be replayed.
Unavailable status: receipts for unavailable resources are handled distinctly from consumed.
Native deny non-authorizing: a CCS DENY verdict remains an evidence statement and does not constitute authorization, consistent with Section 4.7.3.

The 22-field v1.3 receipt uses a deterministic Ed25519 key pair derived from the seed 'emilia/ccs-05-v1.3-independent-interop/v1'. The signature is a detached Ed25519 signature over the RFC 8785 canonical JSON of the other 21 fields, consistent with Section 4.2. This implementation confirms that the CCS-05 v1.3 receipt specification is sufficient for independent implementation without reference to the author's codebase.

Each conformance test vector is encoded as a JSON object: For negative test vectors: For Level 4 propagation test vectors: