An AI assistant connected to your database or CRM through MCP: why a dedicated read-only account

What MCP does

MCP is a standard that lets an AI assistant (Claude, ChatGPT and others) use tools: run a database query, read a record in the CRM, search a folder on a drive. The MCP server exposes the tools, the assistant decides when to use them, and the result comes back into the conversation. That is how “how many customers have bought nothing for six months” gets an answer from your data, not from the model’s general knowledge.

The MCP server connects to the system on some account. And that is the whole point: the assistant sees exactly what that account sees, and can do exactly what that account can do. MCP neither adds nor removes permissions.

Why a separate account

The easiest route is to connect the server on the account of whoever sets it up: the administrator, the owner, the developer. It works immediately, and the assistant immediately has that person’s permissions, usually all of them. Three consequences:

• Scope. The assistant sees salaries, margins, personal data, everything the administrator sees, and will answer questions about any of it to anyone who can use it.
• Consequences. If the account can change and delete, the assistant can change and delete. A misunderstood “tidy up the old records” ends differently from what anyone intended.
• Accountability. In the system’s log every action by the assistant looks like that person’s. You cannot tell human from AI.

A separate account solves all three. It has its own permission set and its own trail in the log.

Why read-only

Most of what companies want an assistant for is reading: summarise, find, compare, prepare me for a call, how many, who, when. Reading does no damage. Writing does. So the account starts read-only; writing is added only when a specific task needs it, in a narrow scope, with a person confirming. On when AI may act alone, see the article on the human in the loop.

How to set it up

1. Write down the questions. Which questions should the assistant answer? From the list of questions follows the list of objects, tables and fields. Everything else is out of scope.
2. Create the account. In the CRM: a separate user with a permission set built from scratch: read on the named objects and fields, no sensitive fields, no export. In the database: a separate user with SELECT on views prepared for the assistant, not on tables, with personal-data columns left out. On the drive: specific folders shared as “can view”.
3. Limit the reach. A cap on rows per query, on query time, on queries per minute. A mistaken request for a whole table returns a thousand rows, not a million.
4. Connect the server on that account. Through OAuth where available, with a read-only scope. Keys and passwords in a secrets manager, not in a config file.
5. Set an expiry date. The token and the account expire. Renewal is the moment to review: still needed, scope still right.
6. Test with awkward prompts. “Delete the duplicates”, “show me the ID numbers”, “change the price in the proposal”, “export all customers”. The assistant should refuse because the system does not allow it, not because we asked nicely in the instructions.

What to log

What	Why
Who asked (the assistant’s user)	To know whose question led to the query
Which tool, with what parameters	To reconstruct what the assistant did without guessing
What came back: row count, size, time	To spot “give me everything” queries; content is not logged if it is sensitive
Errors and refusals	To know what the assistant tried and could not do
Timestamp and server version	To tie a change in behaviour to an update

The log lives with you, is read monthly and kept for as long as you decide. For the first month we read it together: it shows what people really ask and where the scope is too narrow or too wide.

The most common mistakes

• An employee’s personal login. A salesperson connects the assistant with their own account; it sees what they see, and when they leave nobody knows the connection exists.
• The admin account, “because it will definitely work”. It will. And it will be able to do everything.
• The “full access” OAuth scope. Because it was first on the list. The scope should be read-only if one exists.
• A “read-only” database user that has write rights. The account’s name is not a permission. Check what it can actually do.
• Production first. Test on a copy or past data; production only after the awkward-prompt tests.
• No list of connections. Keep one: system, account, scope, who connected it, until when. Reviewed quarterly.

If you want to connect an assistant to your CRM, drive or database and get it right first time, this is how an AI-connected-to-systems project goes.