GHSA-f9ff-5x35-7gfw: Grackle: Fail-open authorization in the MCP tool layer lets scoped agents perform cross-task and cross-session mutations (IDOR)

Summary Authorization for scoped (agent) MCP callers is enforced inline, per tool, and is applied inconsistently — several mutating tools silently omit the ancestry/workspace check that their siblings perform. Because the MCP server authenticates all outbound gRPC with the full server API key and the backend gRPC handlers perform no caller-based authorization, the MCP tool layer is the *sole* authorization boundary. A malicious or prompt-injected scoped agent can therefore perform cross-task and cross-session operations it should not be allowed to (an IDOR / privilege-boundary bypass). This advisory bundles the audit's Systemic Pattern A findings: F2, F6, F7, F12 (and the duplicate F19). Affected versions @grackle-ai/mcp (with @grackle-ai/plugin-core / @grackle-ai/auth) at 0.132.1 and earlier. Root cause - mcp-server.ts:111-127 (createGrpcClients) sets Authorization: Bearer ${apiKey} (the full server key) on every outbound gRPC call. - Backend handlers (updateTask, deleteTask, resumeTask, killAgent, getTask in plugin-core) take only the request message — no AuthContext — and act on whatever ID is passed. - Therefore scope must be enforced in each MCP tool handler. Some call assertCallerIsAncestor (task_complete, task_start, session_attach, session_send_input); their destructive siblings do not. New tools that forget the check fail open. F2 — task_update / task_delete / task_resume bypass ancestry (High) Location: packages/mcp/src/tools/task.ts:226 (task_update), :393 (task_delete), :465 (task_resume). These accept an arbitrary taskId with only a ROOT_TASK_ID special-case and no assertCallerIsAncestor. The central dispatcher hardcodes its workspace gate to name === "task_show", and these tools' Zod schemas have no workspaceId field (so the blanket injection is stripped). They are not in DEFAULT_SCOPED_MCP_TOOLS but are in the shipped ORCHESTRATOR_MCP_TOOLS / `