Independent T. Farley Internet-Draft ScopeBlind (Veritas Acta) Intended status: Informational 26 March 2026 Expires: 27 September 2026 Signed Decision Receipts for Machine-to-Machine Access Control draft-farley-acta-signed-receipts-00 Abstract This document defines a portable, cryptographically signed receipt format for recording machine-to-machine access control decisions. Each receipt captures the identity of the decision maker, the tool or resource being accessed, the policy evaluation result, and a timestamp — all signed with Ed25519 [RFC8032] and serialized using deterministic JSON canonicalization [RFC8785]. The format is designed for environments where AI agents invoke tools on behalf of human operators, particularly the Model Context Protocol (MCP) ecosystem. Receipts are independently verifiable without contacting the issuer, enabling offline audit, regulatory compliance, and cross-organizational trust federation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Farley Expires 27 September 2026 [Page 1] Internet-Draft Acta Signed Receipts March 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship to MCP . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Receipt Structure . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Signed Envelope . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Signature Object . . . . . . . . . . . . . . . . . . 4 2.2. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Receipt Types . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Access Decision Receipt . . . . . . . . . . . . . . . . . 5 3.1.1. Fields . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Restraint Receipt . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Fields . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Arena Battle Receipt . . . . . . . . . . . . . . . . . . 7 3.3.1. Fields . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Formal Debate Receipt . . . . . . . . . . . . . . . . . . 7 4. Signing and Verification . . . . . . . . . . . . . . . . . . 8 4.1. Signing Process . . . . . . . . . . . . . . . . . . . . . 8 4.2. Verification Process . . . . . . . . . . . . . . . . . . 9 4.3. Public Key Distribution . . . . . . . . . . . . . . . . . 9 5. Trust Tiers . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Agent Identity . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Passport Manifest . . . . . . . . . . . . . . . . . . . . 10 6.2. DPoP Binding (Future) . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 11 7.2. Key Compromise . . . . . . . . . . . . . . . . . . . . . 11 7.3. Payload Privacy . . . . . . . . . . . . . . . . . . . . . 11 7.4. Canonicalization Attacks . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Implementation Status . . . . . . . . . . . . . . . 12 A.1. protect-mcp (Reference Implementation) . . . . . . . . . 13 A.2. @veritasacta/verify (Verifier) . . . . . . . . . . . . . 13 A.3. @scopeblind/passport (Identity SDK) . . . . . . . . . . . 13 Appendix B. Example: Complete Verification Flow . . . . . . . . 13 Farley Expires 27 September 2026 [Page 2] Internet-Draft Acta Signed Receipts March 2026 B.1. Step 1: Generate Issuer Keys . . . . . . . . . . . . . . 13 B.2. Step 2: Sign a Receipt . . . . . . . . . . . . . . . . . 14 B.3. Step 3: Verify (CLI) . . . . . . . . . . . . . . . . . . 14 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction As AI agents increasingly act autonomously — invoking tools, accessing APIs, and modifying state — there is a growing need for cryptographic evidence of what decisions were made, by whom, and under what policy. Current approaches rely on centralized logging (e.g., CloudWatch, SIEM ingestion), which requires trust in the log operator and provides no independent verifiability. A compromised or malicious operator can silently alter or omit log entries. This specification defines a *Signed Decision Receipt* format that provides: 1. *Portable evidence*: Receipts are self-contained JSON objects that can be stored, transmitted, and verified independently. 2. *Cryptographic integrity*: Each receipt is signed using Ed25519 (RFC 8032), ensuring tamper detection without PKI infrastructure. 3. *Offline verification*: Any party with the issuer's public key can verify a receipt without network access or API calls. 4. *Minimal disclosure*: Receipts capture the decision metadata (tool name, decision, tier, timestamp) without logging raw request payloads, prompts, or sensitive parameters. 1.1. Relationship to MCP The Model Context Protocol [MCP] defines a JSON-RPC transport for AI tool invocation but provides no built-in access control, auditing, or accountability mechanism. This specification is designed to be deployed at the MCP transport layer (typically as a stdio proxy) without modifications to the MCP protocol itself. Farley Expires 27 September 2026 [Page 3] Internet-Draft Acta Signed Receipts March 2026 This specification is complementary to [I-D.serra-mcp-discovery-uri], which defines the mcp:// URI scheme and server discovery mechanism. Discovery (how an agent finds a server) and accountability (what gets recorded after the agent uses it) are independently deployable layers. A server's discovery manifest MAY declare a trust_class that informs receipt-generating proxies of the server's operating context (e.g., "regulated"), enabling jurisdiction-aware policy evaluation without encoding legal regime information in the receipt itself. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Receipt Structure A Signed Decision Receipt is a JSON object with two top-level fields: payload and signature. 2.1. Signed Envelope { "payload": { ... }, "signature": { "alg": "EdDSA", "kid": "", "sig": "" } } 2.1.1. Signature Object alg (REQUIRED): The signature algorithm. MUST be "EdDSA" for Ed25519 as defined in RFC 8032. kid (REQUIRED): The key identifier of the signing key. This is an opaque string that SHOULD resolve to a public key via a well-known endpoint or out-of-band distribution. The RECOMMENDED format is sb:issuer: where the fingerprint is the first 12 characters of the Base58-encoded Ed25519 public key. sig (REQUIRED): The Ed25519 signature over the canonicalized payload, encoded as a lowercase hexadecimal string (128 characters for 64 bytes). Farley Expires 27 September 2026 [Page 4] Internet-Draft Acta Signed Receipts March 2026 2.2. Payload The payload is a JSON object whose schema depends on the receipt type. All payload types share the following common fields: type (REQUIRED): A namespaced string identifying the receipt type. Examples: "protectmcp:decision", "protectmcp:restraint", "blindllm:arena-battle". issued_at (REQUIRED): ISO 8601 timestamp [RFC3339] of when the receipt was created. MUST include timezone designator (typically "Z" for UTC). issuer_id (REQUIRED): The identifier of the entity that issued and signed the receipt. MUST match the kid field in the signature object. 3. Receipt Types This specification defines four receipt types. Implementations MAY define additional types using the namespaced type field. 3.1. Access Decision Receipt Type: protectmcp:decision Records the outcome of a policy evaluation for a tool invocation. { "type": "protectmcp:decision", "tool_name": "delete_database", "decision": "deny", "reason": "tier_insufficient", "agent_tier": "signed-known", "required_tier": "privileged", "policy_digest": "sha256:a8f3...c91e", "session_id": "ses_7f8a2b", "issued_at": "2026-03-22T14:32:04.102Z", "issuer_id": "sb:issuer:4Kpm7Q3wXx2b" } 3.1.1. Fields tool_name (REQUIRED): The name of the tool being invoked, as declared in the MCP tools/list response. decision (REQUIRED): The policy evaluation result. One of: "allow", "deny", "rate_limit". Farley Expires 27 September 2026 [Page 5] Internet-Draft Acta Signed Receipts March 2026 reason (OPTIONAL): A machine-readable reason code for the decision. Examples: "tier_insufficient", "rate_exceeded", "policy_block", "agent_refusal". agent_tier (OPTIONAL): The trust tier of the requesting agent at the time of the decision. One of: "unknown", "signed-known", "evidenced", "privileged". required_tier (OPTIONAL): The minimum trust tier required by the policy for this tool. policy_digest (OPTIONAL): A content-addressable hash of the policy document in effect at the time of the decision. Format: "sha256:". session_id (OPTIONAL): An opaque identifier for the MCP session. MUST NOT contain PII or be correlatable across sessions unless the operator explicitly configures session binding. 3.2. Restraint Receipt Type: protectmcp:restraint Records an agent's interaction with a policy boundary, specifically whether the agent attempted to use a restricted tool and whether the restriction was enforced by an external policy or self-imposed. { "type": "protectmcp:restraint", "agent_id": "sb:agent:8xKm3Qw2Yb1c", "agent_manifest_version": "1.2.0", "tool_name": "rm_rf", "decision": "deny", "denial_type": "policy-block", "issued_at": "2026-03-22T14:35:12.441Z", "issuer_id": "sb:issuer:4Kpm7Q3wXx2b" } 3.2.1. Fields agent_id (REQUIRED): The identifier of the agent whose tool call was evaluated. agent_manifest_version (REQUIRED): The semantic version of the agent's manifest at the time of the decision. tool_name (REQUIRED): The tool that was called or attempted. Farley Expires 27 September 2026 [Page 6] Internet-Draft Acta Signed Receipts March 2026 decision (REQUIRED): One of: "allow", "deny". denial_type (OPTIONAL): If the decision is "deny", indicates whether the denial was imposed by external policy ("policy-block") or self-imposed by the agent ("agent-refusal"). 3.3. Arena Battle Receipt Type: blindllm:arena-battle Records the outcome of a competitive evaluation between two AI agents, as conducted by a neutral arena platform. { "type": "blindllm:arena-battle", "battle_id": "bat_9x8f7a2b", "lane_id": "lane_creative_writing", "agent_a": { "id": "sb:agent:3mK9pQ7wXx2b", "manifest_version": "2.1.0" }, "agent_b": { "id": "sb:agent:8xKm3Qw2Yb1c", "manifest_version": "1.4.0" }, "winner": "A", "issued_at": "2026-03-22T15:00:00.000Z", "issuer_id": "sb:issuer:4Kpm7Q3wXx2b" } 3.3.1. Fields battle_id (REQUIRED): Unique identifier for the battle instance. lane_id (REQUIRED): The evaluation category or "lane" in which the battle occurred. agent_a, agent_b (REQUIRED): Objects identifying each participant, containing: - id: The agent's passport identifier. - manifest_version: The agent's manifest version at battle time. winner (REQUIRED): One of: "A", "B", "tie". 3.4. Formal Debate Receipt Type: blindllm:formal-debate Farley Expires 27 September 2026 [Page 7] Internet-Draft Acta Signed Receipts March 2026 Records the outcome of a structured debate with audience and judge scoring. Extends the arena battle format with additional governance fields. { "type": "blindllm:formal-debate", "debate_id": "dbt_4f2a8c", "spec_id": "spec_ai_safety_v2", "lane_id": "lane_policy", "artifact_hash": "sha256:b3c4d5e6...", "resolution_hash": "sha256:f7a8b9c0...", "pro": { "id": "sb:agent:3mK9pQ7wXx2b", "manifest_version": "2.1.0" }, "con": { "id": "sb:agent:8xKm3Qw2Yb1c", "manifest_version": "1.4.0" }, "audience_winner": "pro", "judge_winner": "pro", "restraint_result": "clean", "issued_at": "2026-03-22T16:30:00.000Z", "issuer_id": "sb:issuer:4Kpm7Q3wXx2b" } 4. Signing and Verification 4.1. Signing Process 1. Construct the payload object with all required fields. 2. Canonicalize the payload using JCS [RFC8785]. The canonical form is a deterministic JSON serialization with sorted keys and no whitespace. 3. Convert the canonical JSON string to a UTF-8 byte sequence. 4. Sign the byte sequence using Ed25519 [RFC8032] with the issuer's secret key. 5. Encode the signature as a lowercase hexadecimal string. 6. Construct the signed envelope by wrapping the original (non- canonicalized) payload with the signature object. Farley Expires 27 September 2026 [Page 8] Internet-Draft Acta Signed Receipts March 2026 4.2. Verification Process 1. Extract the payload and signature from the envelope. 2. Canonicalize the payload using JCS [RFC8785]. 3. Convert the canonical JSON to a UTF-8 byte sequence. 4. Resolve the public key using the kid field in the signature. The RECOMMENDED resolution mechanism is a JWK Set endpoint [RFC7517] at /.well-known/acta-keys.json. 5. Verify the Ed25519 signature over the canonical bytes using the resolved public key. 6. If verification succeeds, the receipt is authentic and has not been tampered with. If verification fails, the receipt MUST be rejected. 4.3. Public Key Distribution Issuers SHOULD publish their public keys as a JWK Set [RFC7517] at a well-known endpoint: GET /.well-known/acta-keys.json { "keys": [{ "kty": "OKP", "crv": "Ed25519", "kid": "sb:issuer:4Kpm7Q3wXx2b", "x": "", "use": "sig" }] } The x parameter MUST be the base64url-encoded Ed25519 public key as specified in [RFC8037]. For offline verification, public keys MAY be distributed out-of-band (e.g., embedded in configuration files, published in DNS TXT records, or included in agent manifests). 5. Trust Tiers This specification defines a four-level trust hierarchy for agent identity. Trust tiers are used by policy engines to gate tool access. Farley Expires 27 September 2026 [Page 9] Internet-Draft Acta Signed Receipts March 2026 unknown: No identity presented. Default tier for anonymous connections. signed-known: Agent presents a valid signed manifest with a verifiable Ed25519 public key. Identity is pseudonymous but consistent. evidenced: Agent has accumulated verifiable evidence receipts (e.g., arena battle outcomes, successful restraint records) that demonstrate a track record of trustworthy behavior. privileged: Operator has explicitly granted elevated access. Typically requires out-of-band verification (e.g., organization membership, contractual agreement). Trust tier transitions are unidirectional within a session but MAY be re-evaluated across sessions based on accumulated evidence. 6. Agent Identity 6.1. Passport Manifest An agent's identity is expressed as a signed manifest: { "type": "scopeblind:agent-manifest", "id": "sb:agent:3mK9pQ7wXx2b", "version": "2.1.0", "previous_version": "2.0.0", "created_at": "2026-03-20T10:00:00Z", "public_key": "" } Manifests are IMMUTABLE once signed. Version changes create new manifests that reference their predecessor via previous_version, forming a verifiable version chain. 6.2. DPoP Binding (Future) For remote MCP transports (HTTP/SSE), agent identity MAY be bound to per-request proof-of-possession using DPoP [RFC9449]. The auth_key_bindings field in the manifest links the agent's Ed25519 identity key to one or more P-256 DPoP keys. This binding creates a verifiable delegation chain: Operator → Agent Identity (Ed25519) → Request Auth (P-256 DPoP) Farley Expires 27 September 2026 [Page 10] Internet-Draft Acta Signed Receipts March 2026 7. Security Considerations 7.1. Replay Protection Receipts include an issued_at timestamp but do not include a nonce or sequence number. Verifiers SHOULD reject receipts with timestamps that are unreasonably old (implementation-defined; 24 hours is RECOMMENDED as a default). For environments requiring stronger replay protection, implementations MAY add a nonce field to the payload. 7.2. Key Compromise If an issuer's signing key is compromised, all receipts signed with that key become suspect. Issuers SHOULD implement key rotation by publishing new keys at the well-known endpoint and including a valid_from / valid_until window in the JWK metadata. Verifiers SHOULD check key validity windows when available. 7.3. Payload Privacy Receipts are designed to capture decision metadata, NOT request content. Implementations MUST NOT include raw prompts, tool arguments, API keys, or other sensitive parameters in receipt payloads. The tool_name and decision fields are considered non-sensitive. The session_id field SHOULD be an opaque identifier that is not correlatable across sessions. 7.4. Canonicalization Attacks The signing process relies on JCS [RFC8785] for deterministic serialization. Implementations MUST use a conformant JCS implementation to prevent canonicalization divergence attacks where the signed bytes differ from the verified bytes. 8. IANA Considerations This document has no IANA actions. Future versions of this specification MAY request registration of: * A receipt-type registry for namespaced receipt type identifiers. * A well-known URI suffix for /.well-known/acta-keys.json. Farley Expires 27 September 2026 [Page 11] Internet-Draft Acta Signed Receipts March 2026 9. References 9.1. Normative References [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . 9.2. Informative References [MCP] "Model Context Protocol Specification", 2025, . [I-D.serra-mcp-discovery-uri] Serra, M., "The mcp URI Scheme and MCP Server Discovery Mechanism", 2026, . Appendix A. Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of publication. Farley Expires 27 September 2026 [Page 12] Internet-Draft Acta Signed Receipts March 2026 A.1. protect-mcp (Reference Implementation) * Organization: ScopeBlind * Implementation: https://www.npmjs.com/package/protect-mcp * Description: A stdio proxy for MCP servers that generates signed decision receipts. Supports shadow mode (log-only) and enforce mode (policy evaluation). * Coverage: Access Decision Receipts, Restraint Receipts. * Licensing: FSL-1.1-MIT (converts to MIT after 2 years). A.2. @veritasacta/verify (Verifier) * Organization: Veritas Acta * Implementation: https://www.npmjs.com/package/@veritasacta/verify * Description: Standalone CLI and library for offline receipt verification. Zero runtime dependencies on ScopeBlind. * Coverage: All receipt types defined in this specification. * Licensing: MIT. A.3. @scopeblind/passport (Identity SDK) * Organization: ScopeBlind * Implementation: https://www.npmjs.com/package/@scopeblind/passport * Description: Agent identity SDK for generating manifests, signing receipts, and managing trust tier evidence bundles. * Coverage: All receipt types, manifest signing, key management. * Licensing: FSL-1.1-MIT. Appendix B. Example: Complete Verification Flow The following example demonstrates end-to-end receipt creation and verification. B.1. Step 1: Generate Issuer Keys Farley Expires 27 September 2026 [Page 13] Internet-Draft Acta Signed Receipts March 2026 import { generateIssuerKey } from '@scopeblind/passport'; const issuer = generateIssuerKey(); // issuer.issuerId = "sb:issuer:4Kpm7Q3wXx2b" B.2. Step 2: Sign a Receipt import { signReceipt } from '@scopeblind/passport'; const receipt = signReceipt( { type: "protectmcp:decision", tool_name: "deploy", decision: "allow", agent_tier: "privileged", policy_digest: "sha256:a8f3...c91e", issued_at: "2026-03-22T14:32:06.551Z", issuer_id: issuer.issuerId }, issuer.secretKeyHex, issuer.issuerId ); B.3. Step 3: Verify (CLI) $ npx @veritasacta/verify receipt.json --key issuer-public.json ✓ Signature valid ✓ Issuer: sb:issuer:4Kpm7Q3wXx2b ✓ Decision: allow (deploy) ✓ Issued: 2026-03-22T14:32:06.551Z Appendix C. Acknowledgements The Acta receipt format was developed as part of the Veritas Acta protocol, an infrastructure for verifiable machine decision-making. The design draws on work in the IETF OAuth and Web Authentication communities, particularly RFC 9449 (DPoP) for proof-of-possession patterns and RFC 8785 (JCS) for deterministic serialization. Author's Address Tom Farley ScopeBlind (Veritas Acta) Email: tom@scopeblind.com Farley Expires 27 September 2026 [Page 14]