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

This is the envelope shape, and it is the shape new implementations SHOULD emit. A second, flat shape carries the payload fields at the top level alongside a signature member that is a hexadecimal string. It predates the envelope and remains in use. The two shapes are signed over different byte strings, and an implementation MUST determine which shape it is handling before computing or checking a signature; see Section 6.6. Except where a shape is named explicitly, the remainder of this document describes the envelope shape.¶

2.2. Payload

The payload is a JSON object whose schema depends on the receipt type. This section lists the members common to all payload types. Members specific to one receipt type are defined with that type in Section 3. A member defined elsewhere in this document that may appear in any payload type is listed here.¶

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

previousReceiptHash (OPTIONAL):

A link to the immediately preceding receipt in a receipt chain, present at most once. When present it MUST be a member of the payload object, not of the enclosing receipt object, and its value MUST be computed as specified in Section 6.7.¶

The first receipt in a chain MUST omit the member entirely rather than carrying null or an empty string, which would produce different JCS output and therefore a different signature. A receipt that omits it is either a chain genesis or an unchained receipt; the format does not distinguish these, and a verifier MUST NOT infer chain membership from its absence.¶

evidence (OPTIONAL):

The evidentiary basis the decision rested on, as defined in Section 4. When present it MUST be an array. A verifier that does not implement the predicate MUST still verify the receipt signature and chain, and MUST ignore this member otherwise.¶

committed_fields_root (OPTIONAL):

The Merkle root committing to selectively disclosable fields, as defined in Section 6. Present only in commitment mode. A verifier that does not implement commitment mode MUST ignore this member when verifying the signature, though the member remains covered by that signature.¶

payload_digest (OPTIONAL):

A content-addressable hash of associated data (tool input, tool output, or other large payloads) that is too large to embed in the receipt. Format: an object containing hash (SHA-256 hex string), size (byte count), and optionally preview (first 256 characters). Enables integrity verification of associated data without embedding it in the receipt.¶

hook_latency_ms (OPTIONAL):

The time in milliseconds spent evaluating the policy decision. Enables operators to verify that security middleware adds negligible overhead (<5ms is RECOMMENDED for synchronous policy checks).¶

tool_duration_ms (OPTIONAL):

The time in milliseconds between the initiation and completion of the tool invocation. Present only in post-execution receipts.¶

sandbox_state (OPTIONAL):

Whether the execution environment had OS-level containment active at the time of the decision. One of: "enabled", "disabled", "unavailable". Enables auditors to verify that agent actions occurred within a sandboxed environment.¶

action_ref (OPTIONAL):

A cross-engine correlation anchor: the SHA-256 hash of the canonical representation of the action being evaluated. When two or more governance engines evaluate the same action independently, both receipts carry the same action_ref, enabling bilateral verification without either engine needing to trust the other.¶

The computation is:¶

action_ref = SHA-256(canonicalize({
  agentId,
  actionType,
  scopeRequired,
  timestamp
}))

¶

where canonicalize follows RFC 8785 (JCS) and scopeRequired is sorted lexicographically before canonicalization. The resulting hex string is deterministic: same inputs produce the same hash regardless of implementation language.¶

This field is RECOMMENDED when the receipt will be consumed by external governance frameworks or cross-engine audit tools.¶

iteration_id (OPTIONAL):

A logical iteration grouping identifier for multi-step agent workflows. When an agent runs in an optimization loop or a multi-round deliberation, receipts within the same iteration share the same iteration_id. This enables behavioral analysis tools to group receipts by logical iteration rather than by receipt count.¶

The value is an opaque string. Hierarchy may be encoded by convention using dot-separated segments (e.g., "run_7.sub_3" encodes a nested iteration at depth 2). The field is agent-declared metadata for grouping purposes, NOT a security boundary: a malicious agent could set misleading values. Receipt signatures cover this field (tamper-evident) but do not vouch for its semantic accuracy.¶

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. Agent Lifecycle Receipt

Type: protectmcp:lifecycle¶

Records agent lifecycle events in multi-agent orchestration systems (swarms, coordinator mode, scheduled agents). Enables reconstruction of the full agent topology from the receipt DAG.¶

{
  "type": "protectmcp:lifecycle",
  "lifecycle_event": "subagent_start",
  "agent_id": "worker-a1b",
  "agent_type": "general-purpose",
  "parent_session_id": "ses_7f8a2b",
  "team_name": "backend-ops",
  "sandbox_state": "enabled",
  "issued_at": "2026-04-01T10:15:00.000Z",
  "issuer_id": "sb:issuer:4Kpm7Q3wXx2b"
}

3.5. Spending Authority Receipt

Type: scopeblind:spending_authority¶

Records the outcome of an issuer-blind spending authorization check. Proves that an agent's purchase is within authorized limits without revealing organizational identity, budget ceiling, or delegation chain.¶

{
  "type": "scopeblind:spending_authority",
  "amount": 99.50,
  "currency": "USD",
  "category": "cloud_compute",
  "utilization_band": "low",
  "decision": "allow",
  "policy_digest": "sha256:a8f3...c91e",
  "issued_at": "2026-04-01T12:00:00.000Z",
  "issuer_id": "sb:issuer:4Kpm7Q3wXx2b"
}

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

dimension (REQUIRED):

The class of evidence. Core values: "data_rights", "provenance", "compliance", "freshness", "consent", "identity", "authorization", "integrity". Implementations MAY define additional dimensions using a namespaced extension of the form x-<vendor>:<name>, where <vendor> matches [a-z0-9]+ and <name> matches [a-z0-9_.-]+ (both lowercase).¶

state (REQUIRED):

The evaluated state of this dimension at decision time. One of: "satisfied", "unverified", "stale", "failed", "not_applicable".¶

source (REQUIRED):

The provenance of the evidence, an object with authority (the attesting party; advisory), ref (a resolvable reference or a "sha256:<hex>" digest of the attested subject), an OPTIONAL kid (the attesting authority's key id), an OPTIONAL alg (the signature algorithm, taking the same values as the alg member of Section 2.1.1, and defaulting to "EdDSA" when absent), and an OPTIONAL sig (the authority's signature over the JCS-canonical claim, encoded as a lowercase hexadecimal string and verifiable under kid). As in Section 2.1.1, the encoded length of sig is determined by alg and is not fixed by this document; a relying party MUST NOT reject a source signature on encoded length alone. An attesting authority need not use the same algorithm as the receipt signer. See Section 4.3: a named authority or kid is NOT proof of authorship; only a verified sig is.¶

as_of (OPTIONAL):

An RFC 3339 timestamp of when the evidence was current. RECOMMENDED for freshness-relevant dimensions.¶

The signed claim is the JSON object built from the entry's dimension, state, and as_of together with the source's ref: { dimension, ref, state } plus an as_of member when the entry carries one. When as_of is absent the as_of member is OMITTED from the claim; it MUST NOT be encoded as null. The producer canonicalizes this object under JCS and signs the resulting bytes; source.sig is that signature. A relying party reconstructs the same claim from the entry and verifies source.sig over its JCS bytes.¶

4.2. Properties

evidence is OPTIONAL and additive. A verifier that does not understand it MUST still verify the receipt's signature and chain; the field is covered by the signature (tamper-evident) but requires no verifier action. It is canonicalized under JCS with the rest of the payload and is therefore signed. It MUST NOT carry raw evidence content (positions, prompts, tool payloads); it carries states, references, digests, and timestamps only.¶

Evidence entries MAY be committed and selectively disclosed under Section 6. When they are, the unit of disclosure MUST be the whole entry. A producer MUST NOT disclose an entry's dimension and state while withholding its source, because a relying party cannot apply Section 4.3 to an entry whose source it cannot see, and a disclosed "satisfied" with no visible source is precisely the false assurance Section 9.9 warns against. Withholding an entry in full is permitted; a relying party MUST NOT infer from a disclosed set that no further entries exist.¶

4.3. Trust Model

evidence is a set of claims made by the receipt SIGNER. Every field of every entry, including source.authority and source.kid, is inside the payload the signer fully controls; the receipt signature proves only that the signer ASSERTED them. A present or trusted-looking source.kid is therefore NOT proof that the named authority attested anything. It is exactly the in-payload, signer-controlled value that Section 9.5 warns is "strictly worse than no signature at all, because it provides false assurance."¶

A relying party MUST NOT treat any evidence dimension as INDEPENDENT corroboration unless ALL of the following hold: (1) the entry carries a source.sig; (2) the relying party obtains the corresponding public key OUT OF BAND via the mechanisms in Section 9.5 (not from the receipt) and confirms that key's identifier equals source.kid; (3) the relying party's out-of-band trust policy identifies the source key as belonging to a control domain DISTINCT from the receipt signer. At a minimum, the source public key MUST NOT equal the key that signed the enclosing receipt; and (4) source.sig verifies under that key over the JCS bytes of the claim.¶

Condition 3 is load-bearing: every relying party MUST already pin the receipt signer's own key out of band, because that is the only way to verify the receipt at all. Public-key inequality alone is necessary but not sufficient: the relying party also needs a trust-policy determination that the source key is outside the receipt signer's control. Without this requirement, a receipt signer could sign an evidence claim with its OWN key, satisfy conditions 1, 2, and 4, and manufacture "independent" corroboration of itself. An entry whose source.kid resolves to the receipt's signing key, or whose control domain cannot be established independently, is self-attestation and MUST NOT be counted as independent corroboration.¶

A dimension without a verifiable, independent source.sig is the receipt signer's own claim and MUST NOT raise the assurance a relying party places in the decision, regardless of the authority or kid it names. Producers SHOULD mark a self-attested basis with an authority of runtime:<component>, but this labelling is advisory: because the producer controls it, a relying party MUST identify a non-corroborating dimension by the ABSENCE of a verifiable, independent source.sig, not by trusting the label.¶

A verified source.sig proves only that the authority attested the claim tuple; it does NOT prove the authority observed or endorsed the enclosing decision. The claim binds nothing from the receipt (no session_id, policy_digest, tool_name, or decision), so the same signed claim may lawfully appear in many receipts. A relying party MUST additionally judge whether the claim's ref and as_of pertain to the action being decided, and SHOULD bound acceptance by as_of.¶

5.1. Signing Process

1. Construct the payload object with all required fields.¶

2. Construct the receipt object carrying that payload as its payload member.¶

3. Form the signing input for the envelope shape: canonicalize the payload member using JCS [RFC8785]. The canonical form is a deterministic JSON serialization with sorted keys and no whitespace. The signing input is the payload member alone; it does not include the enclosing receipt object. For the flat shape the signing input is the receipt minus its signature member. See Section 6.6, which an implementation MUST consult before computing either.¶

4. Convert the canonical JSON string to a UTF-8 byte sequence.¶

5. Sign the byte sequence using Ed25519 [RFC8032] with the issuer's secret key.¶

6. Encode the signature as a lowercase hexadecimal string.¶

7. Attach the signature object to the original (non-canonicalized) receipt as its signature member. The transmitted receipt carries the payload exactly as constructed; canonicalization is performed only to derive the signing input and its output is not transmitted.¶

5.2. Verification Process

1. Determine the receipt shape as defined in Section 6.6 and extract the signature. In the envelope shape the signature is the signature member, an object. In the flat shape it is the signature member, a hexadecimal string, and the algorithm and key identifier are carried as separate members of the receipt.¶

2. Reconstruct the signing input for the shape received, as defined in Section 6.6: for the envelope shape, canonicalize the payload member as received; for the flat shape, canonicalize the receipt minus its signature member. This reproduces the byte string the signer formed in Section 5.1. Applying the wrong shape's rule produces a different byte string and causes verification of correctly signed receipts to fail.¶

3. Convert the canonical JSON to a UTF-8 byte sequence.¶

4. Resolve the public key using the key identifier carried by the receipt. The RECOMMENDED resolution mechanism is a JWK Set endpoint [RFC7517] at /.well-known/acta-keys.json. The key MUST be obtained through that mechanism or another out-of-band trust anchor, never from the receipt itself; see Section 9.5.¶

5. Verify the signature over the canonical bytes using the resolved public key and the algorithm declared by the receipt, not an algorithm assumed by the verifier; see Section 6.9.¶

6. If verification succeeds, the receipt is authentic and has not been tampered with. If verification fails, the receipt MUST be rejected.¶

5.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. Merkle Tree Construction

Implementations MUST use the following RFC 6962-style construction with explicit one-byte domain separation:¶

leaf_hash     = SHA-256(0x00 || canonical_leaf_bytes)
internal_hash = SHA-256(0x01 || left_child_hash || right_child_hash)

For a list of leaf hashes D of length n:¶

• If n == 1, the Merkle root is D[0].¶

• Otherwise, let k be the largest power of two strictly less than n. The root is SHA-256(0x01 || MerkleRoot(D[0..k]) || MerkleRoot(D[k..n])).¶

This construction handles non-power-of-two leaf counts without padding by recursively splitting on the largest power of two, matching [RFC6962] Section 2.1.¶

The committed_fields_root field MUST be the lowercase hex encoding of the resulting 32-byte Merkle root.¶

6.2. Canonical Leaf Layout

Each leaf encodes a single committed field as a JCS [RFC8785]-canonicalized JSON object:¶

canonical_leaf_bytes = JCS({
  "name":  field_name,
  "salt":  base64url_unpadded(salt_bytes),
  "value": field_value
})

The name field MUST be the field's identifier within the receipt payload (e.g., "principal", "action"). Including the field name in the leaf binds the commitment to a specific field and prevents cross-field substitution attacks. The value field MUST be the cleartext field value, preserving its original JSON type (string, number, boolean, object, or array). The salt field MUST be the base64url-encoded (without padding, per [RFC4648] Section 5) byte string of the salt.¶

6.3. Leaf Sort Order

Leaves MUST be ordered by the byte-lexicographic order of the UTF-8 encoded name field. Implementations MUST NOT apply locale-aware collation, case folding, or Unicode normalization. Two implementations that disagree on sort order will produce different roots; this rule eliminates that source of interoperability failure.¶

6.4. Salt Construction and Storage

Each committed field MUST have its own salt. Salts MUST be at least 16 bytes and SHOULD be 32 bytes. Implementations SHOULD generate salts using a cryptographically secure random number generator (e.g., crypto.getRandomValues in browsers, or os.urandom on POSIX).¶

Implementations MAY derive salts deterministically from a per-subject master secret, but MUST ensure that erasure of one subject's master secret cannot affect commitments belonging to other subjects. The simplest implementation strategy is to use a fresh random salt per field per receipt; this is the RECOMMENDED default.¶

The salt-prefix ordering for the leaf-level hash inside the canonical leaf JSON object is implementation-internal: the leaf hash is SHA-256 over the JCS-canonicalized object, not over a raw concatenation. This sidesteps salt-ordering ambiguity entirely.¶

For implementations that emit a separate per-field commitment value alongside the Merkle leaf (for example, in earlier draft versions or in a per-field disclosure envelope), the per-field commitment MUST be computed as SHA-256(salt || value_bytes) where value_bytes is the UTF-8 encoding of the JSON-stringified value. Implementations MUST NOT use the reverse ordering SHA-256(value_bytes || salt); receipts that do so MUST be rejected as malformed.¶

6.5. Selective Disclosure

To disclose a single field to a verifier, the discloser provides:¶

1. The cleartext field name, value, and salt.¶

2. A Merkle inclusion proof, consisting of the leaf's zero-based index within the canonically-sorted leaf list, the total tree_size, and the ordered list of siblings (hex-encoded SHA-256 hashes) along the path from the leaf to the root.¶

No left/right indicator is carried for each sibling, and none is needed. Because Section 6.1 fixes the split at the largest power of two strictly less than the node count, the side of every sibling is determined by index and tree_size alone, and a verifier MUST derive it under that rule. This is deliberate rather than an omission. A verifier that instead assumes a padded fixed-depth tree, taking the side from the bits of index as is common in implementations that pad the leaf count up to a power of two, agrees with this construction only when the leaf count is already a power of two and diverges at every other size. For tree_size 5 and index 4 the correct path has one element, while the padded derivation expects three.¶

The verifier reconstructs the leaf hash from the disclosed (name, salt, value) tuple, walks the inclusion proof, and compares the resulting root to committed_fields_root in the signed receipt. Mismatch MUST cause the disclosure to be rejected.¶

A formal Disclosure object with recipient binding, expiry, custody chain, and revocation handle is OUT OF SCOPE for this draft and is deferred to a future revision. Implementations MAY use a minimal disclosure envelope of {name, value, salt, proof} in the interim.¶

6.6. Signature Scope (Normative Clarification)

The signature MUST cover the canonical JCS bytes of the signing input directly: the UTF-8 byte sequence produced by the signing process in Section 5.1, used as the message input to the signature algorithm with no intermediate hash.¶

Two receipt shapes are in use, and the signing input differs between them. An implementation MUST determine the shape before computing the signing input, and MUST NOT apply one shape's rule to the other; the two produce different byte strings, and crossing them causes verification of correctly signed receipts to fail.¶

Envelope shape:

The receipt is the object shown in Section 2.1, carrying exactly two members: a payload member and a signature member that is an object with alg, kid, and sig. The signing input is JCS(payload): the payload member canonicalized on its own, not the enclosing receipt object.¶

Flat shape:

The receipt carries its fields at the top level alongside a signature member that is a hexadecimal string. There is no payload member to canonicalize, so the signing input is the receipt object with the signature member removed, canonicalized. This shape predates the envelope and remains in use; new implementations SHOULD emit the envelope shape.¶

In both shapes the signing input excludes the signature, and in neither is the signature computed over a receipt that already contains one.¶

In either shape the object canonicalized MUST NOT contain a signature member, and that member MUST NOT be included as null or as the empty string; these produce different JCS output and break interoperability.¶

The alg and kid members of the signature object are therefore not covered by the signature. A verifier resolves the key from kid through the mechanisms in Section 9.5 and verification fails if either member is altered, so this is not a substitution vector, but a verifier MUST NOT treat either member as attested content.¶

Standard PureEdDSA [RFC8032] hashes the message internally; implementations MUST NOT pre-hash the canonical bytes (for example with SHA-256) before signing.¶

6.7. Chain Hash Scope (Normative Clarification)

The previousReceiptHash field MUST be the string "sha256:" followed by the lowercase hex encoding of SHA-256(JCS(receipt)), where receipt is the entire signed receipt object including the signature member. For example: "sha256:6699b21fea5819eea4df...".¶

Two choices here are deliberate.¶

The preimage is the whole receipt, not its payload member. Including the signature binds the chain to specific signed bytes, so re-signing an identical payload, after a key rotation for instance, produces a distinct chain link and is visible as a chain event. Hashing the payload alone would make a re-signed receipt indistinguishable from the original, which is the opposite of what a chain is for.¶

The algorithm prefix makes the digest self-describing, matching the form used by policy_digest and by source.ref in Section 4. A verifier MUST reject a previousReceiptHash whose prefix names an algorithm it does not implement, rather than assuming SHA-256 from the length. A bare hex digest with no prefix is the encoding used by earlier revisions; verifiers MAY accept it for compatibility but MUST NOT emit it.¶

6.8. Policy Digest Construction (Normative)

A policy_digest is only evidence if a verifier who has never communicated with the evaluator can recompute it from public bytes alone. An identifier whose derivation is private relocates the self-attestation problem from the decision to the policy: the verifier must trust the evaluator's claim about which policy governed the decision. To close this, the digest construction is normative.¶

The policy digest commits to a manifest of the exact policy source files:¶

M = {
  "construction": "acta-policy-digest-v1",
  "engine": <engine identifier, e.g. "cedar" or "builtin">,
  "files": [
    { "name": <file name>,
      "sha256": <lowercase hex SHA-256 over the file's exact
                 UTF-8 bytes> },
    ...
  ]  // sorted by name, code point order
}

policy_digest = "sha256:" || lowercase_hex(SHA-256(UTF-8(JCS(M))))

Rules:¶

• Each file is hashed individually over its exact bytes. Implementations MUST NOT concatenate policy sources before hashing: concatenation cannot distinguish the file sets ["ab","c"] and ["a","bc"], and a join delimiter only relocates the ambiguity.¶

• Entries are sorted by name in code point order, so the digest is independent of directory read order. Names are included in the manifest, so renames produce a distinct digest.¶

• For a policy supplied as a single in-memory source rather than a file, the entry name MUST be "policy.<ext>" for the engine's conventional extension (for Cedar, "policy.cedar").¶

• For policy expressed as structured configuration rather than source files, the file bytes are the UTF-8 encoding of the JCS canonical form of the policy object, under the name "policy.json".¶

Signature validity and policy freshness remain distinct checks: a receipt whose policy_digest matches a genuinely published policy can still be stale if that policy is no longer the one in force at verification time. A conformant verifier that evaluates policy binding MUST compare the receipt's digest against the policy currently in force, in addition to verifying the receipt signature.¶

Compatibility note: implementations of earlier revisions of this document (protect-mcp before 0.10.0) emitted engine-specific digest preimages truncated to 16 hexadecimal characters with no algorithm prefix. Verifiers SHOULD treat such values as opaque labels rather than recomputable commitments.¶

https://<issuer-domain>/.well-known/acta-policies/<hex>.json

{
  "schema": "acta.policy-bundle.v1",
  "construction": "acta-policy-digest-v1",
  "engine": "cedar",
  "policy_digest": "sha256:<hex>",
  "files": [
    { "name": <file name>, "sha256": <hex>, "content": <string> },
    ...
  ],
  "generated_at": <RFC 3339 timestamp>
}

6.9. Signature Algorithm Agility

Receipts MAY be signed with any of the following algorithms, identified by their JOSE/JWS algorithm names [RFC7518]:¶

• EdDSA (Ed25519, [RFC8032]): Mandatory-to-implement (MTI) baseline.¶

• ML-DSA-65 (FIPS 204): RECOMMENDED for new deployments and post-quantum readiness.¶

• ES256 (ECDSA over P-256): Permitted for compatibility with existing credentials, particularly those used in [I-D.google-cfrg-libzk] ZK proof composition.¶

The signature object MUST contain an alg field carrying the algorithm name as a string. Verifiers MUST verify each receipt against the algorithm declared in its own signature.alg field. Chains MAY contain receipts signed under different algorithms; verifiers MUST handle each receipt independently.¶

The hash-based constructions in this document degrade gracefully under quantum attack rather than breaking. Grover's algorithm reduces SHA-256 pre-image resistance to roughly 2^128 work, which remains infeasible. Collision resistance is already bounded at 2^128 classically by the birthday bound, and known quantum collision methods do not improve on that at any practical memory or time cost. These constructions therefore need no change. The classical-cryptography component is the outer signature, which the algorithm agility above allows to be upgraded in place.¶

6.10. Context Binding for ZK Proofs

When a receipt's principal (or any committed field) references a zero-knowledge proof produced under a separate ZK protocol (e.g., [I-D.google-cfrg-libzk]), the ZK proof MUST bind to the receipt's committed_fields_root as a public input or context hash. Without this binding, a valid ZK proof is replayable into a different receipt with a different committed_fields_root.¶

The committed-fields root serves double duty: it commits to the selectively-disclosable receipt content, and it provides a deterministic, signature-independent context hash that any external proof system can bind against.¶

6.11. Test Vectors

An interoperability test suite is published alongside this draft. The minimum set is:¶

• A cleartext receipt with no committed_fields_root field (signature and JCS output only).¶

• A receipt with four committed fields: the expected Merkle root and an inclusion proof for each field.¶

• A chain of three receipts: the expected previousReceiptHash values.¶

• A tampered Merkle proof: MUST fail verification.¶

• An algorithm-mixed chain (Ed25519 followed by ML-DSA-65): MUST verify successfully when each receipt is checked against its own algorithm.¶

• A non-power-of-two leaf count (e.g., five committed fields): exercises the recursive split rule.¶

Test vectors use fixed (non-random) salts to remain reproducible across implementations. Production deployments MUST NOT reuse the test-vector salts and MUST follow the salt construction guidance in Section 6.4.¶

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

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

9.1. Replay Protection

Receipts include an issued_at timestamp but do not include a nonce or sequence number.¶

This guidance applies to live presentation: a receipt offered as evidence of a currently effective authorization. In that case verifiers SHOULD reject receipts whose timestamps are unreasonably old (implementation-defined; 24 hours is RECOMMENDED as a default).¶

It does not apply to archival verification: examining a receipt as a record of what was authorized at some past time, which is one of the purposes stated in Section 1. Applying a freshness window there would reject every receipt in an audit older than the window. A verifier performing archival verification SHOULD NOT apply one, and SHOULD report the receipt's age rather than deciding on the caller's behalf.¶

For environments requiring stronger replay protection, implementations MAY add a nonce field to the payload.¶

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

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

9.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.5. Key Distribution and Trust Anchors

Receipts are designed to be verified by parties who do not trust the issuer and did not observe the decision being made. This property (the "issuer-blind" property) is the basis for the third-party auditability claim of this document. The property holds only if the verification key a verifier uses to check a signature is sourced through a channel outside the signed payload itself.¶

Verifiers MUST NOT accept a verification key transported inside the receipt envelope (including but not limited to fields such as public_key, verification_key, verification_jwk, or any equivalent name under the signed payload) unless that key is independently anchored by an authenticated trust source. An embedded key is strictly controllable by any party able to produce the rest of the payload; a signature that verifies under an attacker-chosen key provides no authenticity guarantee against tampering and is strictly worse than no signature at all, because it provides false assurance.¶

Conformant verifiers MUST resolve verification keys through one or more of the following external mechanisms, in order of preference when multiple are available:¶

1. A JWK Set [RFC7517] retrieved from a URL bound to the issuer by an independently authenticated trust root (e.g., a server TLS certificate validated via the Web PKI, or a signed DNS record).¶

2. A DID Document whose authenticity follows from the DID method's own verification procedure.¶

3. A trust anchor configured out-of-band by the verifier operator (e.g., a pinned Ed25519 public key loaded from a verifier configuration file).¶

4. A well-known endpoint of the issuer's domain, as described in Section 5.3, provided the domain binding is independently authenticatable.¶

Verifiers SHOULD expose the externally sourced key provenance to the caller (e.g., via a keySource field in structured output) so that the caller can distinguish a verification anchored by --jwks from one anchored by a locally configured trust anchor. This supports defense in depth when an operator layers key provenance constraints above signature verification.¶

Implementations MAY provide a deprecated escape hatch (e.g., a command-line flag) that allows acceptance of embedded keys during a migration window. Such an escape hatch MUST be off by default, MUST emit a visible warning when engaged, and MUST be removed in a subsequent release. See the reference verifier [I-D.verify-reference] for one such implementation.¶

This section was added in draft-02 in response to a public stress- test of draft-01 that identified the embedded-key pattern as a conformance gap. A negative conformance test vector set ([I-D.agent-governance-testvectors]) exercises the required rejection behavior across representative envelope shapes (flat v1, structured v2, Passport-style, full-JWK-embedded).¶

9.6. Verifier Identity Is Not Receipt Content

A receipt is signed by its issuer at issue time. Nothing a verifier learns or computes later can be added to it without invalidating that signature. A field describing which verifier checked a receipt therefore cannot be a member of the signed payload, and a prior revision of this document listed one.¶

Where a deployment needs to record which verifier performed a check, that belongs in a separate verification report that references the receipt by its hash and is signed by the verifier. Such a report is out of scope for this document. A verifier MUST NOT add members to a receipt it has verified, and a consumer MUST NOT treat any member of a receipt as evidence about the party that verified it.¶

9.7. Chain Completeness and Truncation

A receipt chain proves that the receipts a verifier holds have not been altered and have not been reordered. It does not prove that the verifier holds all of them.¶

Removing receipts from the end of a chain leaves every remaining link and every remaining signature valid. A verifier presented with the truncated set cannot distinguish it from a complete one, because nothing in the set commits to how long the set is. This is the omission most worth guarding against: the receipt an operator would prefer a reviewer not to see is usually the most recent. Removing receipts from the middle is detectable, since the next receipt's previousReceiptHash will not match, and that difference is easy to mistake for completeness.¶

Detecting truncation requires a commitment, external to the chain, to the number of receipts and the terminal hash at a given point, signed by the issuer. A verifier that checks a chain against such a commitment can detect omission at the end; a verifier given no commitment MUST NOT report the set as complete, and SHOULD report that it verified integrity only.¶

The commitment is only worth as much as its location. Stored alongside the receipts it describes, it is deletable by whoever deletes the receipts, and the truncated set verifies clean again. It constrains an issuer only once it has reached somewhere that issuer cannot later rewrite. This document does not specify that destination, which depends on what infrastructure the deployment already has and what an adversary controls within it.¶

A further property is out of scope here: these mechanisms let one verifier detect omission from the set it was given, but they do not establish that every verifier was given the same set. An issuer can maintain divergent histories and show each verifier a self-consistent one. Detecting that requires verifiers to compare what they were shown, through a mechanism such as a witnessed or gossiped log, and no construction in this document provides it.¶

9.8. Decisions Are Not Executions

An Access Decision Receipt attests that a policy was evaluated and what it returned. It does not attest that the action then executed, that it succeeded, or what it returned. An "allow" receipt records permission, not performance, and a verifier MUST NOT read one as evidence that the tool ran.¶

Where a deployment needs the executed fact, that is a separate post-execution receipt issued after the invocation returns, binding the decision it acted on to the observed outcome. tool_duration_ms and sandbox_state (Section 2.2) belong to that second receipt, and their presence in a receipt is what distinguishes it from a decision-time one. The value "require_approval" makes the same separation explicit for held actions.¶

Conflating the two is a common error in receipt formats, and it fails in the direction that matters: a reviewer concludes an action occurred because it was permitted, or that it was blocked because no execution receipt exists, when the receipt set only ever established the decision.¶

9.9. Evidence Predicate: False Assurance

The OPTIONAL evidence field (Section 4) can make a decision LOOK well-founded without being so: source.authority, source.kid, and the dimension states are all under the receipt signer's control. A relying party MUST derive assurance ONLY from source.sig values it verifies under out-of-band-pinned keys that are DISTINCT from the receipt signer (see Section 4.3), never from the presence of evidence, a plausible authority, or a matching kid. Two forgeries are defeated by the trust model, each exercised as a negative reference vector ([I-D.agent-governance-testvectors]) that verifies as a receipt yet corroborates nothing: a named-key forgery (a trusted kid copied in with no valid sig) and self-corroboration (the signer signs the claim with its own key). An implementation that surfaces evidence to a human or a downstream policy MUST visibly distinguish dimensions carrying an independent, verified source.sig from those that do not.¶

11.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

[RFC6962]

Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/info/rfc7518>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

11.2. Informative References

[RFC9497]

Davidson, A. and C. A. Wood, "Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497, December 2023, <https://www.rfc-editor.org/info/rfc9497>.

[RFC9901]

Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens (SD-JWT)", RFC 9901, DOI 10.17487/RFC9901, November 2025, <https://www.rfc-editor.org/info/rfc9901>.

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

[I-D.google-cfrg-libzk]

Google, "The libzk Library for Zero-Knowledge Proofs of Predicates over Existing Credentials", 2026, <https://datatracker.ietf.org/doc/draft-google-cfrg-libzk/>.

[I-D.verify-reference]

Farley, T., "Veritas Acta Reference Verifier (@veritasacta/verify)", 2026, <https://www.npmjs.com/package/@veritasacta/verify>.

[I-D.agent-governance-testvectors]

Farley, T., "Agent Governance Cross-Implementation Test Vectors", 2026, <https://github.com/ScopeBlind/agent-governance-testvectors>.

A.1. protect-mcp (Reference Implementation)

• Organization: ScopeBlind¶

• Implementation: https://www.npmjs.com/package/protect-mcp¶

• Description: Security gateway for MCP servers with Cedar WASM policy evaluation, Ed25519-signed decision receipts, and Claude Code hook integration. Supports stdio proxy mode, HTTP hook server mode, shadow mode (log-only), and enforce mode.¶

• Coverage: Access Decision Receipts, Restraint Receipts, Agent Lifecycle Receipts, Spending Authority Receipts.¶

• Licensing: MIT.¶

• Version: 0.11.1.¶

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: Apache-2.0.¶

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: Apache-2.0.¶

A.4. protect-mcp-adk (Google ADK)

• Organization: ScopeBlind¶

• Implementation: https://pypi.org/project/protect-mcp-adk/¶

• Description: Google Agent Development Kit plugin for Ed25519 receipt signing. BasePlugin subclass, wraps tool calls.¶

• Coverage: Access Decision Receipts.¶

• Licensing: MIT.¶

A.5. scopeblind-pydantic-ai (Pydantic AI)

• Organization: ScopeBlind¶

• Implementation: https://pypi.org/project/scopeblind-pydantic-ai/¶

• Description: Pydantic AI Capability for Ed25519 receipt signing. Uses wrap_tool_execute hook for policy evaluation and signing.¶

• Coverage: Access Decision Receipts.¶

• Licensing: MIT.¶

A.6. scopeblind-llamaindex (LlamaIndex)

• Organization: ScopeBlind¶

• Implementation: https://pypi.org/project/scopeblind-llamaindex/¶

• Description: LlamaIndex CallbackHandler for FUNCTION_CALL events. Signs tool calls via BaseCallbackHandler, composes with other handlers (Langfuse, Arize, etc.).¶

• Coverage: Access Decision Receipts.¶

• Licensing: MIT.¶

A.7. @scopeblind/vercel-ai (Vercel AI SDK)

• Organization: ScopeBlind¶

• Implementation: https://www.npmjs.com/package/@scopeblind/vercel-ai¶

• Description: Hooks into Vercel AI SDK's experimental_onToolCallStart and experimental_onToolCallFinish for per-tool-call receipt signing.¶

• Coverage: Access Decision Receipts.¶

• Licensing: MIT.¶

A.8. @scopeblind/langchain (LangChain + LangGraph)

• Organization: ScopeBlind¶

• Implementation: https://www.npmjs.com/package/@scopeblind/langchain¶

• Description: Evidence wrapper for LangChain tool calls and LangGraph node transitions. Produces decision/execution/outcome receipt DAGs.¶

• Coverage: Access Decision Receipts, graph-level receipts.¶

• Licensing: MIT.¶

• Version: 0.2.0.¶

A.9. Microsoft Agent Governance Toolkit (Enterprise Consumer)

• Organization: Microsoft¶

• Implementation: https://github.com/microsoft/agent-governance-toolkit¶

• Description: Consumes receipts via a Cedar policy bridge (PR #667), governed examples for software tool calls (PR #1159) and physical attestation (PR #1168). Not a signing implementation; reads and validates receipts produced by other implementations.¶

• Coverage: Access Decision Receipts (consumer-only).¶

• Licensing: MIT.¶

A.10. AWS Cedar for Agents (WASM Policy Engine)

• Organization: AWS / Cedar Policy¶

• Implementation: https://github.com/cedar-policy/cedar-for-agents¶

• Description: WASM bindings for Cedar policy evaluation in JS/TS agent hosts. SchemaGenerator (PR #64, merged) and RequestGenerator (PR #73) enable Cedar-native policy evaluation that produces the policy_digest field referenced in receipts.¶

• Coverage: Policy evaluation inputs; does not produce receipts directly.¶

• Licensing: Apache-2.0.¶

A.11. Sigstore Rekor (Transparency Log Anchor)

• Organization: Linux Foundation / Sigstore¶

• Implementation: https://rekor.sigstore.dev¶

• Description: Receipts submitted as DSSE entries to Rekor's public transparency log. Provides an independent temporal anchor: the Rekor inclusion proof and signed entry timestamp prove the receipt existed at a specific time without trusting the receipt operator. Working proof-of-concept submitted (issue #2798).¶

• Coverage: Temporal anchoring of any receipt type.¶

• Notes: Uses DSSE envelope with payloadType "application/vnd.scopeblind.receipt+json". Ed25519ph (prehash variant) required for the alternative hashedrekord entry type.¶

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
[ok] Signature valid
[ok] Issuer: sb:issuer:4Kpm7Q3wXx2b
[ok] Decision: allow (deploy)
[ok] Issued: 2026-03-22T14:32:06.551Z