Signed Decision Receipts for Machine-to-Machine Access Control

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

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.1. Signed Envelope

{
  "payload": { ... },
  "signature": {
    "alg": "EdDSA",
    "kid": "<issuer-identifier>",
    "sig": "<hex-encoded-ed25519-signature>"
  }
}

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

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

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": "<base64url-encoded-public-key>",
    "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).¶

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": "<base58-ed25519-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)

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

9.1. Normative References

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.

[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, <https://www.rfc-editor.org/info/rfc8037>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/info/rfc8785>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.

[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, <https://www.rfc-editor.org/info/rfc9449>.

9.2. Informative References

[MCP]

"Model Context Protocol Specification", 2025, <https://modelcontextprotocol.io/specification>.

[I-D.serra-mcp-discovery-uri]

Serra, M., "The mcp URI Scheme and MCP Server Discovery Mechanism", 2026, <https://datatracker.ietf.org/doc/draft-serra-mcp-discovery-uri/>.

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

B.1. Step 1: Generate Issuer Keys

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