]> Correctover

Xiamen, Fujian China https://example.com

Internet Engineering Task Force The Correctover Conformance Shape (CCS) defines a tamper-evident receipt schema and a set of cryptographic bindings that together constitute a verifiable conformance record for an agent runtime's decision to permit, deny, or escalate a tool invocation. CCS is designed as a one-receipt-per-invocation object that can be consumed by an executor-side Action Evidence Boundary (AEB), providing the request_hash, response_hash, runtime_context_hash, action binding, params_hash binding, issuer, audience, nonce/sequence, freshness, and config_hash fields that the AEB processing model requires as native inputs. This document specifies the CCS Receipt Schema, the Canonical Configuration model, the nine binding mechanisms, key management, transport requirements, verifier source classification, conformance levels, and negative test cases. It is intended to enable a reader such as the author of the Action Evidence Boundary specification to evaluate whether and how a CCS receipt can be mapped into an Authorization Evidence Chain (AEC) component.

Introduction The Correctover Conformance Shape (CCS) is a receipt-and-binding specification that produces a single, tamper-evident, cryptographically bound artifact for every tool invocation decision made by an agent runtime's governance layer. A CCS receipt answers: "Given this exact request, this exact configuration, this exact runtime context, and this exact set of rules, the verifier decided ALLOW/DENY/ESCALATE, and here is the proof." CCS is not a policy language, an authorization framework, or a transport protocol. It is the _shape_ of the evidence that a verifier produces when it finishes evaluating a command. This evidence is intended to be consumed by downstream systems — including an executor-side Action Evidence Boundary (AEB) as defined in — as one native artifact within a larger Authorization Evidence Chain (AEC). The initial reference implementation (ccs-verifier 0.2.0) 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 requires from a native artifact: request binding, response binding, runtime context binding, issuer/audience, freshness, nonce, and canonical configuration.

Scope CCS specifies:

• A receipt schema () that binds a verdict to the exact invocation context.
• A canonical configuration model () that binds the receipt to the exact rule set and policy under which verification occurred.
• Nine binding mechanisms () that connect the receipt to the request bytes, response bytes, runtime context, action identity, parameter identity, issuer, audience, nonce, and freshness window.
• Key management requirements ().
• Transport requirements () including fail-closed semantics.
• Verifier source classification ().
• Conformance levels and test vectors ( and ).

CCS does NOT define:

• A new authorization receipt format that replaces or competes with . CCS is a _verifier-side decision record_, not an organizational authorization artifact.
• A policy language. Rules are pluggable; CCS specifies how rule outcomes are recorded and bound, not what the rules are.
• A transport protocol for inter-process communication. The reference implementation uses in-process function calls; a gRPC transport is specified at the interface level but not yet implemented.
• A universal evidence taxonomy. CCS defines one artifact shape for one class of decision (tool-invocation governance).

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(τ) ⊆ Supported(τ) 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, Reproducibility, Compliance) and the six-dimensional verification model (Structure, Schema, Latency, Cost, Identity, Integrity).

A PANW contributor cited CCS DOI in a fork of Palo-Alto-AI-Research- Lab/semantic-kernel (PR #14199, closed by Microsoft). This citation is noted as evidence of external interest in the CCS DOI; it does not constitute adoption by Microsoft or the Semantic Kernel project.

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

CCS Receipt Schema

Field Definitions A conforming CCS Receipt is a JSON object conforming to I-JSON . The following table defines each field. Fields marked "Implemented" are present in ccs-verifier 0.2.0. Fields marked "Specified, not yet implemented" are defined by this specification but are not yet present in the 0.2.0 reference implementation.

Signed Bytes The receipt field in the 0.2.0 reference implementation is computed by the sign_receipt function as follows: *Signing payload construction (0.2.0, 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.2.0, 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 (Specification, for AEC mapping):* When the extended fields (, "Specified, not yet implemented") are present, the signing payload MUST be extended to include them: The extended receipt MUST use HMAC-SHA256 with the same truncation (32 hex chars) or MUST use Ed25519 as specified in , with the full 64-byte hex digest. *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.

Receipt JSON Example The following is an example CCS receipt as produced by ccs-verifier 0.2.0 (Implemented fields only): The following example shows the extended receipt with AEC-mappable fields (Specified, not yet implemented):

Canonical Configuration

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:

Example canonical config:

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

• Keys are sorted lexicographically.
• No whitespace between tokens (compact form).
• ASCII-only encoding with \uXXXX escapes for non-ASCII.
• NaN and Infinity are not permitted (must serialize as strings or reject).

Config Hash The config_hash is computed as: The config_hash MUST be included in the extended signing payload () when the extended fields are in use. This 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.

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 , enabling the CCS receipt to participate in CAID matching (Section 5.3 of ) and AEC evidence satisfaction (Section 5.4 of ).

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. The canonical bytes are defined as the Command.canonical_bytes() output from the reference implementation: 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 — the tool name, the parameters, the agent_id, or the trace_id. An attacker who modifies the request after verification will produce a different request_hash, breaking the binding. *Status:* Specified, not yet implemented in ccs-verifier 0.2.0. The 0.2.0 implementation binds via params_hash (16-char truncation) which covers only the parameters, not the full request context.

response_hash Binding *Purpose:* Bind the receipt to the exact response produced by the tool invocation. *Mechanism:* After the tool is invoked and a response is produced, the verifier (or a post-invocation hook) MUST compute: Where response_bytes is the exact byte representation of the tool's response. For string responses, this is the UTF-8 encoding. For structured responses, the canonical JSON serialization MUST be used. *Binding strength:* The response_hash enables a downstream consumer to verify that the response they received is the same response that was observed at verification time. If the response is modified in transit, the hash will not match. *Timing:* The response_hash MUST be computed after the tool invocation completes. It is appended to the receipt as a post-hoc binding, not part of the pre-invocation signed bytes. If the response_hash is absent, the receipt still covers the pre-invocation decision but does not bind to the response. *Status:* Specified, not yet implemented.

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: *Binding strength:* Prevents a receipt issued in one environment (e.g., staging) from being replayed in another (e.g., production). The receipt is bound to the exact runtime context in which verification occurred. *Status:* Specified, not yet implemented.

action Binding *Purpose:* Provide a CAID-compatible action identifier that enables the CCS receipt to participate in the AEB's CAID matching process ( ). *Mechanism:* The action field is a string identifier constructed as: For AEC 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), and any additional fields the relying party considers material.

*Status:* Specified, not yet implemented.

params_hash Binding *Purpose:* Bind the receipt to the exact tool parameters. *Mechanism (Implemented in 0.2.0):* str: return hashlib.sha256( json.dumps(params, sort_keys=True, separators=(",", ":")).encode() ).hexdigest()[:16] ]]> The 0.2.0 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 for params_hash. *Status:* Implemented (16-char truncation) in 0.2.0.

issuer Binding *Purpose:* Identify the verifier that produced the receipt, enabling the AEB to dispatch verification to the correct native verifier adapter ( ). *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 (HMAC or Ed25519) so that an attacker cannot substitute a different issuer without invalidating the receipt. *Status:* Specified, not yet implemented.

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. This prevents an attacker from presenting a receipt intended for one executor to a different executor. *Status:* Specified, not yet implemented.

nonce/sequence Binding *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:

• 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: a receipt with sequence number N MUST NOT be accepted if a receipt with sequence number N+1 has already been accepted from the same issuer.

*Status:* Specified, not yet implemented.

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 between the issuer and the consumer. 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. The exact window depends on the risk profile of the action being governed. *Status:* Specified, not yet implemented.

Key Management

Key Generation *HMAC-SHA256 (Implemented in 0.2.0):* 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 (Specification, for cross-domain verification):* For deployments where the verifier and consumer are in separate trust domains (e.g., out-of-process verification across organizational boundaries), Ed25519 key pairs SHOULD be used: The private key signs the receipt; the public key is distributed out- of-band for verification. This prevents the consumer from forging receipts.

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 (configuration file, environment variable, or trust anchor store). The key fingerprint (SHA-256 of the raw public key bytes) SHOULD be used as the signing_key_id.

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. The receipt field contains the signature under the current key; an additional receipt_prev field contains the signature under the previous key.
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) to ensure no unexpired receipts are left without a valid key.

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.2.0):* 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 documented in the reference implementation. *Out-of-process (Specified):* 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.

Transport Requirements

Fail-Closed Semantics CCS enforcement MUST be fail-closed. This is the core security guarantee, derived from the formal framework 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.2.0:* 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. This is the fundamental difference from observer-pattern hooks (which fail-open when the observer crashes, as documented in ).

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 () 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. A receipt that was issued quickly but has since expired MUST still be rejected.

In-Process vs Out-of-Process Deployment

*Note on performance:* The P50/P99 latency figures above are informational measurements from the reference implementation and early deployments. They are not normative requirements. Actual latency depends on hardware, operating system, rule complexity, and deployment configuration.

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

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

• The relying party has full visibility into the source code, rule definitions, and signing key management.
• The relying party can independently verify that the verifier implements fail-closed semantics correctly.
• The signing key is generated and held entirely within the relying party's infrastructure.

*Assurance:* Highest. The relying party trusts the verifier because they built it and control every aspect of its operation. *AEC mapping:* A Class A verifier's receipt is directly consumable as a policy-permit evidence component in an AEC, subject to CAID matching.

Class B: Audited Verifier A verifier built by a third party but subjected to independent audit by the relying party or a trusted auditor. *Properties:*

• The source code is available for review (may be open source or provided under NDA).
• An independent audit has verified that the implementation matches the specification, particularly fail-closed semantics and signing correctness.
• The audit report is available to the relying party.

*Assurance:* High, contingent on audit scope and freshness. The relying party trusts the verifier because a trusted auditor has verified it. *AEC mapping:* A Class B verifier's receipt is consumable as a policy-permit evidence component, but the relying party SHOULD document the audit basis and any residual risk.

Class C: Self-Declared Verifier A verifier whose operator claims conformance to CCS but has not submitted to independent audit. *Properties:*

• The operator declares that the verifier implements CCS correctly.
• No independent verification of the implementation has occurred.
• The relying party has no direct evidence that fail-closed semantics are correctly implemented.

*Assurance:* Low. The relying party trusts the verifier based on the operator's assertion alone. *AEC mapping:* A Class C verifier's receipt MAY be consumed as evidence, but the relying party's AEC requirement SHOULD weight it lower than Class A or Class B. A relying party with a strict evidence policy MAY reject Class C receipts entirely.

Conformance Levels

Level 0-3 Definitions *Level 0 — Baseline (Implemented in 0.2.0):* 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 AEC composition. *Level 1 — Extended Bindings:* In addition to Level 0, the verifier produces receipts with: request_hash, config_hash. The receipt binds to the exact request bytes and the exact configuration. A Level 1 implementation provides stronger replay resistance (via request_hash) and configuration binding (via config_hash). *Level 2 — Full AEC Readiness:* In addition to Level 1, the verifier produces receipts with: response_hash, runtime_context_hash, action (CAID-compatible), issuer, audience, nonce, sequence, issued_at, expires_at, max_clock_skew. Ed25519 signing is supported as an alternative to HMAC. A Level 2 implementation provides all bindings necessary for the receipt to be consumed as a native artifact by an AEB per . *Level 3 — Out-of-Process with Full Isolation:* In addition to Level 2, the verifier operates out-of-process with a fully implemented gRPC transport. The signing key is held only in the verifier process. Cross-replica replay prevention is implemented via shared durable state. A Level 3 implementation provides the strongest security guarantees: process isolation, key protection, and distributed replay prevention.

Conformance Vectors (Positive Test Cases) Each conformance vector is a self-contained test case that a conforming implementation MUST pass. *CV-001: Basic ALLOW receipt (Level 0)* *CV-002: Basic DENY receipt (Level 0)*

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

Negative Test Cases This section defines eight 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 are designed to demonstrate that the bindings defined in are load-bearing: removing any one binding reopens the corresponding attack.

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+) in the receipt no longer matches the modified parameters. The HMAC verification fails because the signed bytes have changed. *Expected verdict:* DENY. *Detection condition:*

Changed Response *Scenario:* An attacker intercepts the tool's response, modifies it, and presents the modified response to the downstream consumer along with the original receipt. *Expected receipt change:* The response_hash in the receipt no longer matches the modified response bytes. *Expected verdict:* The receipt is still valid for the pre-invocation decision (the verifier did allow the invocation), but the downstream consumer detects the response mismatch and rejects the response. *Detection condition:* *Note:* This is a post-invocation binding. The 0.2.0 implementation does not include response_hash; the attack is undetectable at Level 0.

Replay *Scenario:* An attacker captures a valid receipt for a one-time action (e.g., "transfer $100 to account X") and replays it to authorize a second invocation of the same action. *Expected receipt change:* The nonce in the receipt 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 (). *Note:* The 0.2.0 implementation does not include nonce; replay detection is not possible at Level 0 except via the in-process audit log (which is not durable across restarts).

Stale Evidence *Scenario:* An attacker presents a receipt that was issued 24 hours ago for a time-sensitive action (e.g., a stock trade). *Expected receipt change:* The expires_at field in the receipt has passed. *Expected verdict:* DENY (expired receipt). *Detection condition:*

if current_time > receipt.expires_at + receipt.max_clock_skew:

return DENY

*Binding defeated if removed:* freshness binding (). *Note:* The 0.2.0 implementation does not include expires_at; stale receipts are not detectable at Level 0.

Wrong Audience *Scenario:* An attacker obtains a receipt intended for Executor A and presents it to Executor B, hoping that Executor B will accept it as authorization for the same action. *Expected receipt change:* The audience field in the receipt identifies Executor A, not Executor B. *Expected verdict:* DENY (audience mismatch). *Detection condition:*

if receipt.audience != expected_audience:

return DENY

*Binding defeated if removed:* audience binding (). *Note:* The 0.2.0 implementation does not include audience; cross- executor receipt misdirection is not detectable at Level 0.

Key Substitution *Scenario:* An attacker generates their own signing key, produces a forged receipt with a fraudulent verdict, and presents it along with the attacker's public key. *Expected receipt change:* The receipt's issuer field identifies the attacker's key, which 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 (). *Note:* At Level 0 with HMAC, key substitution requires the attacker to know the shared secret. At Level 2+ with Ed25519, key substitution is detectable via the issuer/audience bindings.

Verifier/Runtime Collusion *Scenario:* The agent runtime and the verifier are operated by the same entity. The verifier is configured to always return ALLOW, regardless of the command. The receipts are technically valid (correct HMAC, correct bindings) but the governance is meaningless. *Expected receipt change:* No change to the receipt itself. 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 (self-declared) and apply additional scrutiny. *Detection condition:*

if verifier.deny_rate < 0.001 and verifier.total_receipts > 10000:

flag_for_review(verifier)

*Mitigation:* This is not a cryptographic attack; it is a governance failure. Mitigation requires:

• Independent auditing of the verifier's rule set (Class B).
• Out-of-process deployment with the verifier operated by a different organization than the runtime (Class A, independent operator).
• Statistical monitoring of verifier verdict distributions.

Missing Transport *Scenario:* The verifier is configured for out-of-process deployment, but the gRPC transport is not implemented or is unavailable. The agent runtime falls back to allowing the tool invocation without verification. *Expected receipt change:* No receipt is produced. The tool invocation proceeds without governance. *Expected verdict:* This is a fail-open condition. A conforming implementation MUST block the tool invocation (fail-closed). *Detection condition:* *Binding defeated if removed:* Fail-closed semantics (). *Note:* The 0.2.0 reference implementation correctly implements fail- closed for in-process verification. The out-of-process transport is a stub that raises NotImplementedError, which is caught by the fail- closed wrapper and blocks the invocation. However, a deployment that patches around the NotImplementedError would create a fail-open vulnerability.

Security Considerations *Truncated hashes.* The 0.2.0 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 but is not yet fully implemented. *Float timestamp precision.* The timestamp and verified_at fields use Python floats (IEEE 754 double precision). This provides approximately 15-17 significant decimal digits, which is sufficient for microsecond precision at current epoch values but MAY lose precision for comparisons between very close timestamps. Implementations SHOULD use monotonic clocks (time.perf_counter()) for latency measurement and wall clocks (time.time()) only for issuance timestamps. *JSON canonicalization.* The params_hash and config_hash depend on deterministic JSON serialization. Any difference in serialization (different key ordering, different whitespace handling, different Unicode encoding) produces a different hash. Implementations MUST use the canonical serialization specified in and . *Rule evaluation ordering.* The rule_summary field records rules in evaluation order. Because DENY short-circuits evaluation, two receipts for the same command MAY have different rule_summary values if the rule set changes between invocations. The config_hash binding (Level 1+) addresses this by binding the receipt to the exact rule set. *TOCTOU in out-of-process mode.* Between the time the verifier evaluates a command and the time the agent executes the tool, the runtime environment may change. The runtime_context_hash (Level 2) mitigates this by binding the receipt to the context at verification time; any subsequent context change invalidates the binding. *Receipt chaining.* This specification does not define receipt chaining (each receipt is independent). Implementations that require ordered audit trails SHOULD use the sequence field () or implement external chaining (e.g., hash-chain the receipts in the audit log).

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Informative References EMILIA Protocol, Inc. Consequential agent actions can cross identity, transport, authorization, policy, and execution systems. Each system can produce a valid artifact while the executor still lacks a safe rule for joining the artifacts to the exact effect, consuming one-time authority, and handling an uncertain outcome. This document defines the Action Evidence Boundary (AEB), an executor-side processing model for that lifecycle. AEB requires native artifact verification, Canonical Action Identifier (CAID) matching, Authorization Evidence Chain (AEC) satisfaction, a separate local authorization decision, durable atomic consumption or reservation, invocation, closed effect outcomes, and authenticated reconciliation. It defines no receipt or token format, no policy language, no universal evidence taxonomy, and no new registry. Native workload credentials, message signatures, attested per-action tokens, permit records, authorization receipts, and status mechanisms retain their own semantics and verifiers. EMILIA Protocol, Inc. This document defines the EMILIA Protocol (EP) authorization receipt, an evidence artifact binding an enrolled approver key to one canonical action before execution. An approver-held key signs an Authorization Context containing the action hash, policy reference, nonce, audience, and validity window. A Trust Receipt carries the signed contexts, terminal consumption record, and Merkle inclusion material so a relying party can verify the recorded event offline under independently selected log, directory, policy, and approver trust inputs. The receipt establishes only the guarantees of the selected verification profile. The mapping from an enrolled approver identifier to a natural person is asserted by the directory authority. Offline verification does not establish current revocation status, global non-replay, comprehension, legality, safety, or execution. Replay prevention requires an online atomic consumption store at the executor. The state-machine invariants are machine-checked under the assumptions stated in this document.

CCS v1.2 Receipt Field Summary Table

Conformance Test Vector Format Each conformance test vector is encoded as a JSON object: