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.
wolf
How do you combat the problem that in practice certain tasks (e.g. creating new marketing content) are only done „for real” in Production? Graduated permission roll-out is good, but what gives you the confidence for the final step (write access to production)?
Divanshu
You're right moving through phases isn't what gives us confidence by itself. Dev and Stage content is synthetic; the real marketing task only exists in Production. If we thought calendar time in earlier phases was the safety mechanism, we'd be wrong. What actually gives confidence for the final step is the other five lessons, not phase progression.
Lisa Brown
Does this indicate a new role or sub-role within the authoring team, like a permissions group for agentic-enabled authors who may sit more in IT? This would avoid having Shadow IT show up in marketing where nontechnical resources are managing dev workflows? Authors are a cost center anyway and it may be beneficial to use workflows like this to start to migrate them into IT long-term.
Pranay Rajput
Yes and honestly it emerged naturally to us without designing it. Some authors just got it. They understood the tool calls, knew what to do when something broke. They became the go-to before anything hit IT. Should you formalize that? I think yes. A permissions tier like agentic-enabled authors and IT owns the governance, authors stay in their content workflow. If marketing figures this out on their own and starts wiring things up without you knowing you will find out when something breaks in production.
KatieP
How do you limit the machine ACLs while also providing access as a proxy to the human author? Do you remove permissions from the humans too during the acl cleanup?
Divanshu
When it comes to MCP - it impersonates the user session so idea is not to clear up all of it but to make sure everyone has related ACLs not more not less. By clearing unknown broad permissions we are adding the risk of getting something wrong more often. So we can narrow down the permissions.
Lisa Brown
How did the related Workfront project timelines shift as a result of the new process? Were you able to measure the payoff on better SLAs, fewer compliance exceptions, as well as sentiment in the task comments?
Pranay Rajput
We don't actually use Workfront so I can't speak to that directly. But the broader question did we measure the payoff ! fair one. And honestly, not well enough. What we saw was authors started asking better questions instead of just saying something's broken. But we didn't have clean baselines going in so we can't give you hard numbers.If you're starting now set your baseline before rollout.Six months in you'll want to show the business something concrete. Thats our lesson learned.
Tomasz
How do you trace who did what why? These chats are burried in people's chat so a lot of context is hidden there. Did you consider plugging it into some surface like ticketing system, and have dumps of the chats come back there for traceability?
Divanshu
What we see today is the similar logs that we see using UI because it's no different from a user making changes to LLM making changes on behalf "TODAY". But looking forward to have more detailed stacktraces.