The short answer: do not make AI a door into every system

A secure AI integration gives the model access to specific business capabilities through a controlled integration layer. The ERP, CRM, document store, or business API must remain responsible for authorization and business rules.

A basic request path should work like this:

  1. The user authenticates with an organizational account.
  2. The AI requests only an approved capability, such as checking inventory or reading a customer record.
  3. The source system or business API checks that user’s permissions again.
  4. The system returns only the data required for that request.
  5. Any data change or transaction is reviewed and confirmed before execution.

The goal is not to promise that leakage can never happen. It is to reduce likelihood, limit impact, and make the integration observable, revocable, and stoppable when something goes wrong.

Expose business capabilities, not an entire database

The model should not receive database credentials, administrator privileges, or an open-ended command interface. If the task is to check stock, expose a narrow checkInventory capability that accepts an authorized warehouse and product identifier instead of allowing the model to write arbitrary SQL.

Well-bounded capabilities might include:

  • summarizing customer information the current employee may view;
  • checking quantities in an authorized warehouse;
  • finding terms in documents the user may access; and
  • creating a draft quotation for review.

The ERP and CRM should remain the systems of record and keep enforcing rules such as who may view a customer, who may change a price, and which amount requires approval. Those rules should not be hidden in a prompt. Instructions to a model are not a dependable security boundary.

The trust boundary when AI reaches internal systemsA request travels top to bottom, but every "is this allowed?" decision happens below the boundary line.
  1. PersonSends a request under their own company account
    Can
    State what they need, and confirm before anything is committed
    Cannot
    Widen their own permissions by phrasing a request differently
  2. AI assistantInterprets the request and calls the tools it has been given
    Can
    Ask for a capability and shape results into a summary or a draft
    Cannot
    Hold database credentials, write its own SQL, or vouch for itself

  3. Trust boundary — anything above this line can be talked into something

    Integration layerAuthenticates, checks scope, rate-limits, and writes the audit log
    Can
    Refuse an out-of-scope call and strip data the task does not need
    Cannot
    Assume a call is legitimate because an AI is the one making it
  4. ERP · CRM · internal documentsHold the real records and enforce business rules as the last gate
    Can
    Re-check that this specific person may see this specific record
    Cannot
    Be bypassed by wording inside a prompt

MCP standardizes connections, but it does not secure them automatically

The Model Context Protocol (MCP) is an open protocol for connecting language-model applications to external data and tools. It standardizes how clients discover and use resources, prompts, and tools.

MCP can be useful when multiple AI clients need the same capabilities or when the integration layer should remain separate from one AI platform. It is not mandatory and does not replace every API.

Situation A possible approach
One AI system already has a controllable connector Use the platform connector
The workflow uses a small number of well-defined APIs Use REST or OpenAPI directly
Several AI clients need the same tool set Consider MCP
The legacy system has no API that enforces permissions and business rules Build the business API first, then choose the connection method

MCP defines communication patterns, but it cannot enforce every security principle at the protocol layer. Implementers still need consent flows, authorization, access controls, and data protection appropriate to their own systems.

Separate identity, application access, and record-level authorization

Saying “we use OAuth” does not answer which customers or documents a user may see. A complete design separates at least three questions:

Question Related mechanism Example
Who is this user? Authentication such as OpenID Connect Confirm that the user is a sales employee
Which operations may the AI application call? OAuth 2.0 scopes Read customer data or check inventory
Which records may this user actually access? ERP, CRM, or business-API authorization Return only assigned customers

OAuth 2.0 gives an application limited access without handing it the user’s password, while OpenID Connect adds an identity layer on top of OAuth 2.0. The source system must still enforce record-level access by customer, branch, department, warehouse, or document type on every request.

If an MCP server sits between the client and downstream systems, do not forward an access token without validating its audience or separating credentials by resource server. MCP Security Best Practices describes token passthrough as an anti-pattern because it breaks trust boundaries and weakens auditability.

Controls that should cover the whole data path

There is no universal number of layers. Select controls according to the sensitivity of the data, the impact of an operation, and what the existing systems can enforce.

1. Minimize the data sent to the model

A customer-status summary may not require a national identification number, bank account, internal cost, or complete history. The integration layer should select only necessary fields, mask sensitive values, limit result counts, and set appropriate expiry for cached results.

Minimizing data before it leaves the source is more dependable than sending everything to the model and asking a prompt not to disclose it.

2. Operate in the real user’s context

Avoid one shared account that can see the whole organization. AI actions should use an identity or authorization context that can be traced to the initiating user, allowing the source system to make the correct access decision and produce an accurate audit trail.

If a service account is necessary, restrict its privileges, add user-level policy in the business API, and record who initiated each request. Merely writing a username to a log does not replace authorization before the operation.

3. Preserve document permissions in RAG

Retrieval-augmented generation (RAG) retrieves content from documents or a knowledge base before sending context to a model. Creating a new search index means the organization must deliberately preserve the access rules of the source documents.

Store permission or group metadata with indexed content and filter search results before any content reaches the model. Do not retrieve everything and ask a prompt to decide. Retrieved documents should also be treated as untrusted input because their text may attempt to make the AI disclose data or call another tool.

For an overview of RAG, fine-tuning, and index design, see Microsoft Foundry: RAG and indexes.

4. Separate read, draft, and execute permissions

Reading data and changing it have very different risk. They should not share one broad permission.

Operation level Example Control
Read Check inventory or summarize customer history Filter by user permissions and log access
Draft Draft a quotation, email, or purchase request Require review before saving or sending
Execute Send a quotation, change a price, or create a purchase order Recheck authorization, show details, and ask for confirmation
High impact Approve credit, pay money, or change bank details Require an authorized approver and additional controls

OWASP LLM06: Excessive Agency recommends minimizing extension functionality and permissions, enforcing policy in downstream systems, and requiring human approval for high-impact actions.

5. Review the data policy of every service in the path

“Enterprise AI” does not imply one universal set of terms. Before using production data, verify whether prompts, responses, and attachments train models; how long they are stored; where they are processed; who can inspect the history; and which terms apply to every extension.

For example, Microsoft’s data, privacy, and security documentation for Microsoft Copilot states that prompts, responses, and data accessed through Microsoft Graph are not used to train foundation LLMs, and that Copilot surfaces organizational data according to user permissions. Interaction history is still stored under Microsoft 365 commitments and can be governed by administrators through Microsoft Purview.

Overly broad existing permissions remain a problem because AI can make already-accessible information easier to discover. Microsoft therefore provides guidance to review permissions and create a governed data foundation before expanding Copilot. Agents, MCP servers, and third-party services also require their own review of permissions, privacy statements, and terms.

6. Make operations auditable and stoppable

The organization should be able to determine who initiated an AI request, which capability ran, which system it contacted, what category of data it used, who approved it, and whether it succeeded. Logs are sensitive too, so do not automatically record access tokens, secrets, or complete personal data.

Define redaction, retention, and log-access policies. Provide ways to revoke access, disable a tool, rate-limit operations, and alert on unusual behavior such as large exports or repeated attempts to cross departmental boundaries.

Example: a sales assistant connected to CRM and ERP

Suppose a salesperson asks AI to summarize a customer’s history, outstanding balance, frequent purchases, and current stock, then prepare a draft quotation. A controlled path could be:

  1. The employee signs in with an organizational account.
  2. The AI requests tools for reading the customer record and checking stock.
  3. The integration layer verifies that those tools and scopes are permitted.
  4. The CRM and ERP verify which customer, warehouse, and data categories the user may access.
  5. The systems return only necessary data, and the AI creates a summary and draft quotation.
  6. The employee reviews pricing, terms, and line items before submitting the draft to the company’s existing approval process.
Who enforces each step, and when a real record is writtenThe first five steps touch no live data. The write happens only after a person confirms.
  1. Employee signs in with their company accountEnforced by: Identity providerLive record: Untouched
  2. AI asks for the customer-read and stock-check toolsEnforced by: AI assistantLive record: Untouched
  3. Check that this tool and scope are permittedEnforced by: Integration layerLive record: Untouched
  4. Re-check that this user may see this customer and warehouseEnforced by: ERP · CRMLive record: Untouched
  5. AI summarizes and prepares the quotation as a draftEnforced by: AI assistantLive record: Draft

  6. Confirmation point — everything above here can be discarded with no effect on live data

    Employee checks pricing and terms, then sends it for approvalEnforced by: Employee + existing approval workflowLive record: Written

The model does not need a password or administrator privileges, cannot read the whole database, and cannot bypass an approval rule merely because an instruction tells it to do so.

Start with a small, testable use case

An organization does not need to connect every system at once. A more controllable starting point is one use case, one user group, and the minimum required data—for example, allowing sales staff to read their assigned customer records and check inventory in read-only mode.

A practical sequence is:

  1. Choose a valuable workflow with limited downside.
  2. Identify required data, data owners, and user permissions.
  3. Select a connector, API, or MCP based on the workflow and existing systems.
  4. Test wrong answers, over-privileged requests, prompt injection, and attempts to bypass policy.
  5. Validate answer quality, authorization, and audit trails before enabling draft creation.
  6. Enable real transactions only with confirmation and an incident-response path.

The NIST AI Risk Management Framework can help organizations govern, understand, measure, and manage AI risk throughout the lifecycle. It does not prescribe MCP or any single architecture.

Checklist before connecting AI to production data

  • Is there a clear use case, process owner, and desired outcome?
  • Have you identified which data AI needs and which data must not be exposed?
  • Are user permissions in ERP, CRM, and document systems accurate?
  • Did you choose a connector, API, or MCP based on the job rather than the trend?
  • Does each tool have a narrow scope and recheck authorization at the source?
  • If you use RAG, are document permissions preserved and filtered before retrieval reaches the model?
  • Are read, draft, and execute permissions separate?
  • Does an authorized person approve high-impact actions?
  • Have you reviewed model-training, retention, processing-location, and third-party terms?
  • Can you audit activity, alert on anomalies, revoke access, and stop the integration?

Frequently asked questions

Is MCP required to connect AI with ERP and CRM?

No. An existing connector or a well-designed API may be simpler. MCP is useful when several AI clients need a shared, standardized set of data sources and capabilities.

Does MCP make an integration secure automatically?

No. MCP standardizes communication. The system still needs authentication, authorization, input controls, and source-system business rules. Security depends on the full request path, not the protocol name.

Does OAuth 2.0 prevent all data leakage?

No. OAuth 2.0 limits which resources or capabilities an application may call. It does not independently decide which customer or document records the user may access. ERP, CRM, or a business API must enforce record-level policy.

What type of use case should come first?

Start with a bounded, measurable read or draft workflow that still has human review, such as summarizing a customer record, checking stock, or drafting a quotation. Add transaction permissions only after the controls are proven.

Conclusion

Secure AI integration with ERP, CRM, and internal systems does not depend on MCP, OAuth 2.0, or an enterprise AI service alone. MCP can standardize connections, OAuth 2.0 can limit application access, and the source system must still decide which data and operations the user is allowed to access.

Before implementation, answer four questions: what data can AI see, on whose behalf is it operating, what can it do, and how can the organization audit or stop it? If the existing systems cannot enforce those answers through controlled APIs, designing the integration layer and purpose-built software system should come before selecting a model or protocol.

Sources and further reading