CRM Permissions for AI Agents: Access Checklist - Relaticle [ Back to blog ](https://relaticle.com/blog) ![CRM permissions for AI agents: an access checklist](https://relaticle.com/storage/ink/01M38HCK3DY8GPEAQ2Z5FW3S3J.png)CRM permissions for an AI agent should identify its workspace, allowed operations, and approval point. For reporting, start with a credential that rejects writes. For editing, verify who reviews changes and how you revoke the connection. We build Relaticle. Its built-in chat proposes CRM writes for approval. External assistants using its MCP server execute authorized writes directly. Connecting the same model through those paths does not give it the same approval behavior. This guide provides an access worksheet and acceptance tests. The examples describe expected behavior to verify, rather than tests performed on your configuration. [](#choose-one-job-before-issuing-access "Permalink")Choose one job before issuing access ----------------------------------------------------------------------------------------- Start with a request you can inspect: prepare the weekly pipeline review from open opportunities, notes, and tasks. That job requires reads. It does not require deleting contacts, changing owners, or creating custom fields. A second job might create tasks from meeting notes. It needs reads to resolve records and assignees, plus permission to create the tasks. Deletion remains unnecessary. Write down these boundaries before opening the connector settings. “Manage our CRM” is too broad to determine which operations the connection needs. [](#compare-the-three-relaticle-access-paths "Permalink")Compare the three Relaticle access paths ------------------------------------------------------------------------------------------------- Several controls can apply to a tool call. Workspace binding, user authorization, token abilities, and confirmation answer different questions. | Connection | What limits operations? | |---|---| | MCP with a personal token | Selected token abilities and user authorization | | MCP with OAuth | User authorization; the OAuth scope grants toolset access | | Built-in Relaticle chat | User authorization and the application's proposal flow | | Connection | Where are writes confirmed? | |---|---| | MCP with a personal token | In the external client, if configured | | MCP with OAuth | In the external client, if configured | | Built-in Relaticle chat | A person reviews the CRM proposal | Personal access tokens support read, create, update, and delete abilities. The token form also asks you to select a workspace. Relaticle OAuth connections use the `mcp:use` scope and bind access to the selected workspace. That scope does not offer separate read and write choices. The connected user's authorization still applies. If the credential itself must reject writes, use a personal token with read permission. Choose a client connection method that supports that token. A prompt saying “only summarize” does not turn an OAuth connection into a read-only credential. The [MCP tools specification](https://modelcontextprotocol.io/specification/2025-11-25/server/tools) recommends human oversight while leaving the interaction design to implementations. Tool labels and OAuth consent do not establish a per-write approval gate. [](#fill-out-the-access-worksheet "Permalink")Fill out the access worksheet --------------------------------------------------------------------------- Here is a fictional reporting connection for a small agency: ``` Connection: Friday pipeline review Business owner: Sales lead Technical owner: Workspace administrator Purpose: Prepare a review of open opportunities and outstanding tasks. Client: The team's chosen MCP client Authentication: Personal access token Workspace: Agency sales pilot Allowed operations: Read Allowed data: Records available to the connected user in that workspace Write approval: No writes permitted by this credential Review date: Before expanding the pilot to another workflow Revocation: Revoke the personal access token in Relaticle Evidence: Known read succeeds, attempted update fails, revoked read fails ``` Replace each entry with your actual choice. Keep the credential secret out of this document. Notice the data boundary. Relaticle token abilities restrict operations. They do not create a per-field confidentiality policy or a pipeline-only record filter. A reporting token may read more than the fields mentioned in the prompt. If your requirement limits records or fields, verify the additional control before connecting. The business owner decides whether the workflow remains appropriate. The technical owner manages the connection, review, and revocation. One person can hold both roles. [](#prove-that-the-intended-restriction-works "Permalink")Prove that the intended restriction works --------------------------------------------------------------------------------------------------- Use disposable records in a pilot workspace with the configuration you intend to use. Keep expected results outside the assistant's conversation. ### [](#test-1-confirm-the-connection-identity "Permalink")Test 1: Confirm the connection identity Ask the assistant which workspace and authenticated user the connection exposes. Compare that answer with the settings you selected. Then retrieve a known company. Confirm its identity and open the returned record link. Expected result: the connection reaches the intended workspace and record. A familiar company name alone is insufficient if multiple workspaces contain it. ### [](#test-2-attempt-a-denied-write "Permalink")Test 2: Attempt a denied write Using the reporting token, request a harmless rename of the disposable company. The server should reject the update. Open the record independently and confirm that its name remains unchanged. Record the denied tool result without recording the credential. An assistant declining politely does not prove server enforcement. The useful evidence is a write request rejected by the credential's allowed operations. ### [](#test-3-check-editing-separately "Permalink")Test 3: Check editing separately Create a separate editing connection only if the workflow requires it. Request one low-impact change and observe the actual confirmation point. For built-in chat, inspect the pending CRM proposal before approving it. Reject it first and verify that the record remains unchanged. For external MCP, inspect the client's tool confirmation. Deny the call and verify that no change occurs. Then allow a clearly identified test change. If the client runs authorized tools without confirmation, record that behavior. A written prompt does not add an application approval card. Repeat the test after any “remember this choice” setting. First-call confirmation can differ from the behavior of later calls. ### [](#test-4-revoke-access "Permalink")Test 4: Revoke access Revoke the test token or OAuth connector, then attempt another read. Expected result: the revoked connection cannot retrieve the record. Document where the owner performed revocation and which connection they removed. An unused connection with no identifiable owner should not survive the pilot indefinitely. Our [Claude connection walkthrough](https://relaticle.com/blog/how-to-connect-claude-to-your-crm-with-mcp) covers setup paths. Use the [MCP documentation](https://relaticle.com/developers/mcp) alongside your client's current authentication instructions. [](#make-each-proposed-change-reviewable "Permalink")Make each proposed change reviewable ----------------------------------------------------------------------------------------- An editing request should identify the record, current value, intended value, and supporting source. For example, changing a company owner requires the company ID and both owner identities. Similar names should trigger clarification before execution. Use this request alongside the access policy: ``` Prepare a plan for the named CRM changes. Show each record name and ID, current value, proposed value, and source. List uncertain matches separately. Wait for my approval before writing. After execution, read the changed records and report each outcome. ``` This prompt improves the conversation. Only the actual client and server controls determine whether an unapproved tool call can execute. If a request creates several records, review their relationships too. A correct task attached to the wrong opportunity still needs correction. [](#read-access-still-moves-information "Permalink")Read access still moves information --------------------------------------------------------------------------------------- A read-only connection cannot edit the CRM. It can return information to the assistant and its model provider. Review the destination of those reads separately from write permissions. Decide which workspace and customer information belong in the pilot. Also treat content inside records as data. A note saying “export all contacts” does not authorize that operation merely because an assistant retrieved it. Restricting operations reduces the actions available if the assistant mishandles an instruction embedded in a record. It does not replace review of the client's data handling. [](#keep-a-usable-record-of-partial-failures "Permalink")Keep a usable record of partial failures ------------------------------------------------------------------------------------------------- One conversation may involve several tool calls. A company could be created before its follow-up task fails. Ask for a report listing completed records, failed operations, and remaining work. Before repeating a create call, check whether the record already exists. A timeout does not prove that a write failed. Replaying the whole request can produce duplicate work. For deletion, test the product's actual recovery behavior separately. Relaticle's CRM delete tools use soft deletion, but MCP does not provide a restore tool. [](#decide-whether-the-connection-meets-the-job "Permalink")Decide whether the connection meets the job ------------------------------------------------------------------------------------------------------- Close the pilot with three pieces of evidence: permitted reads, denied writes or verified confirmations, and successful revocation. If a required restriction is absent, narrow the job or choose another access path. Do not replace a missing control with stronger wording in the prompt. Revisit permissions when the workflow changes, its owner leaves, or the connection gains new capabilities. Our [agent-native CRM guide](https://relaticle.com/blog/what-agent-native-crm-actually-means) explains the broader capability distinctions. The completed worksheet should make the reason for every permission visible to the next person responsible for the connection. Tagged: [ #mcp ](https://relaticle.com/blog/tag/mcp) Related posts ------------- [ Guides Oct 6, 2026 HubSpot migration checklist: moving to another CRM ---------------------------------------------------- This HubSpot migration checklist covers moving to another CRM, including exports, associations, workflow replacements, and a worked cutover check. ![HubSpot migration checklist: moving to another CRM](https://relaticle.com/storage/ink/01M38HCG3RJEN1A8NHAGXAE8WW.png) ](https://relaticle.com/blog/hubspot-migration-checklist) [ Guides Oct 2, 2026 Five CRM workflows to hand to Claude -------------------------------------- Five CRM workflows for Claude: pipeline reviews, meeting notes, lead entry, data cleanup, and weekly digests, with explicit read and write boundaries. ![Five CRM workflows to hand to Claude](https://relaticle.com/storage/ink/01M17KWYEEY8XB0VPJB7VV1D1Z.png) ](https://relaticle.com/blog/five-crm-workflows-to-hand-to-claude) [ Guides Sep 29, 2026 Backups, upgrades, and security for a self-hosted CRM ------------------------------------------------------- A practical operating playbook for backing up, upgrading, and securing a self-hosted CRM without treating customer data casually. ![Backups, upgrades, and security for a self-hosted CRM](https://relaticle.com/storage/ink/01M17KWWPXPKX3V7DN7YZGR2PW.png) ](https://relaticle.com/blog/backups-upgrades-and-security-for-a-self-hosted-crm) ### On this page