Hash-bound (or cryptographic) approval for high-risk MCP mutations?

[mirusser]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Hash-bound (or cryptographic) approval for high-risk MCP mutations?

I opened a more concrete Kubernetes-focused RFC here:

containers/kubernetes-mcp-server#1150

I wanted to ask whether this problem belongs at the broader MCP level as an optional mutation-approval profile.

MCP already has useful foundations: tool annotations, human-in-the-loop guidance, and URL-mode elicitation for out-of-band flows. What I’m exploring is whether high-risk mutation tools need a portable lifecycle around the approval itself:

1. plan: server creates a concrete mutation plan, dry-run result, policy findings, and digest
2. challenge: server creates a time-bounded, identity-bound approval challenge for that exact plan
3. execute: server verifies the digest, approval state, TTL, requester/approver binding, and current dry-run result before mutating

The concern is not simply “should the user be asked before a dangerous tool runs?” Existing confirmation/elicitation mechanisms can do that.

The narrower concern is: did the human approve the exact mutation payload that was later executed?

This seems especially relevant for MCP servers that mutate real infrastructure: Kubernetes, cloud resources, CI/CD, IAM, databases, incident response systems, etc.

I have a reference implementation and SafetyE2E tests in Kubernetes-MCP-Guard, but I’m not proposing that implementation specifically. I’m asking whether MCP would benefit from a small optional interoperability profile for digest-bound mutation approval.

Questions:

• Is this already covered by existing or planned MCP primitives?
• Would this be better handled as implementation guidance, an extension, or a formal SEP?
• Are there existing discussions/workstreams around mutation approval, replay protection, or payload-bound HITL that I should join instead?

[mirusser]

I've been thinking and designing possible approach to this problem, here is my design that I've come up with so far:

This document sketches a possible MCP mutation-approval profile.

The profile goal is narrow: bind human approval to an exact mutation intent and an exact review snapshot, then allow execution only after approval and required pre-execution gates pass. It is not a full policy engine, authorization model, workflow product, or domain-specific (like Kubernetes) planning format.

Core Idea

The generic part is the approval lifecycle:

• plan identity
• intent and review digest binding
• plan validity and challenge TTL
• requester and approver binding
• approval challenge lifecycle and terminal challenge outcomes
• replay prevention through execution reuse policy
• audit spine
• approval-bound execution semantics

The domain-specific (Kubernetes in my case) part is the evidence and execution meaning:

• what a mutation intent means
• how impact is previewed
• whether dry-run exists
• whether diff exists
• how freshness or drift is checked
• how domain policy is evaluated
• what the human can safely see
• how execution retries and idempotency work

Roles

Generic Approval Core owns the domain-independent approval lifecycle: plan envelopes, lifecycle state, digest checks, approval challenges, challenge outcomes, approval grants, audit spine, review snapshot canonicalization, and pre-execution gate orchestration. It does not define domain-specific review content, but it may host a review surface while domain adapters supply the domain-specific evidence artifacts rendered there.

Domain Adapter defines, explains, and executes mutation intents for one target system. The Kubernetes adapter is the first adapter and owns Kubernetes mutation meaning, dry-run evidence, diffs, drift detection, Kubernetes policy checks, Kubernetes mutation-intent canonicalization, execution behavior, evidence artifact digests, and adapter audit payloads.

Approval Authority creates approval challenges, enforces approval policies, records challenge outcomes, and issues or exposes approval grants for execution. In my repository, that role is currently implemented by the gateway plus approval store. Another implementation could delegate the role to an external workflow system.

Review Surface renders the immutable review snapshot identified by the review digest to the approver. It must not rely on model-supplied approval content as the source of truth.

Plan Envelope

A plan envelope is a generic wrapper around one domain-specific mutation intent. It is not the mutation itself.

Minimum generic fields:

{
  "planId": "opaque workflow identifier",
  "profile": "mcp.mutation-approval",
  "operationType": "adapter-specific operation label",
  "requester": {
    "subject": "authenticated requester subject"
  },
  "approvalPolicy": {
    "type": "same-subject"
  },
  "executionReusePolicy": {
    "type": "single-execution"
  },
  "validFrom": "2026-05-14T00:00:00Z",
  "validUntil": "2026-05-14T01:00:00Z",
  "freshnessPolicy": {
    "checks": [
      {
        "type": "adapter-defined"
      }
    ]
  },
  "intentDigest": {
    "algorithm": "sha-256",
    "canonicalization": "adapter-defined",
    "value": "..."
  },
  "reviewDigest": {
    "algorithm": "sha-256",
    "canonicalization": "profile-defined",
    "value": "..."
  },
  "evidenceArtifacts": {
    "adapter": "kubernetes",
    "items": [
      {
        "type": "diff",
        "digest": {
          "algorithm": "sha-256",
          "canonicalization": "adapter-defined",
          "value": "..."
        }
      }
    ]
  }
}

planId is an opaque workflow handle for MCP calls, approval URLs, audit correlation, and storage. It is not an integrity mechanism. intentDigest proves the executable mutation intent is the same. reviewDigest proves the human-approved review snapshot is the same.

Digests

The profile uses two digest bindings:

• Intent Digest binds the exact executable mutation intent.
• Review Digest binds the immutable review snapshot, including plan-envelope metadata, the intent digest, evidence artifact digests or digest-bound references, redaction metadata, approval policy, execution reuse policy, freshness policy, requester, plan validity window, and review-surface context.

Every digest declares its algorithm and canonicalization. The generic approval core defines canonicalization for generic envelope metadata and the review digest. Each domain adapter defines canonicalization for its mutation intent and evidence artifacts.

Approval Lifecycle

The generic lifecycle is:

1. Create a plan envelope for a domain-specific mutation intent.
2. Compute intent and review digests using declared canonicalization.
3. Expose trusted plan evidence through a review surface.
4. Create one or more short-lived approval challenges while the plan remains valid.
5. Resolve the approval challenge by recording a challenge outcome, such as approved, denied, rejected, expired, or canceled, through the approval authority.
6. If the challenge is approved, issue or reference an approval grant bound to the plan identifier, requester, approver, intent digest, review digest, approval policy, expiry, and reuse constraints.
7. Before execution, verify all pre-execution gates.
8. Execute through the domain adapter only if every required gate passes.
9. Record the outcome in the audit trail.

Same-subject approval is the default approval policy: the approver must be the same authenticated subject as the requester. Other approval policies, such as delegated approval or multi-party approval, are future extension points.

Pre-Execution Gates

Approval is necessary but not sufficient. Immediately before mutation, approval-bound execution verifies:

• plan validity window still allows execution
• authorization check still passes
• approval authority reports a valid approval grant
• intent digest still matches executable intent
• review digest still matches approved review snapshot
• execution reuse policy allows another successful execution
• declared freshness policy passes
• required domain policy checks still pass

Freshness and domain policy meanings are adapter-owned, but the generic profile requires declared gates to be evaluated before execution. A freshness policy may contain zero or more freshness checks so adapters can combine checks such as dry-run, resource-version matching, preview recomputation, or other target-specific freshness signals.

Replay And Reuse

The default execution reuse policy is single-execution: one approved plan envelope may authorize at most one successful execution.

Reusable plans are an explicit future extension point. They must opt in through an execution reuse policy that defines how many successful executions are allowed and under what conditions.

Retry behavior for failed or unknown execution attempts is domain-adapter-owned because target systems differ sharply in idempotency and failure semantics.

Audit Spine

The profile requires a generic audit spine that proves the lifecycle:

• plan.created
• challenge.created
• challenge.approved
• challenge.denied
• challenge.expired
• challenge.rejected
• challenge.canceled
• grant.issued
• execution.started
• execution.blocked
• execution.failed
• execution.succeeded

Terminal challenge events record challenge outcomes. grant.issued exists only when the approval authority issues or references durable execution authorization for an approved challenge.

Generic audit events should carry plan identifier, intent digest, review digest, requester, approver when relevant, approval policy, grant identifier when relevant, timestamps, and event result. Domain adapters may attach adapter audit payloads such as Kubernetes object references, namespaces, dry-run summaries, drift messages, and policy findings.

[cristianleoo]

This shape is clearer with the Generic Approval Core and Domain Adapter separated. The part I would keep especially explicit is that the approval core should own lifecycle integrity, while the adapter owns semantic freshness.

For high-risk mutations, I would want the execution receipt to show both categories side by side:

• lifecycle checks: plan id, requester, approver, challenge outcome, grant id, intent digest, review digest, TTL, reuse policy
• adapter checks: current dry-run or preview result, domain policy findings, drift/freshness result, final target/resource identity, execution outcome

That separation avoids a common failure mode where an approval system proves the user approved a digest, but the operator still cannot tell whether the world changed between review and execution. Kubernetes makes that obvious because resource versions, dry-run output, and policy findings can drift. The same pattern shows up for CI/CD, cloud resources, IAM, and database migrations.

I also like requiring the review surface to render trusted evidence rather than model-supplied approval text. The model can summarize, but the digest-bound review snapshot should be built from enforcement-owned artifacts. Otherwise a compromised or confused agent can preserve the envelope while changing the human-facing explanation around it.

Disclosure: I work on Armorer Labs.