From 7b8e2bde214b35fd6f0d4f3899789388d623164d Mon Sep 17 00:00:00 2001 From: Rich Smith Date: Wed, 19 Aug 2026 22:32:20 -0400 Subject: [PATCH] fix: restore auth binding requirement to Security Considerations (#9) --- specification/draft/tasks.md | 1 + 1 file changed, 1 insertion(+) diff --git a/specification/draft/tasks.md b/specification/draft/tasks.md index ef700cc..15aa2d9 100644 --- a/specification/draft/tasks.md +++ b/specification/draft/tasks.md @@ -900,6 +900,7 @@ The `tasks/get` endpoint returns exactly what the underlying request would have ## Security Considerations - **Task ID unguessability.** A server **MAY** use task IDs as bearer tokens for a server's stored state. Servers **MUST** generate them with sufficient entropy that a third party cannot enumerate or guess them. +- **Auth binding.** Servers **MUST** perform authentication and authorization checks on each task-related request to ensure that the client has permission to access a task. - **Cross-caller correlation.** Because there is no `tasks/list`, a server cannot inadvertently leak the existence of one caller's tasks to another. This is an improvement over the `2025-11-25` tasks specification, in which a poorly-scoped list could expose unrelated task IDs. - **Input-request trust model.** `inputRequests` carry elicitation and sampling payloads from the server through the client to the user or model. Hosts **MUST** apply the same trust model to these payloads as they would to standard elicitation/sampling requests. A task is not a higher-trust channel.