The Key You Hand to an AI: What an External Agent May Read in Your CRM — and What Waits for Your Yes
Most small firms already have an AI client they like. The problem is that the client does not know anything about the firm: not the deals, not the invoices, not the customer who called yesterday. Connecting it to the CRM solves that problem with one address and one key — and the interesting engineering is not the connection, but the brake attached to it.
The connection uses MCP, the Model Context Protocol: a standard way for an AI client to ask a server which tools exist and to call them. Firmspace exposes such a server at one address, /api/connect/mcp, speaking JSON-RPC over HTTP. Claude, ChatGPT, Cursor, n8n, Zapier, DeepSeek Harness or a script of your own can use it; nothing has to be installed on a server and no database password is shared. For tools that prefer a plain list, the same key opens /api/connect/tools with names, descriptions and parameters.
The key is created in the CRM under Settings → Integrations → Connect an agent, and only the owner or an administrator can do it. It gets a name, a level, a list of sections and one switch for approvals. The key itself is shown once, at the moment of creation; the database keeps only a hash, so a forgotten key is replaced, not recovered. A firm can hold up to twenty keys, which is enough for one per tool or per person and too few to quietly accumulate them.
Two levels exist. Read makes the agent a viewer: it can look, search and summarise, but it cannot write. Work makes it a manager, which means the same rights a human manager has in the sections the key was given. The section list is not decoration: a key limited to CRM and tasks cannot open the mailbox or the warehouse, no matter what the AI client asks for. A viewer cannot change a deal even if the approval switch is off.
Inside those limits the agent sees the same tools the assistant inside the CRM uses: search contacts and deals, read a deal's history, list invoices, check stock, look at tasks, search mail, read a PDF from Documents, create a deal, add a note, draft an invoice. But the list is filtered hard. There is no delete, no cleanup of junk cards, no rule that decides which mail becomes a lead, no screen control, no assistant memory and no blog publishing. Destructive and service tools are simply not exposed, because an external agent should not be able to erase a year of records by misreading one instruction.
The approval switch is the centre of the design. With it on — the default — a write does not happen. The agent receives an answer saying the change is pending, with a request id, and the request appears in the CRM under Settings → Integrations → Agents. The owner sees what is being proposed, by which agent and when, and chooses approve or reject. Approving runs the action with the owner's rights and re-checks the arguments; the tool call is not replayed blindly from the agent's memory.
The switch is per key, not per tool. That is a deliberate simplicity: either all writes from this agent wait, or none do. If the owner turns approval off for a trusted automation, the same key can create records immediately, and the only remaining fence is the section list and the role. Turning it back on is a one-line decision. A firm that wants an exploring assistant should issue a read key; one that wants a proposing assistant should leave approval on; a fully automatic key should be a conscious, narrow exception.
Reads do not wait. A search or a summary runs immediately, because the cost of a wrong read is a wrong answer, while the cost of a wrong write is wrong data that someone will later invoice, ship or report. Every call is logged with the agent's name and one of four states: read, proposed, executed, failed. That log is the first place to look when an AI client claims it did something — the claim and the record are different things.
There is one more door, and it is optional. A key can be allowed to read named environment variables of the firm — an API key for a delivery service, for example — through a separate tool. The owner lists the names, or allows all with a wildcard; names are normalised and limited, and every read is written to the audit log with the agent's name. This is a convenience, not a vault: a key with a wildcard is a key that can read every secret the firm has stored, so the narrow list is the sane default.
The limits are deliberately boring. A key may make 120 requests per minute; a firm may make 5,000 agent calls per day; a single tool result is clipped at 30,000 characters, so a careless request cannot drag a whole database into a chat window. Agent access needs a plan that includes the AI assistant, and a blocked organisation gets nothing. These numbers are not a marketing promise — they are the fence that keeps an enthusiastic client from turning into a load test.
A key is not a user, and it should not be treated as one. Name it after the thing that uses it, not after a person; keep one key per tool or laptop; check the «last used» and call counter; revoke the key when the tool is gone or the laptop is lost. A revoked key answers 401 immediately, and there is no «undo» needed because the key never contained the data — it only opened a door that is now closed. Nothing here replaces the CRM's own roles: the agent sees only the intersection of the key's scope and the role it maps to.
The practical way to start is unromantic: create a read key, connect the client you already use, ask it questions about one deal and one invoice, and compare the answers with the screen. When the answers are boringly correct, add a second key with the work level and approval on, and let it propose one note or one task. The point of the whole mechanism is not that an AI can reach your CRM. It is that the door is narrow, the handle is on your side, and every push is written down.