MDM #17. Designing MDM APIs for AI Agents: Contracts, Context, Security and MCP
AI agents change what enterprises should expect from Master Data Management APIs.
Traditional MDM APIs were usually designed for application integration: an ERP system requests a supplier, a CRM application updates a customer, or a data pipeline extracts mastered entities for downstream consumption.
An AI agent behaves differently.
It may need to determine which business entity a user means, retrieve only the attributes relevant to a decision, understand whether the information is authoritative, choose an appropriate business operation, recover from ambiguity and decide when a human approval is required.
That does not mean MDM needs an entirely new protocol.
It means the API contract must become more explicit about identity, semantics, authority, side effects, version state and recoverability.
An AI-ready MDM API should not merely expose master-data records. It should expose governed business capabilities that machines can invoke safely and predictably.
This distinction is the foundation of an enterprise MDM API strategy for the Agentic AI era.
The MDM API Problem Is Not Primarily About REST versus MCP
Discussion around AI integration increasingly focuses on protocols such as the Model Context Protocol, or MCP.
That is important, but it is not the first design question.
The more fundamental questions are:
- What is the authoritative business entity?
- Which operations should consumers be allowed to invoke?
- What does each operation mean?
- Which attributes may be returned or changed?
- How should ambiguous matches be handled?
- How should concurrent changes be detected?
- Which operations require approval?
- What happens when an operation is retried?
- How can every material action be reconstructed?
If these questions are unresolved, adding an MCP server only exposes an ambiguous MDM architecture through a new interface.
↓
Stable API Contracts
↓
Security & Governance
↓
REST / GraphQL / Events / MCP
↓
Applications & AI Agents
The business capability should therefore be designed before the protocol adapter.
1. AI Agents Need Business Capabilities, Not Database-Shaped APIs
A conventional CRUD interface might expose:
POST /suppliers
PATCH /suppliers/12345
DELETE /suppliers/12345
Those operations may be technically valid, but they say little about the business meaning of the action.
For MDM, meaningful operations are often richer:
GetGoldenRecord() — retrieve the current mastered entity
GetPotentialMatches() — return candidate duplicate entities and evidence
ProposeSupplierChange() — create a governed modification request
ValidateMasterData() — evaluate proposed values against domain rules
ProposeMerge() — create a merge recommendation without executing it
ApproveMerge() — execute an authorized merge after required approval
This approach makes the API easier for applications and AI agents to use because the contract represents a business capability rather than an unrestricted data operation.
Entity Resolution Should Be a First-Class API
One of the most important MDM capabilities for AI is entity resolution.
A human may ask:
“Check whether ABC Korea is an approved supplier and whether we have an active contract.”
The agent should not guess which internal supplier ID corresponds to “ABC Korea.”
A stronger pattern is:
↓
Entity Resolution API
↓
Authoritative Supplier ID
↓
Supplier Master API
↓
Contract / Risk / Transaction Services
The resolution service should also be able to return ambiguity.
For example:
candidate_count: 3
next_action: REQUEST_ADDITIONAL_IDENTIFIER
That response is safer than silently selecting the highest-scoring candidate.
2. API Contracts Must Be Machine-Readable and Semantically Stable
The OpenAPI Specification provides a standardized way to describe HTTP API surfaces and semantics in a machine-readable form.
OpenAPI Initiative — OpenAPI Specification
A formal API contract allows development, testing and governance tools to understand:
- available operations,
- required parameters,
- schemas,
- authentication requirements,
- response structures, and
- defined error conditions.
For MDM, however, technical schema is only part of the contract.
An enterprise-grade contract should also define business semantics.
An MDM API Contract Needs More Than Field Names
| Contract Element | Question It Must Answer |
|---|---|
| Entity Semantics | What business entity does this API represent? |
| Authoritative Status | Is the response mastered, provisional or sourced directly from another system? |
| Operation Semantics | Does the operation retrieve, recommend, request or execute a business change? |
| Preconditions | What must be true before the operation can execute? |
| Side Effects | Will the call change MDM state or downstream systems? |
| Authorization | Which identity and authority are required? |
| Concurrency | What happens if the entity changes between read and update? |
| Failure Semantics | Can the caller distinguish validation, authorization, conflict and dependency failures? |
3. Return Trusted Context — but Do Not Invent a Universal “Quality Score”
The original generation of MDM APIs often returned the current entity state with little governance context.
AI consumers can benefit from additional information, but enterprises should avoid creating an arbitrary numeric “trust score” and treating it as objective truth.
A stronger response separates the mastered entity from specific governance signals.
{
"entity": {
"masterId": "SUP-001234",
"entityType": "Supplier",
"legalName": "ABC Electronics Co., Ltd.",
"status": "ACTIVE",
"country": "KR"
},
"mastering": {
"authoritative": true,
"entityVersion": "184",
"resolvedAt": "2026-09-26T08:40:00Z"
},
"provenance": {
"legalNameSource": "ERP_VENDOR_MASTER",
"countrySource": "SUPPLIER_REGISTRATION"
},
"quality": {
"ruleset": "supplier-core-v7",
"status": "PASS",
"evaluatedAt": "2026-09-26T08:35:00Z"
},
"governance": {
"domainOwner": "Supplier Data Office",
"classification": "INTERNAL"
}
}
This response does not claim that a supplier is “98.5% trustworthy.”
Instead, it provides specific evidence that an application or agent can interpret according to the workflow.
Context Should Be Use-Case Specific
An AI agent does not need every available MDM attribute.
A procurement agent might need:
- supplier master ID,
- legal identity,
- status,
- qualification state,
- country, and
- relevant relationship identifiers.
It may not need bank-account details, internal steward notes or every historical cross-reference.
Returning unnecessary attributes increases privacy, security and context-management risk.
AI-friendly APIs should provide sufficient context, not maximum context.
4. Separate Read Capabilities from Change Capabilities
This is one of the most important design principles for Agentic MDM.
An agent that can search supplier records does not automatically need authority to modify them.
A useful capability structure is:
Resolve · Search · Retrieve · Explain
↓
RECOMMEND
Detect Duplicate · Recommend Attribute · Suggest Relationship
↓
PREPARE
Create Change Request · Prepare Merge Proposal
↓
EXECUTE
Apply Approved Low-Risk Change
↓
HIGH-IMPACT EXECUTION
Merge · Delete · Critical Attribute Change
The same API identity should not necessarily have access to every layer.
Merge Is Not Just Another Update
MDM-specific operations can have complex side effects.
For example, current Reltio documentation shows that entity merges can combine attributes, crosswalks and relationships, preserve survivor and contributor identities, generate merge events and interact with hierarchy structures.
The broader architectural lesson is vendor-neutral:
A merge API should not be exposed to an AI agent as if it were equivalent to editing a description field.
High-impact operations need explicit preconditions, authority and recovery design.
5. Concurrency Must Be Explicit
An AI agent may read a master record, reason for several seconds or minutes, and then submit a proposed change.
The entity may have changed in the meantime.
Blindly overwriting the latest state introduces a classic lost-update problem.
A safer contract includes an entity version or equivalent concurrency token.
↓
Agent Evaluates Change
↓
Submit Change against Version 184
If Current Version = 184 → Continue
If Current Version = 185 → Return STALE_VERSION
The caller must then retrieve the updated entity and reassess the action.
HTTP itself provides conditional-request mechanisms, and API implementations can use equivalent optimistic-concurrency controls appropriate to the platform.
IETF — RFC 9110: HTTP Semantics
6. Retry Safety Is a Business Requirement
Agents retry operations.
Networks time out. Tool calls fail. Responses can be lost even when the server completed the transaction.
For read operations this is usually manageable.
For master-data writes, uncontrolled retries can create:
- duplicate change requests,
- duplicate entities,
- repeated approvals,
- repeated downstream events, or
- unexpected workflow transitions.
Write contracts therefore need a defined retry strategy.
For example, a client-generated operation identifier can allow the service to recognize that the same logical request has already been processed.
+ Operation Identifier
→ MDM Service
Repeated Same Request
→ Return Existing Result
Rather Than Execute Again
The exact implementation is platform-specific. The important point is that retry behavior must be part of the API contract rather than left to agent improvisation.
7. Errors Must Be Machine-Actionable
A human developer can interpret an error such as:
An AI agent needs more deterministic information.
A useful error taxonomy might include:
| Error | Expected Caller Behavior |
|---|---|
| ENTITY_NOT_FOUND | Verify identifiers or initiate entity-resolution flow. |
| AMBIGUOUS_MATCH | Request additional identifying information or escalate. |
| VALIDATION_FAILED | Correct proposed values using structured validation results. |
| STALE_VERSION | Retrieve current entity and reassess the proposed action. |
| NOT_AUTHORIZED | Do not retry with altered parameters to bypass policy. |
| APPROVAL_REQUIRED | Create or continue the governed approval workflow. |
| TEMPORARY_FAILURE | Retry according to defined backoff and retry limits. |
The agent should not need to infer critical recovery behavior from free-form prose.
8. Authorization Must Operate at Entity, Attribute and Function Level
MDM APIs expose high-value business objects and therefore require more than endpoint authentication.
The OWASP API Security Top 10 specifically identifies risks including:
- broken object-level authorization,
- broken authentication,
- broken object-property-level authorization, and
- broken function-level authorization.
These risks map directly to MDM.
An identity may be permitted to call a supplier endpoint but still lack permission to:
- read bank details,
- modify tax identifiers,
- access suppliers from another legal entity,
- execute a merge, or
- approve its own change request.
The Authorization Decision Should Be Resource-Aware
Human · Application · Agent
+
RESOURCE
Domain · Entity · Attribute
+
ACTION
Read · Recommend · Update · Merge · Approve
+
CONTEXT
Purpose · Delegation · Risk · Workflow State
=
AUTHORIZATION DECISION
NIST SP 800-207A similarly emphasizes identity-based authorization for applications and services rather than relying only on network location.
NIST — SP 800-207A: Zero Trust Access Control for Cloud-Native Applications
9. Do Not Force Every MDM Consumer Through One Physical API Gateway
A centralized access layer can be useful, but “one gateway for everything” should not become an architectural rule.
Large enterprises frequently operate multiple regions, clouds, MDM platforms and domain architectures.
A more scalable principle is:
Standardize the logical MDM contract and policy model. Do not assume that every request must pass through one physical gateway.
The architecture may include:
- API gateways,
- service meshes,
- domain façades,
- regional endpoints,
- vendor-native APIs, and
- enterprise MDM services.
What matters is that consumers receive stable business semantics and consistent security controls.
10. API and Event Architecture Solve Different Problems
This article should also be separated from the real-time data architecture discussed in the previous MDM article.
The distinction is straightforward.
| API | Event |
|---|---|
| Ask for current state | Notify that state changed |
| Invoke a business capability | Publish the outcome of a business event |
| Request / response | Asynchronous distribution |
| Useful for queries and commands | Useful for propagation and downstream reaction |
A mature MDM architecture often needs both.
↓
Approved Master Change
↓
MDM Commits New State
↓
Master-Data Change Event
↓
Downstream Consumers React
11. Version the Contract, Not Every Internal Implementation
API stability matters because AI agents, applications and workflows may depend on a contract for years.
But arbitrary rules such as “every old version must be supported for exactly 12 months” are not universally appropriate.
A better lifecycle policy defines:
- what constitutes a breaking change,
- how consumers discover versions,
- how deprecated capabilities are announced,
- how active consumers are identified,
- how migration is tested, and
- when an old version can be retired safely.
API inventory is itself a security requirement. OWASP identifies improper API inventory management as a major API risk because forgotten versions and undocumented endpoints can remain exposed.
Do Not Leak the Internal MDM Data Model into Every Consumer
A second versioning problem appears when the public API mirrors the vendor's internal physical schema.
For example, if every consuming agent directly depends on vendor-specific crosswalk, survivorship and configuration structures, replacing or upgrading the MDM implementation becomes much harder.
A domain-oriented enterprise contract can isolate consumers from unnecessary platform details.
Supplier · Customer · Product Semantics
↓
Enterprise MDM Service Layer
↓
Vendor-Specific MDM Implementation
Vendor-native APIs remain valuable for administrative and specialist use cases, but they do not need to become the universal enterprise contract.
12. MCP Complements the MDM API — It Does Not Replace It
Model Context Protocol standardizes how AI applications can discover and interact with tools, resources and contextual services.
Model Context Protocol — Specification
This makes MCP relevant to MDM because an enterprise can expose bounded master-data capabilities as AI tools.
For example:
get_supplier_profile
validate_supplier_change
create_supplier_change_request
get_potential_matches
The MCP server can describe these capabilities to an AI client.
But the server should normally invoke governed backend APIs rather than bypassing the MDM service layer.
↓
MCP CLIENT
↓
ENTERPRISE MDM MCP SERVER
↓
GOVERNED MDM APIs
↓
MDM PLATFORM
What MCP Does — and Does Not Do
| MCP Can Help Standardize | MCP Does Not Automatically Guarantee |
|---|---|
| Tool discovery | Correct master data |
| Tool input and output schemas | Correct entity resolution |
| Client-server interaction | Business authorization |
| Transport-level authorization mechanisms where implemented | Attribute-level policy enforcement |
| Portable AI-facing capability descriptions | Data quality or regulatory compliance |
The MCP specification's authorization model addresses access between MCP clients and restricted servers, including HTTP-based authorization flows. Business-level MDM authorization still needs to be enforced by the underlying enterprise architecture.
An MCP Tool Should Be Narrower Than a Generic MDM Endpoint
For AI agents, a narrowly bounded tool is often safer than exposing generic write access.
Compare:
update_supplier(entity_id, arbitrary_json)
with:
propose_supplier_address_change(
supplier_id,
new_address,
evidence_reference,
expected_entity_version
)
The second tool communicates purpose, scope and preconditions much more clearly.
13. Every Agent-Facing Tool Needs an Explicit Contract
A useful Agent Tool Contract should document at least:
| Contract Element | Definition |
|---|---|
| Purpose | What business objective is this tool intended to support? |
| Input Schema | What validated inputs are required? |
| Output Schema | What deterministic response states can occur? |
| Side Effects | Does the tool modify master-data state? |
| Authority | Which identities may invoke it and under what delegation? |
| Preconditions | What entity state or approval must exist? |
| Retry Behavior | Can the operation be retried safely? |
| Escalation | When must the agent stop and transfer control? |
The Agent Tool Contract is a Digital Future & Strategy practitioner framework, not part of the MCP or OpenAPI specifications.
14. Observability Must Connect Agent Intent to Master-Data Change
Traditional API monitoring focuses heavily on technical metrics:
- latency,
- error rate,
- request volume, and
- availability.
Agentic MDM needs business observability as well.
For a material write operation, the enterprise should ideally reconstruct:
↓
Human / Application Identity
↓
Agent / Workload Identity
↓
Entity Resolution Result
↓
Tool Selected
↓
Authorization Decision
↓
Input & Entity Version
↓
MDM Change / Approval
↓
New Entity Version
↓
Downstream Event
This trace becomes critical when several agents and applications participate in one process.
15. An Enterprise MDM API Architecture
A scalable target architecture can separate the AI interface from stable MDM business services.
ERP · CRM · Data Products · Applications · AI Agents
↓
CONSUMER INTERFACES
REST · GraphQL · MCP · SDKs
↓
GOVERNED MDM CAPABILITY LAYER
Resolve · Search · Read · Validate · Propose · Approve · Publish
↓
SECURITY & POLICY
Identity · Authorization · Data Scope · Approval · Rate Limits
↓
MASTER DATA SERVICES
Match · Merge · Survivorship · Hierarchy · Workflow · Quality
↓
MDM SYSTEMS OF RECORD
Customer · Supplier · Product · Material · Location · Organization
↓
EVENT LAYER
Master Created · Changed · Merged · Deactivated
The architecture allows multiple protocols without creating multiple definitions of the same business capability.
16. Do Not Build an “AI API” Separate from Enterprise MDM Governance
One tempting approach is to create a dedicated set of simplified APIs only for AI agents.
That can create a second governance path.
The agent API may eventually implement different validation rules, different entity semantics and different permissions from the APIs used by enterprise applications.
A stronger approach is:
↓
Multiple Controlled Interfaces
↓
Human Applications · APIs · MCP · AI Agents
The interface can change without duplicating the underlying MDM policy.
17. A Production Readiness Checklist for MDM APIs
Before allowing production AI agents to use an MDM service, the architecture team should be able to answer the following questions.
1. Is the authoritative entity clearly defined?
2. Is entity resolution available as a governed capability rather than an agent guess?
3. Are read and write permissions separated?
4. Are high-impact operations such as merge, delete and critical-attribute changes separately controlled?
5. Does every write operation define concurrency behavior?
6. Can retries occur without creating duplicate business actions?
7. Are error states structured and machine-actionable?
8. Is authorization enforced at the resource, property and function levels required by the use case?
9. Can the API limit the attributes returned to the minimum necessary?
10. Are provenance and quality signals tied to specific rules and sources rather than an unexplained trust score?
11. Is there an inventory of consumers and active API versions?
12. Can deprecated versions be retired based on actual consumer usage?
13. Does the MCP layer reuse governed MDM services rather than bypass them?
14. Is every agent or application represented by an accountable identity?
15. Can the enterprise reconstruct the complete path from business request to master-data change?
The MDM API Strategy for the Agentic Enterprise
AI agents do not make REST APIs obsolete.
They make good API design more important.
An enterprise should not respond to Agentic AI by exposing more raw master-data endpoints.
It should expose fewer, clearer and better-governed business capabilities.
The strategic shift is:
“Give the Agent Access to the MDM Database”
TO
“Give the Agent the Minimum Governed
Master-Data Capability Required
to Complete the Business Task”
OpenAPI can describe stable HTTP contracts.
REST or GraphQL can support application interaction.
Events can distribute mastered state changes.
MCP can expose selected capabilities to AI clients.
None of these protocols replaces MDM governance.
The durable architecture is the layer beneath them:
× Explicit Business Semantics
× Bounded Capabilities
× Granular Authorization
× Safe Change Semantics
× Version & Retry Control
× End-to-End Observability
=
Agent-Ready MDM
The future of MDM APIs is not about making every master-data operation available to AI. It is about making the right business capabilities discoverable, deterministic and safe enough for AI to use.
Sources & Further Reading
- OpenAPI Initiative — OpenAPI Specification
- Model Context Protocol — Specification
- Model Context Protocol — Authorization Specification
- OWASP — API Security Top 10
- NIST — SP 800-207A: Zero Trust Access Control for Cloud-Native Applications
- IETF — RFC 9110: HTTP Semantics
- Reltio — Entity Management APIs
- Reltio — Potential Matches API
- Reltio — Merge and Unmerge Entity APIs
This article presents a vendor-neutral architecture for MDM APIs used by enterprise applications and AI agents. OpenAPI, MCP, OWASP, NIST and HTTP specifications provide external standards and security references. Reltio documentation is included only as a concrete example demonstrating the richer semantics of real MDM operations such as potential matching, merge and unmerge; it should not be interpreted as the only valid MDM implementation model. The MDM capability layer, Agent Tool Contract, error taxonomy, retry model, production-readiness checklist and agent-ready architecture are Digital Future & Strategy practitioner frameworks. MCP standardizes AI client-server interaction but does not automatically provide master-data quality, entity resolution, business authorization or regulatory compliance. Implementation patterns should be adapted to each organization's MDM platform, security architecture and business-risk model.
Reviewed: September 2026
MDM Strategy Series
Part 4 — Architecture & Integration
MDM #14. Master Data as a Data Product
MDM #15. Hybrid Federated MDM
MDM #16. Real-Time Data Fabric for Master Data
MDM #17. Designing MDM APIs for AI Agents: Contracts, Context, Security and MCP
Part 5 — Governance & Future
MDM #18. Regulatory-Ready Master Data: Privacy, Sustainability and AI Governance
MDM #19. Zero Trust for Master Data: Security and Governance in the Agentic AI Era
Comments
Post a Comment