Connecting AI Assistants to CRM and ERP Systems Safely

Levels of integration

Start at the lowest level that delivers value and move up only with evidence that controls work.

Identity and authorization

• Use delegated authorization, such as OAuth, so the assistant acts as the signed-in user with that user's permissions and record-level sharing rules.
• Request only the scopes each tool needs, and use short-lived tokens.
• Avoid API keys or service accounts with administrator rights.
• Follow current OAuth security guidance, such as RFC 9700.
• Develop and test against sandbox environments, never production data.

Design narrow tools

• Offer specific actions with typed parameters, such as "get order status by order number", rather than "run any query".
• Validate every parameter on the server: allowed values, ranges and whether the user may access that record.
• Limit how many records a single call can return.
• Make create actions idempotent so a retry does not create duplicates.
• Provide a preview that shows exactly what will change before anything is committed.

Confirmation and separation of duties

• Show the user a clear summary of the change and require explicit approval.
• Keep high-risk operations, such as payments, bank details, credit limits and price overrides, out of the assistant, or route them through the ERP's existing approval workflow.
• Never let the assistant approve its own proposals.

Prompt injection and data exfiltration

The OWASP Top 10 for LLM Applications highlights prompt injection and excessive agency as leading risks for connected assistants. A CRM note, a customer email or a web page can contain text designed to make the assistant perform actions or reveal data.

• Treat tool results and retrieved content as data, not instructions.
• Restrict which actions are available after the assistant has read untrusted content.
• Do not automatically render links or images from model output, which can be used to send data to outside servers.
• Rely on human confirmation as the final safeguard for changes.

Tool protocols

The Model Context Protocol (MCP) is increasingly used to expose tools and data to AI applications. Its specification includes security best practices: proper authorization, avoiding token passthrough, protecting against confused deputy problems, validating inputs and connecting only to trusted servers.

Data minimization and privacy

• Return only the fields needed to answer the request.
• Mask sensitive values such as bank account and tax identification numbers.
• Set retention for conversation and tool logs.
• Confirm that the model provider's data terms suit the information involved, and apply the Data Privacy Act's purpose and proportionality principles.

Reliability

• Handle API errors, timeouts and rate limits gracefully, and tell the user what happened.
• Verify that record identifiers exist before acting; models can invent plausible ones.
• Keep multi-step changes consistent, so a failure halfway does not leave records half-updated.

Monitoring and audit

• Log the user, the request, each tool call with parameters, approvals and results.
• Alert on unusual activity, such as bulk lookups or repeated failed actions.
• Review logs regularly during early rollout.
• Keep a switch that disables tools quickly if something goes wrong.

Rollout path

1. Read-only lookups for a pilot group.
2. Drafting assistance with human sending.
3. Confirmed changes to low-risk fields.
4. Broader use as monitoring confirms that controls work.