In July 2026 the Model Context Protocol team promoted its Enterprise-Managed Authorization extension to stable status. Organisations can now control access to MCP servers through their own identity provider, centrally, the same way they control access to anything else that matters. The final specification lands on 2026-07-28. For anyone who has spent the last eighteen months explaining to a security team why a protocol with 9,652 registered servers and no central auth story belongs anywhere near production data, this is the release that ends the argument.
They’re right to ship it. Enterprise adoption made it necessary: 41% of surveyed software organisations now run MCP servers in limited or broad production. This was the missing piece.
But I think the industry is being too polite about what centralised authorization does not do.
Authorization answers a question nobody was losing sleep over
MCP is a port. It exposes whatever cargo you already have. Enterprise-Managed Authorization puts a proper security gate at that port. It checks the credentials of every truck that pulls up, logs the plate, and turns away anyone without a badge from your identity provider. That is real work and it was overdue.
What it does not do is open a single crate.
The gate verifies who is allowed to move cargo. It has no opinion on whether the crate labelled “12V, IP67, 450 lumens” contains a product with those properties. In product data, that second question is the entire job.
This distinction stayed academic as long as agents only read. For most of 2025 and the first half of 2026, the agentic PIM story was a retrieval story: let the model see the catalog, let it answer questions, let it draft descriptions a human then approves. Access control was sufficient governance, because the worst outcome of a bad read is a bad answer, and a human was still holding the pen.
That stopped being true in the last few weeks. Akeneo shipped Agentic Ziggy on 2026-07-08, a fleet of agents that enrich and manage product data, not just describe it. Salesforce made Agentforce Commerce generally available on 2026-07-06, including a Merchant Agent that reorganises catalogs from natural-language instruction. The direction is unambiguous and it is the right direction. Agents are becoming writers.
An agent that writes into your PIM is not a retrieval problem with extra steps. You have added a new class of author, operating at machine speed, to a system whose entire economic value rests on being the place where the true version of a product lives.
The number that governs this is not accuracy
The industry argument about agentic product data keeps landing on accuracy. Wrong metric. Or more precisely, a metric that quietly assumes the thing you actually need.
Accuracy is a property you measure after the fact, in aggregate, against a labelled sample. Governance is a decision you make in advance, per record, about which changes are allowed to land without a human looking at them. A model that is 94% accurate across a catalog is not telling you which 6% to check. If you cannot answer that, 94% stops being a quality score and becomes a distribution of unlocated errors across your entire product range.
Here is what that looks like in practice, from 70+ PIM implementations. A classification store carrying 500 to 600 attributes per product is not an outlier in our ICP. That is the normal shape of a B2B catalog. Run an agent across 10,000 products at that attribute depth and you have generated somewhere in the region of five million attribute values. At 94% accuracy, roughly 300,000 of them are wrong, scattered, unlabelled, and now indistinguishable from the correct ones because they arrived through the same pipe with the same timestamp and the same author.
Finding them afterwards is not a data quality exercise. It is an archaeology project.
The cost of rework is the cost you already know
We have a reliable anchor for what it costs to move product data by hand. Bringing 1,000 products to PIM-ready manually runs to roughly three months of work and about EUR 14,000. That figure is well established in our implementations and it is the number most PIM business cases are built to eliminate.
What is less discussed is that the number is roughly symmetric. Auditing and correcting 1,000 products that were machine-written without provenance costs about the same as entering them, and often more, because correction requires first determining which records need correcting. Manual entry has a known scope. Post-hoc cleanup has an unknown one.
| Path | Unit of work | Scope known upfront | Effective cost per 1,000 SKUs |
|---|---|---|---|
| Manual entry | Enter every record | Yes | ~EUR 14,000, ~3 months |
| Agent writes, no provenance | Enter nothing, audit everything | No | ~EUR 14,000 and up, unbounded tail |
| Agent proposes, human decides on flagged records | Review the uncertain subset | Yes | Fraction of the above |
Only the third row converts automation into savings. The other two relocate the labour and call it progress. And that row only exists if every machine-written value arrives with two things attached: where it came from, and how confident the system was when it wrote it.
That is why openProd was built to propose, not commit. Every extracted value carries a confidence score and a traceable source: this attribute, from this page of this supplier PDF, at this level of certainty. High-confidence values flow through. Uncertain ones surface for a human. The review queue ends up being a subset of the work, sized by the system, instead of the whole catalog re-examined by hand.
The performance numbers hold up under that constraint. A supplier PDF to PIM-ready in about 15 minutes on a live file. 4,000 products processed in roughly 1.5 minutes. 128 product variants recognised from a single PDF. Up to 95% time saved against the manual baseline. None of those figures depend on removing the human from the decision. They depend on removing the human from the 95% of the work where there is nothing to decide.
What a CFO should ask before the first agent gets write access
The budget question about agentic product data usually gets framed as a licensing question. Frame it as a liability question instead.
Three things are worth establishing before any agent is granted write permission on a production catalog, and none of them are answered by an authorization layer:
Can you reconstruct the origin of any given attribute value? Not the change log entry saying an agent wrote it at 14:32. The source document, the page, the confidence at the time of writing. Without this, every downstream dispute about a specification becomes unresolvable, and in regulated categories that is not an inconvenience. The EU AI Act’s data quality provisions put the burden of demonstrating data provenance on the operator, not on the model vendor.
Is there a defined threshold at which a machine-written change requires human approval, and who set it? If the answer is that the model writes whatever it produces, the organisation has not delegated a task. It has delegated a decision, usually without anyone senior realising they made that call.
What is the rollback unit? Restoring a catalog to yesterday is not rollback, it is data loss for every legitimate change made in between. The meaningful unit is the individual machine-written value, reversible on its own.
An organisation that can answer these three can safely let agents write at scale, and will get the full 95%. An organisation that cannot has not automated its product data operation. It has moved the entry cost from a budgeted line item to an unbudgeted one, and pushed the discovery of that cost out by two quarters.
The upstream point, one more time
One structural reason makes this sharper at the supplier onboarding layer than anywhere else in the stack.
An agent operating inside your PIM works on data that has already been through your process. It has a shape, a history, an owner. An agent operating on inbound supplier files works on data that has none of those things: a PDF that arrived by email, an Excel export with merged header rows, a spec sheet where the units change halfway down the table. That is the layer where the confidence question is most acute and where it is least often asked, because most PIM data quality metrics only start counting once the record is already inside.
The audit you run on supplier data before onboarding is the same audit an agent needs to run on itself, continuously, at write time. Not an extra governance layer bolted onto the automation. The thing that makes the automation worth having in the first place, and whose absence explains why PIM projects stall six months after go-live despite the platform working exactly as specified.
The question
Centralised authorization for MCP is genuinely good news, and every team running agents against product data should adopt it. It settles who is allowed through the gate.
The harder question stays open, and it stopped being theoretical this month. The agents arriving this quarter hold the pen. They are no longer reading over your shoulder.
Are you automating work, or automating rework?
If your agents are about to start writing into your catalog, the honest test is simple: pick one attribute on one product, and try to reconstruct where the value came from and how sure the system was. If that takes longer than a minute, the governance layer is not there yet.
We can show you what it looks like when it is, on one of your own supplier files, in about fifteen minutes. Book a demo.
