Rewrite access control section to explain session-binding

Author: LucaButBoring

docs/specification/draft/basic/utilities/tasks.mdx

@@ -775,17 +775,15 @@ The `tasks/result` endpoint returns exactly what the underlying request would ha
 
 ### Task Isolation and Access Control
 
-1. Receivers **SHOULD** scope task IDs to prevent unauthorized access:
-   1. Bind tasks to the session that created them (if sessions are supported)
-   1. Bind tasks to the authentication context (if authentication is used)
-   1. Reject `tasks/get`, `tasks/list`, `tasks/result`, or `tasks/cancel` requests for tasks from different sessions or auth contexts
-1. Receivers that do not implement session or authentication binding **SHOULD** document this limitation clearly, as task results may be accessible to any requestor that can guess the task ID.
-1. Receivers **SHOULD** implement rate limiting on:
-   1. Task creation to prevent resource exhaustion
-   1. Task status polling to prevent denial of service
-   1. Task result retrieval attempts
-   1. Task listing requests to prevent denial of service
-   1. Task cancellation requests to prevent abuse
+Task IDs are the primary mechanism for accessing task state and results. Without proper access controls, any party that can guess or obtain a task ID could potentially access sensitive information or manipulate tasks they did not create. To prevent unauthorized access, receivers **SHOULD** bind tasks to the session or authentication context that created them.
+
+However, context-binding is not practical for all applications. Some MCP servers operate in environments without session management (such as single-user tools), or use transports that don't support sessions or authentication.
+In these cases, receivers **SHOULD** document this limitation clearly, as task results may be accessible to any requestor that can guess the task ID.
+When context-binding is not available, receivers **SHOULD** use cryptographically random task IDs with sufficient entropy to make guessing infeasible, and consider implementing shorter TTL durations to limit exposure windows.
+
+If context-binding is supported, for `tasks/get`, `tasks/result`, and `tasks/cancel` requests, receivers **MUST** reject requests for tasks from different sessions or authentication contexts. For `tasks/list` requests, receivers **MUST** filter the returned task list to only include tasks belonging to the requestor's session or authentication context.
+
+Additionally, receivers **SHOULD** implement rate limiting on task operations to prevent denial-of-service and enumeration attacks.
 
 ### Resource Management