Design question: verifiable approval provenance for cMCP tool catalogs

[SomeshZanwar]

Context

cMCP already provides strong integrity controls for an approved tool catalog.

The gateway validates catalog entries, verifies tool-definition hashes, rejects duplicate tool names, computes a deterministic full-catalog hash, and carries the active catalog hash in the GatewayClaim.

That answers:

Does the catalog loaded by the runtime match the catalog that was approved?

I think there may be a separate governance gap:

Can a verifier determine how that catalog reached its approved state?

The current catalog carries an approved_by string, but not independently verifiable evidence showing:

• which catalog change was reviewed;
• which approval policy applied;
• which reviewer identities approved it;
• whether an approval threshold was satisfied;
• whether pre-activation checks were completed;
• whether the approval history presented to a verifier is complete and current.

LIMITATIONS.md already notes that the gateway trusts the approved catalog and cannot detect when a look-alike or malicious entry was introduced through a compromised reviewer or social-engineering process.

Integrity versus approval provenance

I see these as two separate properties:

1. Post-approval catalog integrity
   The running catalog has not changed from the approved catalog hash.

2. Pre-activation approval provenance
   The approved catalog was produced through a verifiable review and authorization process.

The existing catalog hash addresses the first property. It does not, by itself, establish the second.

This also appears relevant to the Phase 2 statement that measuring the tool catalog closes the typosquatting threat. Measurement can prove that a catalog did not change after approval, but it cannot determine whether a deceptive entry was already present when the catalog was approved.

Possible bounded direction

Would it make sense for cMCP to support a signed catalog-change record for operations such as:

• adding a tool;
• modifying a tool definition or server identity;
• removing a tool;
• rotating a certificate or workload identity;
• approving a catalog exception?

A minimal record might bind:

record version
catalog identifier
sequence number
previous record hash
previous catalog hash
new catalog hash
change-set digest
approval-policy identifier and hash
reviewer identities and key identifiers
approval signatures
automated-check result digest
creation timestamp

The approval policy could support configurable M-of-N authorization rather than a fixed number of reviewers, including:

• distinct reviewer principals;
• optional distinct-role requirements;
• prohibition of self-approval;
• trusted reviewer issuers or keys;
• key expiry and revocation checks.

Possible runtime binding

For an initial cMCP-specific implementation, a verified summary could potentially live under:

{
  "gateway": {
    "catalog": {
      "hash": "sha256:...",
      "drift_detected": false,
      "provenance": {
        "record_id": "...",
        "chain_tip": "sha256:...",
        "approval_policy_hash": "sha256:...",
        "verification_status": "verified"
      }
    }
  }
}

The verifier would require:

catalog provenance record new_catalog_hash
==
gateway.catalog.hash

The provenance status should be produced by the verifier, not accepted from a user-editable catalog field.

Anti-rollback consideration

A signed hash chain can prove internal continuity of the records presented, but it cannot alone prove that the operator supplied the latest valid record.

A production design may therefore also require one of:

• a verifier-pinned latest checkpoint;
• a transparency-log receipt;
• a trusted release manifest;
• another external monotonic-state source.

This may be unnecessary for a first schema iteration, but it seems important to define the assurance boundary explicitly.

Non-goals

This would not prove that:

• an approved tool is objectively safe;
• reviewers cannot collude;
• reviewer identity infrastructure cannot be compromised;
• an upstream server contains no vulnerabilities;
• approval provenance replaces the existing catalog hash and runtime-attestation controls.

It would only establish that the active catalog is bound to a verifiable approval process under a configured policy.

Questions for maintainers

1. Does approval provenance belong within cMCP's scope?
2. Would gateway.catalog.provenance be an appropriate initial location, or should this remain a detached sidecar artifact?
3. Should a first iteration focus only on the schema, canonical signing input, verifier behavior, and test vectors?
4. Is there an existing AgenTrust identity, checkpoint, or transparency pattern that this should reuse?
5. Should the Phase 2 wording distinguish catalog measurement from catalog approval provenance?

I would be interested in contributing a focused design and verification implementation after maintainer feedback on the appropriate scope.

[imran-siddique]

Yes, this belongs within cMCP's governance scope, with a narrower first boundary than embedding a claimed verification status in the runtime object.

The accepted first iteration is a detached, signed catalog-change record plus verifier behavior and deterministic vectors. The verifier—not the catalog author—produces the status and binds the record's new_catalog_hash to the runtime gateway.catalog.hash. Start with schema, canonical signing input, configurable M-of-N rules, reviewer/key lifecycle checks, verification behavior, and negative vectors.

Reuse RFC 8785/JCS and AgenTrust key identifiers/signing conventions where compatible. Treat anti-rollback as a separate assurance: a hash chain proves continuity of what was presented, while freshness requires an externally pinned checkpoint or transparency receipt.

And yes, Phase 2 wording should distinguish measurement from approval provenance. Measurement detects post-approval drift; it cannot prove the approved input was benign.

Tracked as cmcp#517. Closing this discussion as decided and moving implementation detail to the issue.