Rolling Out MCP on AEM: Lessons from Early Production

Adobe has exposed AEM's full operational surface to AI clients through five Model Context Protocol servers: Content and Content Read-Only (GA, 2026.1.0), Cloud Manager (2026.4.0, April 2026), and Quickstart and Dispatcher bundled with the local SDKs. Every AEM team is running the same demo — Claude Desktop creating a content fragment from natural language. The harder question, and the subject of this session, is what it takes to put that in front of real users without surprising anybody. This is a retrospective from early production, not a product walkthrough.

MCP on AEM does not introduce a new permission model. When a user authenticates through Adobe IMS, the server acts under that user's full AEM identity — their ACLs, nothing more, nothing less. The real rollout questions are about server selection and credential hygiene: which MCP servers you enable, who connects to which server, and whether you issue service accounts or federate personal Adobe IDs.

We trace a single patch_fragment call — OAuth 2.0 PKCE through Adobe IMS, the AEM ACL check performed as the authenticated user, JSON Patch with ETag optimistic concurrency — and cover where early rollouts get surprised: users with broader access than their team realized after years of accumulated group memberships, and service accounts provisioned broadly during setup that nobody went back to audit.

The Cloud Manager MCP section covers the pipeline confirmation gate — effectively the one governance mechanism MCP adds on top of IMS identity. What it protects, where it adds friction, how we instrument it. Plus the measurement problem: logging tool calls so you can separate real productivity gains from novelty use.