This is a good shape for async approval because the MCP-visible part stays narrow: the client gets a task handle, while the approval system stays server-side.

One invariant I would make explicit is that the task handle is not authority by itself. It should be bound to the exact original call envelope and to the policy evaluation that produced the requestable denial.

The server-side record should preserve at least:

• task id;
• tool name;
• canonical arguments digest;
• requester principal/session;
• subject or resource being acted on;
• policy id/version;
• approval request id;
• disposition;
• expiry/freshness window.

On approval, the server should re-evaluate policy against the same envelope before execution. If the tool, arguments, principal, resource, policy version, or freshness window no longer match, the task should resolve as stale/denied with no side effect.

Acceptance tests I would want:

• requestable denial returns a task without executing the tool;
• approval resumes the call at most once;
• denial produces a terminal disposition, not an execution error;
• cancelled or expired task cannot later execute;
• changed arguments or principal require a new approval;
• result retrieval does not expose backend approval artifacts.

That keeps async approval durable without turning taskId into a bearer approval token.

Strongly agree, and this is the invariant worth stating in normative text rather than leaving implied. The handle is a reference to a pending decision, never a grant. The SEP leaned this way in a few scattered places; per your comment I have consolidated it into one explicit rule plus a required binding record. Applied in 8d12c295.

Where it already lived:

• Completion requires a fresh re-evaluation on approval (approval is an input to a new decision, not a standing grant; PDP authoritative at enforcement), plus an execution-time freshness/credential check.
• Security / Confused deputy binds the task to the originally evaluated subject, resource, action, and context and forbids steering execution to a different operation.
• At-most-once + best-effort dedup, and authorization artifacts stay server-side (taskId is not a bearer token; binding material never crosses the wire).

What I added (new subsection "The task handle is not authority", plus edits to Completion and Security):

1. An explicit invariant: the taskId is not authority. Authority is the PDP decision, re-derived at execution against the original call envelope.
2. A normative binding record the server MUST retain and MUST check before executing: task id, tool name, canonical arguments digest, requester principal/session, subject/resource, approval request id, disposition, and expiry/freshness window (your list, adopted close to verbatim).
3. An explicit envelope-match-or-new-approval rule: if tool, arguments, principal, or subject/resource differ from the bound envelope at execution time, the task resolves denied-not-executed with no side effect and a changed call requires a new access request. This sharpens the dedup section, which only spoke to retries.

One refinement I flagged rather than adopting verbatim: policy id/version. I record it (audit, drift detection), but did not make a version change auto-resolve to stale. The SEP re-evaluates against current policy, so a policy change should produce a fresh allow-or-deny, not an automatic denial; pinning to the exact version that produced the requestable denial would also reject approvals still valid after an unrelated policy edit. So in the text: envelope fields (tool/args/principal/resource) are an exact-match binding; policy version is recorded and re-evaluation runs against current policy. If you specifically want version pinning for a class of high-assurance tools, that reads as a deployment policy on top rather than the default. Did you mean strict pinning or drift-detection?

Your acceptance tests are exactly the conformance scenarios this needs, and most are MCP-observable, so I folded them into the conformance clause (now a checklist):

• requestable denial returns a task without executing — observable
• approval resumes at most once — observable
• denial is a terminal disposition, not an execution error — observable (the denied-not-executed vs execution-error distinction, carried in the CallToolResult body)
• cancelled or expired task cannot later execute — observable (ties to the cancel-before-execution boundary rule)
• changed arguments or principal require a new approval — observable (the envelope-match test above)
• result retrieval does not expose backend approval artifacts — observable

Thanks, this tightens the "durable handle, not bearer token" line that is the whole point of keeping the approval system server-side.

On the Limitations: you give two safety conditions for a side-effecting tool — a durable consumer, or that the effect is "independently auditable." The durable-consumer half has a protocol shape (poll the task). The independently-auditable half doesn't — it's a requirement with nothing in the task model to satisfy it against.

Is that intentional (left fully to deployments), or is leaving room for it in the task model in scope for this SEP? The two conditions read as parallel, but only one is actionable at the protocol level.

I would split the answer in two.

The audit system itself can stay deployment-owned. I do not think this SEP needs to standardize the audit record schema, storage backend, retention policy, or verifier format.

But I would avoid leaving "independently auditable" as pure prose, because then the two safety conditions are not really parallel. The durable-consumer path has a protocol object to come back to. The independently-auditable path should at least have a task-visible hook that lets the final task outcome reconcile to some server-side evidence.

The smallest shape I would leave room for is:

• the task is still bound to the original call envelope: task id, tool, arguments digest, requester/subject/resource, policy context, and approval request;
• the terminal task result still distinguishes approved-executed, denied-not-executed, execution-error, and cancelled;
• if the side effect can complete without a live consumer, the server records an outcome entry keyed by the task id / decision id / original call digest;
• tasks/get can surface an opaque outcome or audit reference when the deployment exposes one;
• a deployment with neither a durable consumer nor a later-verifiable outcome record should be called out as unsupported for side-effecting tools, not merely discouraged.

That keeps the audit evidence out of MCP core while making the requirement testable. A later verifier does not need the whole approval backend on the MCP wire, but it should be able to answer:

1. did the tool execute or not;
2. which bound call envelope did that outcome apply to;
3. was the approval/denial/cancel terminal before execution;
4. can a retry or lost consumer cause a second mutation.

So my read is: leave the evidence format to deployments, but leave an explicit task-model attachment point for an opaque outcome/audit reference. Otherwise "independently auditable" is true operationally, but not actionable for implementers reading the SEP.