Model Context Protocol (MCP): Secure Access to Business Systems

An AI assistant checking an order’s status carries different responsibilities from one that can cancel it. Both actions may look similar in a chat window, but their consequences differ for business records, customers, and access policies. The first decision when setting up an MCP connection is which work to delegate.

MCP lets AI applications use external data and tools through a shared protocol. The official specification dated July 28, 2026 defines that communication. Your application must still enforce decisions such as who may change a particular customer’s records. The following is our proposed starting approach for a business connecting order management and customer support.

Two software specialists reviewing tool connections and access permissions on a laptop

Two different risks in one connection

Imagine a support assistant reading a customer’s message and checking their order in an ERP. The message contains an instruction asking the assistant to send the entire customer list elsewhere. This hypothetical example illustrates prompt injection: text inside a record attempts to redirect the assistant’s task.

A trusted support system might deliver that message; its contents are not necessarily trustworthy. In its engineering article on containing agents, Anthropic explains that trusted connectors can return data containing malicious instructions, and model defenses alone are insufficient.

The second question is whether the assistant could read and send the customer list even if it followed the instruction. Access limited to the relevant order’s status, without an external sending tool, reduces this attack path’s impact. Filtering text and enforcing tool permissions are separate controls. A successful sign-in does not establish permission to read every record or perform every action.

Bind permissions to the actual operation

Instead of exposing every API endpoint immediately, start with three narrow tools: look up order status, prepare a reply draft, and send an approved reply. The server should check lookup access against the user’s organization and permitted orders. It must not simply trust an organization identifier supplied in the request.

Names such as orders:read and orders:write are example scopes your application might define, not business permissions prescribed by MCP. An account with read access should also be blocked when it calls a write tool directly. Hiding the tool from the interface or describing it as “read-only” does not enforce that restriction.

For protected HTTP connections, the MCP authorization specification describes an OAuth 2.1 flow and validation that an access token belongs to the intended server. Our OAuth 2.0 glossary entry explains the foundation. Local stdio connections do not use the same HTTP flow; the process environment and accessible resources require separate controls.

When an MCP server connects to another service, it must not forward arbitrary tokens received from its client. The official MCP security guide prohibits this “token passthrough.” Handle authorization for the two connections separately, and restrict the upstream account to permissions required for the job.

Approval should show the actual change

In our proposed order workflow, the assistant first produces a draft change. The user sees the order number, affected field, old and new values, and customer impact. At execution, the server checks that approval applies to that same operation. If the amount or target record changes afterward, the draft requires another review.

A system message saying “ask permission first” cannot provide this control. The application should bind the approval record, operation identifier, and execution conditions together. Approval for one support reply must not become permission to send every subsequent message. Alongside the technical tool name, explain the business consequence in language the reviewer understands.

The MCP tools specification recommends that people can reject calls and see clear activity indicators; it does not mandate a particular interface. The draft and change comparison described here are our design proposal for order management. Authorization checks should remain effective even when a user approves by mistake.

Read access also needs boundaries

A read-only pilot still needs privacy controls. Checking whether an order shipped does not require the entire customer profile. Limit tool responses to necessary fields; keep addresses, phone numbers, and payment details out of model context unless the task requires them. Record which data reaches which server and model provider in your connection inventory.

Keep credentials out of chat text and tool outputs. Where supported, use short-lived, narrowly scoped tokens and test revocation. Rate limiting caps request volume; it does not prevent reading another organization’s record. Mask secrets and unnecessary personal data when logging operation results.

Acceptance checks for a small pilot

Measure more than whether the assistant produces a correct answer. We recommend this sequence:

Choose one task. For example, draft support replies using one store’s order status. Explicitly exclude cancellation, refunds, and bulk external data transfers.
Test boundaries with synthetic data. Try another organization’s order identifier, missing permissions, and customer messages containing instructions. Confirm that denied requests return no protected data.
Enable limited production reads. Start with a few users and necessary fields. Inspect incorrect matches, denied access, and excessive data returned.
Evaluate one write operation separately. Complete previews, specific approval, duplicate prevention on retries, and verification after execution. If the response disappears, check whether the operation happened before resending it.
Verify the stop procedure. Assign responsibility for disabling the connection and revoking access. Repeat pilot checks when tool permissions or provider behavior changes.

These boundaries make the human oversight discussed in our AI-assisted software development article concrete for business systems. To define this scope for your ERP or support platform, explore our API development and integration and security audit services, or contact us.

Official sources

Sources checked: September 5, 2026. Compare the cited protocol version with the versions supported by your chosen client and server.