AI agent CRM permissions: a buyer's worksheet

Before connecting an AI agent to your CRM, define which records and fields it may read, which actions it may take, and where those limits are enforced. Start with a narrow task and require a demonstration that forbidden actions fail. A persuasive summary is not evidence that the agent has appropriate access.

For a growing Houston business, a sensible first task might be preparing an internal account summary for a salesperson. That does not require permission to export every contact, change deal values or send customers messages. I would put those boundaries into the project brief before discussing the agent's personality or interface.

Separate reading, drafting and committing a change

Write an access worksheet for one task. Use these prompts with the person responsible for the CRM and the proposed implementer:

1. Which records are in scope: the assigned accounts, one branch or another explicitly defined set?
2. Which fields may the agent read, and which must remain unavailable?
3. Can it prepare a suggestion outside the CRM, save a draft inside it, or commit a change?
4. Can it send anything to another person or system? Name each permitted destination.
5. Which identity performs each action, and who can revoke its access?
6. Where will you inspect the action and its result?

Treat saving a draft inside the CRM as a write, even if nobody has sent it. Keep exporting separate from viewing. Specify whether attachments and free-text notes belong in scope rather than assuming that access to an account includes everything attached to it.

These are proposed purchasing requirements. OWASP's authorization guidance supports the underlying approach: assign only necessary privileges, deny access unless allowed, and check permissions on every request.[1]

Require controls outside the agent's instructions

Ask the implementer to show where the application or integration rejects an unauthorized request. A sentence in the agent's instructions saying "do not edit billing details" should not be the only barrier. Require the receiving system to enforce the permitted identity, operation and record scope, even when a request comes through a different route.[1]

Do not accept a shared administrator login as the default demonstration setup. Ask which narrower integration identity or supported delegated permissions the selected CRM offers. If its permission model cannot express your boundary, ask what additional enforcement the design needs before approving the connection.

For an MCP-based integration, the versioned MCP tools specification requires servers to implement access controls and says clients should not trust tool annotations unless they come from trusted servers. A tool description is not proof of enforcement.[3] Require the same business boundary whichever connection method the supplier proposes.

Decide what the agent may see before testing what it can do

Read access deserves its own review. Chrome's WebMCP security guidance explicitly warns that even a tool that does not change state can reveal user information.[2] A read-only CRM pilot should therefore have limits on the information it retrieves and where that information goes.

Ask for a data-flow sketch showing the CRM, the integration, any model provider and the place staff will read the result. Have the implementer identify what each receives and which proposed storage, retention and logging settings need your approval. Do not accept "read-only" as an answer to those questions.

Name the authoritative record for each important fact. For example, your proposed worksheet might make the CRM's structured renewal-date field authoritative and require the agent to flag a conflicting note. Require the summary to identify its source record and retrieval time. If a required field is absent, the expected result should say it is missing rather than invent a value.

A sample decision record to adapt

This is an invented scoping example, not a deployed client system or a recommended universal configuration:

1. Task: prepare an internal renewal summary for the salesperson's assigned accounts.
2. Allowed reads: account reference, assigned owner, renewal date and approved product fields, restricted to those accounts.
3. Excluded information: payment details, unrelated contacts, attachments and free-text notes.
4. Allowed output: a draft summary in an internal review screen, with source references and retrieval time.
5. Forbidden actions: CRM updates, bulk exports, outbound messages and changes to account ownership or permissions.
6. Missing or conflicting data: flag the account for review without guessing or changing its record.
7. Acceptance owner: the designated sales operations manager, who reviews the boundary tests before a live connection is considered.
8. Stop control: the CRM administrator can disable the integration identity; the demonstration must show that access then fails.

Copy this record and replace its fields with your decisions. If the proposed task needs customer notes, add them deliberately and revisit the data-flow review. Do not quietly widen access just because the first summary lacks context.

Buy a boundary demonstration, not just a successful summary

Use an isolated test environment with invented records and no live customer data. Disable real outbound delivery and keep production credentials out of the exercise. Ask for these checks before accepting the design:

1. An authorized test account returns only the allowed fields.
2. A different account and an excluded field remain inaccessible, including through a direct integration request.
3. A request to edit a renewal date or send a message is rejected.
4. A test note containing instructions to export contacts cannot authorize that export.
5. Disabling the integration identity prevents further access.

Require a record of the attempted action, the access decision and the supported result readback without copying excluded information into logs. Keep that receipt separate from the business outcome: retrieving a renewal date does not establish that the date is correct, and generating a summary does not establish that a renewal happened.

If your project includes writes later, use the separate guide on checking an integration's outcome before retrying. For now, bring your completed worksheet to a discussion of API integration services, or contact me about the proposed workflow. Describe the systems and permission boundaries without sending credentials or confidential records.

Common buyer questions

Is read-only access enough for a safe pilot?

No. Also define the records, fields, recipients and data handling allowed in the pilot. Test those limits with invented data before considering live access.

Should every action need a person to click approve?

Choose review requirements for the specific action. Human confirmation should supplement, not replace, application-enforced access limits.

Does a successful demo mean the agent is ready for production?

No. It establishes only the demonstrated behavior in that environment. Require a separate review of the actual CRM permissions, data handling and operating responsibilities before connecting production.

Sources

1. [1] OWASP: Authorization Cheat Sheet (official source)
2. [2] Chrome for Developers: WebMCP tool security
3. [3] MCP specification 2025-06-18: Tools