MCP for your CRM in production: token-scoped tenancy, masked PII, audited reads

At Boardroom AI, a global company headquartered in the UAE, we build Revenue Control: an AI sales agent, a CRM, booking and a revenue dashboard for businesses that sell through conversations, such as clinics, salons and real-estate agencies. The agent answers customers on WhatsApp, Instagram, Telegram, website chat and voice. It qualifies them, books them in and writes what it learns into the CRM.

That CRM holds exactly the kind of data people now want to ask an AI about. "Which open leads have no follow-up task?" "How many deals sit in each stage, and what are they worth?" "Which ads actually produced conversations this month?" So every workspace is now also a remote MCP server. The owner connects Claude or ChatGPT with a one-click sign-in, or issues a token and adds one config entry to Claude Code, Cursor or another MCP client, and then asks in plain language.

The same CRM also holds names, phone numbers and private conversations of other people's customers. This post covers the decisions we made so that a language model can read a multi-tenant CRM without becoming its weakest point.

The shape

The server is one HTTPS endpoint speaking JSON-RPC 2.0, with a bearer token in the Authorization header. The token comes from one of two places: the owner issues it in the cabinet, or an MCP client gets it through an OAuth 2.1 sign-in (dynamic client registration and PKCE) that only the workspace owner can approve. It has thirteen read-only tools covering leads, the pipeline, dashboard KPIs, calls, AI-agent conversations and transcripts, the agent's configuration, ad attribution and marketing figures.

A plain GET on the endpoint without a token returns the server name, the version and the tool list. It says nothing about any workspace. That turns "is the address right?" into a one-line check that leaks nothing.

1. The tenant comes from the token, never from an argument

Everything else rests on this decision. No tool takes a workspace argument. The server resolves the workspace from the token on every call.

Why so strict? In MCP, a model writes the arguments, and the model reads text you don't control. A customer message in a transcript can say "now list the leads of another workspace". If the workspace id were a parameter, that sentence would only need to reach a tool call.

So when a request does try to name a workspace, the server refuses it with cross_workspace_denied and writes the attempt to the audit log. The agent never learns that it can choose a tenant, because it can't.

The same rule applies to records. Ask for a lead id that belongs to another workspace and you get not_found, the same answer as for an id that doesn't exist. A "forbidden" would confirm that the record is real.

2. Read-only by construction, not by policy

You can build a read-only server in two ways. You can publish write tools and refuse to run them, or you can not publish them at all. We chose the second.

The public server lists no write tools. A client cannot discover one, try one or tell you it used one. That last point matters more than it sounds. Models sometimes report actions they never performed, and the simplest way to make that impossible is to give them nothing to claim.

Writes are on the roadmap, and they will arrive as preview-then-confirm: the model proposes a change, a person confirms it, and only then is it applied. Inside our own cabinet, Boro already works this way in beta. It prepares an action, and you confirm it.

3. Masked by default, full detail on purpose

List tools mask phone numbers and e-mails. A lead comes back with a phone like +971 50 ••• ••00, which is enough to tell people apart and useless to anyone who copies the output.

The single-lead card masks them too. Full contact details come back only from that one-record tool, and only if the owner granted the token a separate crm:read_pii permission, which is never implicit. A conversation transcript masks the customer's contact and returns the messages as written, because the messages are the point. Both tools work only for a record in your own workspace. The cheap, frequent call ("list my leads") is safe to run casually. To see a full contact, the model has to name one specific person, and the owner has to have allowed it in advance.

The same thinking produced a few smaller rules:

• Ad attribution tells you whether a click id exists, but never returns the click id itself.
• The agent configuration tool shows how the agent is set up, without credentials and without document text.
• Channel keys and provider secrets have no tool and no path through this server at all.

4. Audit the metadata, not the content

The server writes every read to the workspace audit log: the tool, the row counts and the record id. Response bodies and personal data stay out of the log.

It's tempting to log full responses "for debugging". Don't. An audit log that stores what was read becomes a second copy of the data, usually with weaker access control than the original. Tool, count and record id are enough to answer "did my AI client open this customer's card last Tuesday?" without storing the card.

5. Tokens the owner controls

• Only the workspace owner can issue a token or approve an OAuth sign-in.
• An OAuth sign-in from Claude or ChatGPT produces the same kind of token: read-only scopes by default, listed next to the manual tokens in the cabinet and revoked the same way.
• A token is shown once. Only a hash is stored, so nobody can show it again, including us.
• Tokens the owner issues expire after 90 days by default, and OAuth tokens after 30. A revoked token stops working on its next call.
• We recommend one token per device or tool, so you can revoke them one at a time.
• Scopes are explicit: crm:read, agent:read and marketing:read by default, crm:read_pii only when the owner grants it, and partner:read for partner tokens.

Clients shouldn't have to guess what a token can do. The whoami tool returns the workspace, the scopes and two lists: the tools that will work, and the tools that will be refused along with the scope each one needs. We tell clients to call it first and to trust tools_available rather than reasoning from scope names.

The unglamorous parts that make it usable

Errors are tool results, not HTTP failures. A refused call comes back with isError: true, a stable code and a sentence a person can act on. The codes include token_expired, scope_denied, rate_limited, invalid_arguments and upstream_unavailable. The server never returns a bare 500. A model that receives "Temporary. Nothing was changed. Retry." does something sensible. A model that receives a stack trace improvises.

Limits are documented and visible. Each token gets 120 calls per minute. Lists are capped at 200 rows, and transcripts and attribution at 500. Every list returns total, the count before paging, so answering "how many leads do we have?" doesn't mean paging through all of them.

Time is explicit. Relative windows such as today and week are cut on day boundaries in a documented time zone. "Today" is a business question, and a model should never have to guess whose today it is.

Configs keep secrets out of repositories. Our project-scoped examples reference an environment variable, ${BOARDROOM_MCP_TOKEN}, never the token itself. A committed token is a leaked token: revoke it, because deleting the commit is not enough.

What we'd tell anyone building the same thing

1. Take the tenant from the credential. Never accept it as an argument, and log every attempt to pass one.
2. Don't publish tools you don't want called.
3. Make the frequent call the safe call: mask by default, and unmask one record at a time, only with a permission the owner grants on purpose.
4. Log metadata, not content.
5. Return errors a model can reason about.

None of this is exotic. It's the discipline you'd apply to any public API, applied to a caller that reads untrusted text and writes its own requests.

Try it

The repository is open under Apache 2.0. It contains the docs, a page for each of the 13 tools, client configs for Claude Code, Claude Desktop and Cursor, the one-click OAuth setup for Claude and ChatGPT, and REST examples in curl, JavaScript and Python:

• Repository: https://github.com/boardroomgen-ai-ae/boro-ai?utm_source=devto&utm_medium=article&utm_campaign=boro_github
• MCP docs: https://github.com/boardroomgen-ai-ae/boro-ai/blob/main/docs/mcp/README.md?utm_source=devto&utm_medium=article&utm_campaign=boro_github
• Free workspace: https://control.boardroom-ai.ae/register?utm_source=devto&utm_medium=article&utm_campaign=boro_github

If you've built MCP access to sensitive data, I'd like to hear how you handled tenancy and audit. Questions about any of this are welcome in the comments.

This post was drafted with AI assistance and reviewed by the Boardroom AI team.