AI-Ready #11. Connecting MDM to AI Agents: APIs, Permissions and Human-in-the-Loop Controls
Connecting an AI agent to Master Data Management is not mainly an API problem.
The difficult question is what the agent should be allowed to read, interpret, recommend and change.
An MDM platform may contain trusted customer, supplier, product, material, location or employee records. Once an AI agent can access that environment, the architecture connects probabilistic AI behavior to systems that may directly affect business operations.
That changes the design problem.
The key design question is not “Can the agent call the MDM API?” It is “Which business capabilities should be exposed, under what identity, authority, evidence and approval conditions?”
This article presents a practical architecture for connecting MDM to AI agents while keeping access, actions and accountability controlled.
The framework is vendor-neutral. Specific OpenAI, Anthropic, SAP and OWASP references are used only where their public documentation supports the underlying pattern.
Tool Calling Is an Integration Pattern, Not a Security Model
Modern AI platforms commonly support tool or function calling.
OpenAI describes function calling as a way for models to interface with external systems and data through functions defined by an application.
Anthropic similarly describes tool use as a mechanism through which Claude can invoke user-defined or platform-provided tools.
This makes tool calling a useful integration pattern for enterprise systems.
But it does not automatically provide:
- business authorization,
- least-privilege access,
- data classification,
- approval policy,
- transaction controls,
- rollback,
- audit evidence, or
- accountability.
Those controls must be designed outside the model.
Never treat the model's decision to call a tool as proof that the action is authorized.
A Reference Architecture for MDM–Agent Integration
A practical design separates reasoning from system authority.
↓
AI Agent
↓
Tool Contract / Orchestration Layer
↓
Policy & Authorization Layer
↓
MDM API / Workflow / Search Service
↓
MDM System of Record
↓
Audit, Monitoring & Evaluation
Each layer has a distinct responsibility.
| Layer | Responsibility | Control Question |
|---|---|---|
| AI Agent | Interpret the task, reason over context and request an appropriate tool. | What does the agent want to do? |
| Tool Contract | Expose clearly defined business capabilities using structured inputs and outputs. | Is the requested action structurally valid? |
| Policy / Authorization | Evaluate identity, scope, data sensitivity, action type and approval requirements. | Is the agent allowed to perform this action now? |
| MDM Service | Perform governed query, workflow or transaction operations. | What actually changes in the source system? |
| Audit / Evaluation | Capture evidence, exceptions, outcomes and control failures. | Can we reconstruct and evaluate what happened? |
Do Not Expose the MDM Database as an AI Tool
One of the most important design decisions is the level of abstraction exposed to the agent.
A weak pattern is:
This gives the AI too much responsibility for understanding schema, business rules and transaction semantics.
A stronger pattern exposes bounded business capabilities.
For example:
| Avoid | Prefer |
|---|---|
| query_mdm_database() | get_supplier_profile() |
| update_master_record() | submit_supplier_address_change() |
| execute_sql() | find_material_by_specification() |
| delete_record() | request_master_record_deactivation() |
The second design exposes business intent rather than technical power.
Design Tool Contracts Like Enterprise APIs
A tool contract should contain more than a function name.
I would define at least:
- clear business purpose,
- required and optional parameters,
- canonical entity identifiers,
- allowed values,
- data classification,
- permission scope,
- approval requirement,
- expected errors,
- idempotency behavior for writes,
- source and freshness metadata, and
- version information.
An illustrative contract could look conceptually like this:
This design keeps the AI within a bounded role.
Separate Read, Recommend, Submit and Execute
It is tempting to divide MDM permissions into only two categories:
read and write.
For AI agents, that is often too coarse.
A more useful authority ladder is:
| Authority | Example | Typical Control |
|---|---|---|
| Read | Retrieve an approved material or supplier profile. | Identity, purpose, scope and data-access policy |
| Recommend | Recommend possible duplicate records or a classification. | Evidence and confidence presented to reviewer |
| Submit | Create a change request in the existing MDM workflow. | Workflow validation and approval policy |
| Execute Bounded Change | Perform a predefined, reversible low-risk correction. | Policy gate, audit, rollback and monitoring |
| High-Impact Change | Merge, deactivate or materially change a business-critical entity. | Strong approval or human decision unless separately justified |
Authority should be assigned by action consequence, not simply by whether the API method uses GET or POST.
Human-in-the-Loop Should Be Risk-Based
A blanket rule that every MDM write requires manual approval may be unnecessarily restrictive.
The opposite rule — allowing the agent to write freely — is also difficult to justify.
The approval model should reflect several factors.
| Factor | Lower-Risk Condition | Higher-Risk Condition |
|---|---|---|
| Business Impact | Cosmetic or informational correction | Financial, legal, supply or customer impact |
| Reversibility | Easy rollback | Difficult or irreversible |
| Evidence | Deterministic authoritative source | Conflicting or inferred evidence |
| Policy Ambiguity | Clear rule | Requires judgment |
| Entity Sensitivity | Low-risk reference data | Customer, employee, vendor-payment or regulated data |
A reasonable operating pattern is therefore:
→ More Automation
High Consequence + Ambiguity + Difficult Recovery
→ Stronger Human Oversight
Approval Should Be a Workflow Decision, Not a Prompt Instruction
An instruction such as:
is not a sufficient enterprise control.
The agent is being asked to determine whether its own action is important.
A stronger implementation applies policy outside the model.
↓
Policy Engine Evaluates Action
↓
Approval Required?
↙ ↘
Human Workflow Controlled Execution
The approval rule can consider:
- entity type,
- attribute being changed,
- business value or exposure,
- source of evidence,
- agent identity,
- requesting user's authority,
- confidence or ambiguity indicators,
- regulatory classification, and
- previous exceptions.
Design Identity at Three Levels
An enterprise agent transaction may involve three different identities:
- Human identity — who initiated or owns the business request.
- Agent identity — which agent or service is acting.
- Execution identity — which credential actually calls the backend system.
Collapsing all three into one technical service account weakens accountability.
A well-designed audit trail should be able to answer:
- Which user or event initiated the request?
- Which agent interpreted it?
- Which tool was selected?
- Which policy permitted or denied execution?
- Which human approved the action, if required?
- Which backend identity executed it?
Minimize the Data Returned to the Agent
An MDM record may contain far more information than the AI needs.
For example, a supplier-risk assistant may need:
- supplier ID,
- status,
- country,
- approved categories,
- risk classification, and
- selected performance indicators.
It may not need bank-account information, tax identifiers or personal contact details.
The tool should therefore return a use-case-specific response rather than the entire master record.
Expose the minimum attributes required for the agent to perform the approved business task.
This reduces unnecessary information exposure and makes tool outputs easier to evaluate.
Structured MDM Data and RAG Solve Different Problems
Not every MDM interaction should be converted into embeddings and stored in a vector database.
Structured master data and semantic retrieval serve different purposes.
| Need | Preferred Pattern | Example |
|---|---|---|
| Exact Identity | MDM API / governed lookup | Retrieve supplier 100238. |
| Current Status | API or transactional query | Is the supplier active and approved? |
| Semantic Discovery | Search / vector or hybrid retrieval | Find materials with similar technical descriptions. |
| Policy Knowledge | Governed RAG | Retrieve supplier onboarding policy. |
| Master Change | MDM workflow / transaction API | Submit an approved address change. |
An AI agent may use several of these patterns within one workflow.
The important point is not to replace authoritative structured lookup with approximate semantic retrieval when exact identity matters.
Security: Assume the Agent Can Receive Hostile Instructions
Enterprise agents may process content from emails, documents, web pages, tickets and users.
That creates a security boundary between untrusted content and privileged tools.
OWASP's 2025 Top 10 for LLM and generative-AI applications includes risks such as Prompt Injection, Sensitive Information Disclosure and Excessive Agency.
OWASP GenAI Security Project — Top 10 Risks for LLM and GenAI Applications
For MDM-integrated agents, several controls become especially important.
| Risk | Example | Control Direction |
|---|---|---|
| Prompt Injection | External content attempts to persuade an agent to retrieve unrelated master data. | Treat content as untrusted; enforce permissions outside the prompt. |
| Excessive Agency | A general-purpose tool allows broad master-data changes. | Use narrow tools, least privilege and approval gates. |
| Sensitive Data Exposure | Agent returns unnecessary sensitive attributes. | Field-level minimization, classification and output controls. |
| Abnormal Consumption | Agent repeatedly queries large portions of the MDM estate. | Rate limits, quotas, anomaly detection and request boundaries. |
| Tool-Chain Failure | One incorrect tool result triggers further automated actions. | Validation, bounded call depth, checkpoints and escalation. |
Do Not Rely on Prompt Instructions for Least Privilege
A system prompt can tell an agent:
But the infrastructure should still prevent the agent's credential from calling an unauthorized write endpoint.
The stronger principle is:
+
Tool-Level Permission
+
API Authorization
+
Backend Business Rule
Each layer should constrain the next.
Design for MDM Failure and Partial Data
The agent should not assume the MDM system is always available or complete.
At minimum, define behavior for four conditions.
| Condition | Expected Agent Behavior | Do Not |
|---|---|---|
| API Unavailable | Stop the dependent action or use an explicitly approved fallback. | Invent missing master data. |
| Record Not Found | Return an unresolved identity state or escalate. | Assume the closest search result is the same entity. |
| Conflicting Records | Preserve ambiguity and invoke governed resolution. | Silently choose one value. |
| Partial Attributes | Limit the decision to what the available evidence supports. | Present a partial result as complete. |
Audit the Decision Chain, Not Just the Final API Call
A traditional API log may record that an endpoint was called.
For an AI-agent workflow, that may not be enough.
A useful audit record can include:
- requesting human or initiating event,
- agent and agent version,
- tool selected,
- tool parameters,
- relevant source references,
- policy decision,
- approval request and approver where applicable,
- backend result,
- before-and-after values for material changes,
- timestamps,
- exception or rollback status, and
- correlation ID across systems.
This allows investigators and operators to reconstruct the business action rather than seeing only a technical transaction.
Use Idempotency and Concurrency Controls for Writes
AI agents may retry failed requests.
Networks may time out after the backend has already completed the transaction.
Two users or agents may attempt to update the same entity at the same time.
For write operations, enterprise integration therefore needs ordinary distributed-system controls as well as AI controls.
Examples include:
- idempotency keys,
- version checks,
- optimistic locking,
- duplicate-request detection,
- transaction boundaries, and
- safe retry rules.
Agentic architecture does not replace conventional API engineering. It increases the importance of getting it right.
A SAP-Oriented Enterprise Pattern
Organizations using SAP do not need to expose backend services directly to an AI agent.
SAP Integration Suite API Management is designed to publish and govern APIs with security, traffic management, lifecycle controls and monitoring.
SAP's current Integration Suite documentation also describes support for API and MCP Server artifacts for exposing enterprise capabilities to AI-powered applications and agents.
SAP Help Portal — API Management
SAP Help Portal — Design APIs and MCP Servers
A possible pattern is:
↓
Approved Tool / MCP Interface
↓
API Management & Policy
↓
Integration / MDM Service
↓
SAP MDG / S/4HANA or Other Authoritative System
This should be treated as an architectural pattern rather than a mandatory SAP implementation.
The exact service and workflow design depends on the company's SAP landscape, MDG deployment, integration architecture and security model.
Multi-Agent Does Not Remove the Need for One Control Plane
As organizations introduce specialized agents, a workflow may involve several roles.
For example:
Each agent should not independently define its own MDM access policy.
A stronger design centralizes important controls such as:
- agent identity,
- tool registration,
- domain authorization,
- maximum action scope,
- approval rules,
- call-depth limits,
- rate limits,
- shared audit correlation, and
- emergency disablement.
The agents may be distributed.
Policy should remain governable.
An Illustrative Supplier-Change Workflow
Consider a supplier address change submitted through an AI-enabled procurement assistant.
1. User Request
“Supplier A has moved. Update its registered address using this official document.”
2. Identity Resolution
Agent resolves the supplier to the canonical MDM ID.
3. Evidence Retrieval
Agent extracts the proposed address and links the submitted evidence.
4. Tool Request
Agent invokes request_supplier_address_change().
5. Policy Check
System checks supplier status, user authority, change type and approval policy.
6. MDM Validation
Address format, duplicates and required attributes are validated.
7. Human Approval
Required reviewer receives old value, proposed value, evidence and agent rationale.
8. Governed Execution
Approved workflow updates the master record.
9. Audit
The complete chain is recorded with one correlation identifier.
The AI assists with interpretation and orchestration.
The enterprise system remains responsible for authorization and controlled state change.
What to Measure in Production
Model accuracy alone does not tell you whether MDM–agent integration is working.
I would monitor several layers.
| Layer | Examples | Question |
|---|---|---|
| Entity Resolution | Wrong entity, unresolved entity, duplicate candidates | Did the agent act on the right master entity? |
| Tool Selection | Wrong tool, invalid parameters, rejected tool call | Did the agent select an appropriate capability? |
| Authorization | Denied requests, privilege violations, unusual volume | Are boundaries working? |
| Human Review | Approval, rejection, override and escalation reasons | Where is judgment still needed? |
| Execution | Failed transactions, duplicate writes, rollback | Did the action complete safely? |
| Business Outcome | Cycle time, rework, backlog and exception volume | Did the workflow improve? |
A Practical Rollout Sequence
I would avoid converting this into a universal maturity model.
For one use case, however, the following sequence can reduce unnecessary exposure.
| Phase | Capability | Evidence Before Expanding |
|---|---|---|
| 1. Read | Agent retrieves governed master context. | Identity, access, freshness and field exposure work correctly. |
| 2. Recommend | Agent proposes classifications, duplicate candidates or changes. | Evaluation and human-review evidence are acceptable. |
| 3. Submit | Agent creates governed change requests. | Workflow, audit and authorization remain reliable. |
| 4. Bounded Execute | Selected low-risk actions can execute automatically. | Production error, rollback and exception evidence support automation. |
The progression should stop wherever the business risk no longer justifies additional autonomy.
Implementation Checklist
☐ Define the business action before exposing the API.
☐ Use canonical MDM identifiers where exact identity matters.
☐ Separate Read, Recommend, Submit and Execute authority.
☐ Give every agent an identifiable service identity.
☐ Apply least privilege outside the model prompt.
☐ Minimize the attributes returned by each tool.
☐ Use governed workflows for material master-data changes.
☐ Define when HITL is mandatory and when automation is acceptable.
☐ Implement audit correlation across agent, gateway and MDM systems.
☐ Add idempotency and concurrency controls for write operations.
☐ Define behavior for unavailable, conflicting and incomplete MDM data.
☐ Test prompt injection and excessive-agency scenarios.
☐ Monitor human overrides, policy denials and wrong-entity actions.
☐ Expand agent authority only when operating evidence supports it.
My Practical Takeaway
The most important boundary in MDM–AI integration is not between the AI model and the API.
It is between reasoning and authority.
The agent can help interpret business intent, identify relevant entities, assemble evidence and recommend actions.
But the enterprise should retain control of:
- identity,
- authorization,
- business policy,
- high-impact approvals,
- transaction integrity,
- auditability, and
- risk acceptance.
Connect AI agents to business capabilities, not unrestricted backend power. Let the model request an action; let enterprise policy decide whether that action is allowed.
That architecture allows organizations to increase automation progressively without making MDM governance dependent on the model behaving perfectly.
Sources & Further Reading
- OpenAI — Function Calling
- Anthropic — Tool Use
- OWASP GenAI Security Project — Top 10 Risks for LLM and GenAI Applications
- SAP Help Portal — API Management
- SAP Help Portal — Design APIs and MCP Servers
The reference architecture, authority ladder, risk-based HITL model, supplier-change workflow, production KPI structure and rollout sequence in this article are Digital Future & Strategy practitioner frameworks. They are not official OpenAI, Anthropic, SAP, OWASP or regulatory standards. Organizations should adapt controls to their own MDM platform, business processes, data sensitivity, regulatory obligations and risk appetite.
Reviewed: September 2026
AI-Ready Strategy Series
Part 3 — Master Data & Agent Integration
AI-Ready #10. Prioritizing AI-Ready Master Data by Domain: Customer, Material, Supplier, Product and Employee
AI-Ready #11. Connecting MDM to AI Agents: APIs, Permissions and Human-in-the-Loop Controls
AI-Ready #12. From Assessment to Operations: A Four-Stage Roadmap for Enterprise AI Readiness
Previous: Prioritizing AI-Ready Master Data by Domain: Customer, Material, Supplier, Product and Employee
Next: From Assessment to Operations: A Four-Stage Roadmap for Enterprise AI Readiness
Comments
Post a Comment