Zoho permissions for what Claude sees: how to set them before go-live

Zoho permissions for what Claude sees are the settings in Zoho CRM that limit which records and actions an AI assistant can reach. Claude connected through Zoho's MCP servers works as the user who signed in. It reads and changes only what that user may. So you set the user's permissions before go-live, not after.

The Model Context Protocol (MCP) is an open source standard for connecting AI tools to other software. Zoho states that its CRM MCP servers give AI agents authenticated, real-time access to Zoho CRM. Zoho also states that every action inherits the authenticating user's permissions, with a full audit trail. The authenticating user is the person whose Zoho login approved the connection.

That design works in your favour and against you. If the user is a sales rep with a narrow profile, Claude stays narrow. If the user is an administrator, Claude can reach everything an administrator can. The AI adds no gap of its own. It copies the gaps you already have and lets someone find them by asking a question in plain language.

The practical consequence is simple. Every weakness in your profiles, field settings and sharing becomes easier to reach once Claude is connected. A record a rep could open but never thought to look for is now one sentence away. Reviewing permissions is therefore the first task of an AI project in Zoho, not a tidy-up for later.

Claude reaches Zoho CRM through an MCP server, which is a small service that exposes Zoho data and actions as tools the AI can call. Zoho describes the setup for basic use as three steps with no code: pick the servers you need, authenticate via OAuth, and start prompting. OAuth here means the sign-in step in which a person approves the connection with their own Zoho account.

Zoho offers separate MCP servers for separate jobs. Two matter most for permissions:

• Data Insights: read-only access for querying records, module lists and field schemas.
• Data Operations: full create, read, update and delete access, for creating leads, updating deals, removing duplicates and managing contacts.

Zoho says these servers work from tools such as Claude Desktop, Cursor and VS Code, on live CRM data. Admins control which servers are active, which language models are available and how much autonomy each agent gets. Choosing the read-only server is therefore your first control, before any profile setting.

Anthropic's own guidance on connecting Claude to remote MCP servers points the same way. You need the right authentication credentials, and you follow the connection instructions that each provider publishes. For Zoho, those credentials belong to a person. Whose login you use is the decision that shapes everything Claude can see.

A shared login lets Claude bypass your permissions because the MCP connection works on behalf of whoever authorised it. If someone in IT connects once with an administrator account and shares that setup, every person who uses it works with administrator reach. Their own profile no longer matters.

Claude Code shows how easily a setup gets shared. Its MCP configuration has three scopes. Local scope, the default, is available only to you in the current project. Project scope is shared with everyone in the project through a .mcp.json file.

User scope follows you across all your projects. A connection authorised by an administrator and placed in project scope spreads administrator access to the whole team.

The fix is one connection per named person. CData, which sells a managed MCP platform, recommends a separate personal access token for each integration to keep access control granular. The same logic applies to Zoho logins: one person, one connection, one set of permissions.

Named connections also make the audit trail useful. Zoho records actions against the authenticating user. If five people share one login, the log shows one name for five people's questions. When someone leaves, removing a remote server in Claude Code also deletes the OAuth tokens and client registration stored for it. That gives you a clean way to cut off one person without touching anyone else.

API Access for Zoho MCP is a Zoho CRM permission, set on each profile under Developer Permissions, that controls what a user's MCP connection may do. A profile is the set of permissions Zoho CRM applies to a group of users. The MCP permission sits on top of the user's general CRM permissions as a separate layer.

The permission has two settings:

• Get Data: the user's MCP connection can retrieve CRM data, such as running a query or pulling a report, but cannot change anything.
• Execute Actions: the connection can also perform actions, such as updating a record.

The two settings are independent toggles. Turning one on does not imply the other, so review both for every profile. Without Execute Actions, any attempt to write data through MCP is blocked at the permission level. That block holds whatever the AI client itself is capable of. A matching permission exists for Zia Agents, Zoho's own AI agents inside CRM.

The permission applies to the Professional, Enterprise and Ultimate editions, and to the larger Zoho bundles that include CRM. It gives you two questions to answer for each profile. First, what may this user see and edit in Zoho CRM at all? Second, what may their AI connection do with that access? The answer to the second can be narrower than the first, and for most users it should be.

Start every profile with Get Data on and Execute Actions off, then add write access only where someone reviews what Claude changes. Reading a wrong record wastes a minute. Writing a wrong change can be permanent.

Some Zoho CRM actions cannot be undone. A community-published Claude skill for Zoho CRM automation notes that lead conversion is irreversible. The lead record is removed from the Leads module, and conversion can create up to three records: a Contact, an Account and a Deal.

The same skill notes that Zoho CRM allows duplicate records unless duplicate check rules are configured. An assistant with write access can therefore create duplicates at speed. If your data already has duplicates, cleaning your CRM data before adding Claude comes before granting any write access.

Prompt injection is the second reason to keep writes narrow. Prompt injection is text hidden in content Claude reads that tries to give it new instructions. Anthropic's Claude Code documentation warns that MCP servers that fetch external content can expose you to this risk. A customer email stored on a CRM record is external content. If that connection can only read, a planted instruction has far less it can change.

Write access earns its place where the change is small, visible and reviewed. Updating a deal stage after a call, with the rep confirming the change, is a reasonable case. Bulk updates across hundreds of records are not.

This worked example takes a sales team with two profiles, called here Field Sales and Sales Manager, and sets Claude's access for each. The names are illustrative; use your own profile names.

1. Open the Field Sales profile in Zoho CRM and review what it already allows. Claude will see exactly the same modules, records and fields that the rep can.
2. Under Developer Permissions on that profile, find API Access for Zoho MCP. Turn on Get Data. Leave Execute Actions off.
3. Open the Sales Manager profile. Under the same permission, turn on both Get Data and Execute Actions.
4. As administrator, activate the Data Insights server. Activate Data Operations only because the managers need writes. The Field Sales profile still blocks writes for reps.
5. Ask each person to connect Claude Desktop with their own Zoho login through OAuth. No shared account, no administrator login.
6. Test with one rep. Ask Claude for that rep's open deals, which should work. Then ask it to change a deal stage, which should be blocked.

The result is two clear behaviours. A rep can ask Claude which of their deals have gone quiet and get an answer from live data. The rep cannot have Claude change anything. A manager can ask the same question and then have Claude update the record, with the change logged against the manager's name.

The setup above takes care of the AI layer only. If the Field Sales profile already shows reps more than it should, Claude will show it too. Fix the profile first.

The table below is a starting checklist for Zoho permissions for what Claude sees, by type of user. Adjust it to your own profiles, but keep the pattern: read by default, write by exception, never a shared login.

Two rows deserve a note. Administrators often want Claude for their own work, which is fine on a second, ordinary profile. Connecting with full administrator rights for daily questions brings back the bypass this guide is trying to remove. Shared logins have no row where they are the right answer.

Review the table again whenever you add a profile, change a server or switch on Execute Actions for a new group. Permissions drift as teams change, and the AI connection drifts with them.

Testing means signing in as a user on each profile and asking Claude for things that profile should not reach. A permission you have not tested is a permission you are assuming. The test takes less time than explaining a leak afterwards.

At Svennis we connect Claude with a test user on every profile before go-live and ask it for records, fields and changes that the profile should refuse. Anything that comes back is fixed in the profile before a real user connects.

A useful test set for each profile covers four requests:

• a record owned by someone outside the user's team;
• a field the profile hides, such as a margin or a salary field;
• a change to a record, where Execute Actions is off;
• a report that summarises data the user cannot open record by record.

The same rule holds when Claude works in front of Zoho Desk. Connect it as a user whose Desk access matches the job, and test it the same way before agents rely on it. The Teams service desk built on Claude and Zoho Desk shows what that looks like in practice. Keep the test set and run it again after every permission change.

Zoho permissions stop at the edge of Zoho. Once Claude's answer is copied into an email, a slide or a chart, the profile no longer controls who sees it. Zoho's own analytics team makes the point plainly: an AI-generated chart is a file, and sharing it shares everything in it.

Row-level security is a BI platform capability that recognises who is viewing and shows each person only what they should see. A regional sales rep and the finance director can open the same report and see different rows. A chart produced in a chat and then forwarded has no such layer.

The same article warns that data pasted into an AI tool is accurate only as of the moment it was exported. A spreadsheet export also carries every column the exporting user could see. Asking Claude to query live data through a permissioned connection is safer than pasting an export into a chat.

For reporting, Zoho Analytics offers its own MCP server that connects to Claude. According to Zoho, the BI platform still handles the access controls, governance and metric definitions underneath. That keeps row-level rules in force while people ask questions in plain language. Deciding which Zoho CRM numbers Claude should report is part of the same decision about who sees what.

For a UK company, the main practical point is timing. The API Access for Zoho MCP permission is planned for customers in the US, IN, EU, AU and JP data centres. At the time of the source this guide relies on, the rollout was live in the IN data centre only, with other data centres following in phases.

Check which data centre your Zoho account uses and whether the permission appears under Developer Permissions on your profiles. If it does not appear yet, your controls are the ones already in place: the user's profile, the choice of the read-only Data Insights server, and one connection per named person. Do not plan a go-live around a toggle you cannot see.

Audit matters for any firm that answers to a regulator or a client's security review. Zoho's analytics team notes that in regulated industries, knowing who saw a number and when is a compliance question. Named connections give you that answer. A shared login does not.

Data protection questions sit alongside permissions rather than inside them. Permissions decide which records Claude may read. They do not settle whether sending those records to an AI model suits your obligations. Work through the GDPR checklist for European firms using Claude before personal data flows through the connection.

The order of work matters more than any single setting. Permissions first, connection second. Use this sequence before anyone connects Claude to Zoho CRM:

1. List every person who will use Claude with Zoho, and the profile each one has.
2. Review each profile for records and fields that user should not see, and fix them in Zoho first.
3. Set Get Data and Execute Actions on each profile, if the permission is live in your data centre.
4. Activate the Data Insights server for reading. Add Data Operations only for profiles that need writes.
5. Run the four-request test with a test user on every profile.
6. Connect each person with their own Zoho login, never a shared or administrator account.

Once the permissions hold, the connection itself is the easy part. The step-by-step guide to connecting Claude to Zoho CRM with MCP walks through the setup in Claude. Keep this checklist next to it, and run the tests again whenever a profile or a server changes.