]> ScopeBlind (Veritas Acta)

tom@scopeblind.com

Security Independent MCP receipts Ed25519 access-control AI agents 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 and serialized using deterministic JSON canonicalization . 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.

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.

Relationship to MCP The Model Context Protocol 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. This specification is complementary to , 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.

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.

Receipt Structure A Signed Decision Receipt is a JSON object with two top-level fields: payload and signature.

Signed Envelope ", "sig": "" } } ]]>

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:<base58-fingerprint> 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).

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

Receipt Types This specification defines four receipt types. Implementations MAY define additional types using the namespaced type field.

Access Decision Receipt Type: protectmcp:decision Records the outcome of a policy evaluation for a tool invocation.

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

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

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.

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.

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.

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

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.

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

Formal Debate Receipt Type: blindllm:formal-debate Records the outcome of a structured debate with audience and judge scoring. Extends the arena battle format with additional governance fields.

Signing and Verification

Signing Process

1. Construct the payload object with all required fields.
2. Canonicalize the payload using JCS . 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 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.

Verification Process

1. Extract the payload and signature from the envelope.
2. Canonicalize the payload using JCS .
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 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.

Public Key Distribution Issuers SHOULD publish their public keys as a JWK Set at a well-known endpoint: ", "use": "sig" }] } ]]> The x parameter MUST be the base64url-encoded Ed25519 public key as specified in . 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).

Trust Tiers This specification defines a four-level trust hierarchy for agent identity. Trust tiers are used by policy engines to gate tool access.

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.

Agent Identity

Passport Manifest An agent's identity is expressed as a signed manifest: " } ]]> Manifests are IMMUTABLE once signed. Version changes create new manifests that reference their predecessor via previous_version, forming a verifiable version chain.

DPoP Binding (Future) For remote MCP transports (HTTP/SSE), agent identity MAY be bound to per-request proof-of-possession using DPoP . 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:

Security Considerations

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.

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.

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.

Canonicalization Attacks The signing process relies on JCS for deterministic serialization. Implementations MUST use a conformant JCS implementation to prevent canonicalization divergence attacks where the signed bytes differ from the verified bytes.

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.

References Normative References This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). 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. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. Informative References Mumble Group

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of publication.

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

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

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

Example: Complete Verification Flow The following example demonstrates end-to-end receipt creation and verification.

Step 1: Generate Issuer Keys

Step 2: Sign a Receipt

Step 3: Verify (CLI)

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.