Start with a brief that a person can check
Consider a relationship manager preparing for a customer call. Relevant information might sit in a Salesforce opportunity, approved Dropbox documents and recent correspondence. An assistant could assemble a draft brief with links to those sources and a list of unresolved questions.
Keep this first task specific. It reads permitted information and prepares a draft. Sending a message, changing the opportunity or sharing a file are separate actions with separate requirements. This article describes an integration pattern, not a measured customer deployment.
What MCP contributes
Model Context Protocol provides a standard way for an AI application to connect to tools and resources. It does not, by itself, supply business memory, decide who may see a record or approve a write. Those behaviours depend on the application, server and connected systems.
MCP: authorisation specification
Evaluate supported connectors before building a custom server. Capabilities and access differ by product and account configuration. Connecting four products does not necessarily require four bespoke servers, and a connector that works in one client may need a different setup elsewhere.
| System | A useful initial boundary |
|---|---|
| Salesforce | Read approved fields from records the user is allowed to access. |
| Dropbox | Retrieve specific permitted documents and retain their references. |
| Outlook | Use the authorised correspondence needed for the brief; keep any reply as a draft. |
| Slack | Share an approved summary only to an authorised destination when explicitly requested. |
Enforce permission outside the model
Keep credentials on the server or in the supported credential store. Check the requesting user, permitted records, tool arguments and destination before executing a call. A sentence in a prompt is not an access-control mechanism.
Use narrowly defined tools rather than an unrestricted ability to fetch any URL, read any file or run any query. Limit returned fields as well as the records selected. A summary must not reveal information from a document the intended reader cannot open.
Treat text from documents, messages and CRM fields as untrusted input. A message that tells the assistant to send a confidential attachment somewhere else must not become an instruction to change its permissions or workflow.
Make actions and failures understandable
Show what the assistant proposes to change and which records or recipients are involved. Obtain the required approval before performing a consequential action. Keep the approval tied to that action and its current inputs so a later change cannot reuse an earlier approval silently.
When a credential expires or access changes, stop the affected operation and give the authorised owner a recovery route. Do not broaden permissions to make a failed run succeed. For an uncertain write response, inspect the destination state before retrying.
Run a representative pilot
- The user can read one opportunity but is denied another.
- A linked document is unavailable or has a more restrictive audience.
- Two sources contain conflicting dates or commitments.
- An input document attempts to redirect the assistant’s actions.
- A draft is rejected or changed before approval.
- A tool call fails, times out or returns an incomplete result.
Record whether the brief is accurate, whether its sources can be checked and how much correction it needs. Keep operational logs focused on identifiers, statuses and versions, with access and retention rules. An integration becomes useful when the people using it understand both the result and the next step.
Explore a scoped internal rollout
Discuss a similar workflow
Bring a description of the process, the systems involved and one example of where work gets stuck. We can use discovery to establish the requirements, dependencies and next step before preparing a solution and estimate. Please leave private customer, applicant and patient records out of the website enquiry.