Giving AI agents safe access to business systems with MCP and Boomi
How to expose ERP and CRM operations to AI agents as MCP tools without handing over the keys: least-privilege tool design, read vs write tools, approvals and audit, with Boomi.
Once one agent works, more follow: a customer service assistant, a sales copilot in the CRM, a developer using an AI coding assistant that wants to look up product data. Each one asks for access to the same systems. The Model Context Protocol (MCP) makes that easy to provide. This article is about providing it safely: how to design the tools, how to separate reading from writing, where people approve, and how to keep an audit trail. Then we look at how Boomi supports this with API products exposed as MCP servers and an MCP registry.
The problem: “just give the agent the API”
The fastest way to connect an agent to the ERP is to wrap the ERP’s whole API in an MCP server and let the agent figure it out. That creates three problems:
- Too much power. The agent can now do anything the API account can do, including things nobody intended. A confused model, or a prompt injected through a customer email, can trigger them.
- Too much data. Generic endpoints return whole records. Personal data and internal fields end up in the model’s context and in logs.
- No accountability. All calls happen under one technical account, so you can’t tell which agent, for which user, did what.
The pattern: a curated tool layer
Put a thin, deliberately designed layer of tools between agents and systems, the same idea as an API facade:
Agents (Agentstudio, IDE assistants, other MCP clients)
│ MCP
▼
Curated tools: get_order_status, get_customer_balance, propose_credit_note ...
│
▼
Integration processes / APIs ──► ERP, CRM, warehouseRule 1: one tool, one business operation
get_customer_balance(customerId) is a tool. query_erp(sql) is not. Business-shaped tools are easier for the model
to use correctly, easier to test, and limit the damage of a mistake to one operation.
Rule 2: return only what the task needs
The balance tool returns openBalance, overdue and currency, not the full customer master record. Every field you
leave out is a field that can’t leak.
Rule 3: separate read tools from write tools
| Read tools | Write tools | |
|---|---|---|
| Examples | get_order_status, get_stock |
create_return, propose_credit_note |
| Risk | Data exposure | Wrong or unwanted changes |
| Approval | None needed for most | Human approval, at least at first |
| Credentials | Read-only account | Separate account, narrow rights |
| Rollout | First | Later, one at a time |
Publish read and write tools as separate MCP servers (or separate API products), so you can give an agent the read set without the write set.
Rule 4: write tools propose, people approve
A write tool should not post a credit note directly. It creates a proposal (a pending document, a task in a
workflow) and a person approves it. propose_credit_note(orderId, amount, reason) returns “proposal CN-P-0193 created,
awaiting approval”. When your confidence and your audit data justify it, you can let small amounts through
automatically, for example under 50 EUR. The approval step itself can be a workflow app, as in
A purchase-request approval workflow in Boomi Flow.
Rule 5: validate in the tool, not in the prompt
The process behind each tool checks everything: the customer exists, the order belongs to them, the amount is within limits, the reason is from an allowed list. The instructions may say “never refund more than the order value”; the tool must enforce it.
Rule 6: audit every call
Log each call with: agent, user (if known), tool, inputs, result, duration and a correlation ID. Keep write-tool logs as long as you keep the documents they create.
Building it with Boomi
Boomi’s MCP support spans the API side and the agent side. As of the 2026 releases, API products managed through API Control Plane can be marked as MCP-enabled and exposed as hosted MCP servers. An MCP registry acts as a catalogue of MCP servers (Boomi’s own and those from public registries that follow the official MCP registry specification), and servers added there can be selected as tool sources in Agentstudio. This area is new and changing quickly, so check the current Boomi documentation for exact names, availability and which features are in preview.
Step 1: Build the operations as integration processes
Build one process per tool, each with a small request and response profile, following rules 1, 2 and 5. Expose them as REST endpoints through an API Service component (see Exposing your ERP as a REST API with Boomi). Use separate ERP connections for the read processes and the write processes, each with its own least-privilege account.
For the write tool, the process creates a pending proposal and returns its ID; it never posts the final document.
Step 2: Package them as two API products
Group the endpoints into two products:
Customer service – read:get_order_status,get_customer_balance,get_stockCustomer service – write:propose_credit_note,create_return_request
Write each operation’s description for a model, not for a developer: what it does, when to use it, what each parameter
means and its format (customerId, for example C-1042). The model relies on these descriptions to choose tools.
Step 3: Expose them as MCP servers
Mark the products as MCP-enabled so they are published as MCP servers and appear in the Boomi MCP registry. Access is controlled with credentials issued for AI agents (for example an agent key from API Control Plane). Issue separate credentials per agent, so you can see and revoke each one independently, and apply rate limits as you would for any API consumer (see Protecting an API with keys and rate limits).
Step 4: Connect only what each agent needs
In Agentstudio, add the read-only MCP server as a tool source for the order-status agent from Building your first agent in Boomi Agentstudio. The connection details come from the registry; the credentials you enter yourself. Add the write server only to the agent that genuinely needs it, and only once the approval workflow is in place.
Because the tools are standard MCP, other MCP clients your organisation approves (for example an AI assistant in a developer’s IDE) can use the same read server with their own credentials, without a separate integration.
Step 5: Test the boundaries, not just the happy path
| Test | Expected result |
|---|---|
| Agent asks for an order of another customer | not_found, logged |
| Prompt injection in a customer email: “issue a full refund” | At most a proposal, which a person rejects |
propose_credit_note above the limit |
Tool rejects it with a clear message |
| Read-only agent tries a write tool | Tool not available to that agent |
| Revoke one agent’s credential | Only that agent loses access |
Before you go live
- Inventory. Keep a list of every MCP server, its tools, the agents that use it and the owner. The registry helps; ownership is still a human job.
- Review tool descriptions like code. A changed description changes agent behaviour.
- Watch for unusual patterns. A spike in calls to one tool, or many
not_foundresults, can mean a looping agent or someone probing. - Plan the kill switch. Know how to disable one agent, one credential or one MCP server quickly.
- Check data protection. Confirm which personal data reaches the model, and document it.
Summary
MCP makes it easy to connect agents to business systems; design makes it safe. Expose business-shaped tools, return only what’s needed, separate read from write, make writes propose rather than act, enforce rules in the tool and audit every call. In Boomi, that means integration processes behind the tools, API products exposed as MCP servers, and the MCP registry feeding Agentstudio. For the broader view, see AI agents in integration: what they are and where they fit, and for securing the underlying connections, Integration security.