Connecting an AI agent to your CRM safely: reads, writes, and the write gate

5 minute read · Written by the team that builds UtilitySpaces. More about UtilitySpaces.

Connecting an AI agent to a CRM safely comes down to three rules. Reads run unattended. A write waits for a person unless an admin has set that connection to run without asking. And the agent can only call operations on an explicit, closed list, through a scoped connection credential the workspace holds, never through your login. Everything else in this piece is those three rules applied to contacts, companies and deals.

We build UtilitySpaces, and the CRM is where a wrong write hurts most: the record is shared, the contact is a real person, and an email sent by mistake cannot be unsent. So this is written from the side of the product that says no.

Why are reads and writes treated so differently?

Because the cost of being wrong is asymmetric. An agent that reads a contact it should not have read has created a privacy question you answer afterwards. An agent that creates a duplicate contact, changes a deal stage or emails a customer has changed a system other people depend on, and the undo is a person’s time, or a phone call, or not available.

So the working default is the one built into UtilitySpaces connectors: every operation is marked as a read or a write, reads pass straight through, and a write waits in the approval queue until an owner or admin approves it. Approved, it runs exactly once; rejected, it never runs and the reason goes back to the agent. An admin can set a connection to run without asking or to refuse writes, and that change is recorded. A tool the policy does not recognise counts as a write, so the gate fails closed.

Which CRM actions should always stop?

Anything that cannot be taken back by the person who would have to take it back. For a CRM, that list is short and worth writing on the wall.

• Deleting a record. The contact, the company, the deal. Even where the CRM has a recycle bin, the history attached to the record often does not come back with it.
• Merging records. Merge is deletion with a confident face. Two records become one and the fields that lost the merge are gone.
• Emailing or messaging a contact. The damage is not in your database; it is in somebody else’s inbox, and recall is not a technical operation.
• Changing ownership or deal stage in bulk. One reassignment is housekeeping. Forty is a reorganisation nobody announced.
• Anything touching money. Deal amounts, discounts, close dates that drive a forecast someone else reports.

Here is the part that surprises people: in UtilitySpaces, most of those actions never reach the approval queue, because the agent cannot reach them at all. The CRM connectors expose no delete, no merge and no send-email operation. An action absent from that list is not gated; it is impossible. The gate is for the writes that do exist.

What does the list of operations actually look like?

For the two CRM connectors it is small enough to print, which is the point. An agent given a HubSpot or Twenty connection can call exactly these operations and nothing else.

That is the whole surface. No update, no delete, no merge, no email. If your job needs one of those, this connector is not the way to do it, and we would rather say so here than on the day you find out.

The table is generated from the same catalogue the product reads at run time, so the integration pages and the agent agree by construction. Each page on the integrations index lists its own read and write split the same way.

What does “fails closed” mean?

That the answer to anything not on the list is no, and no is the default rather than the exception. An agent that asks for an operation the connector does not define gets a refusal, not a best guess. An agent whose workspace has two CRMs connected and no binding chosen for a write gets the write refused with the reason, because two candidates is a question, not a tie-break.

The alternative, failing open, is the shape most integrations take by accident: a broad token, a generic HTTP tool, and the agent is trusted to only call the endpoints the prompt mentions. That works right up until the prompt is ambiguous or the ticket the agent is reading contains instructions aimed at it. A closed list of operations is what makes a prompt-injection attempt harmless: the injected instruction asks for an operation the agent does not have.

What is a connection credential, and what is it not?

It is a token the CRM issues for machine access, stored encrypted in the workspace and attached to one connector. For HubSpot that is a private-app access token. For Twenty it is the URL of your Twenty instance plus an API token. The agent never sees either; it asks the connector to perform a named operation and the connector presents the credential.

It is not your login. Nobody’s password is typed into a prompt, and revoking the token at the CRM cuts the agent off without touching anyone’s account. It is also not, on its own, a permission system. The token’s scope at the CRM is the outer wall; the connector’s operation list is the inner one. If the CRM only issues a broad token, that list is doing all the work, which is a reason to keep it short rather than a reason to relax.

One habit worth forming: issue the token for the agent, not for a person. A token copied from a colleague’s account inherits that colleague’s access and disappears when they leave. The four ways of granting access, ranked by what each costs when it leaks, are in giving an AI agent app access safely.

What does a safe first CRM job look like?

Read-heavy, write-light, and boring. A daily pass that lists new deals and posts a one-line summary of each into the sales channel. A check that lists contacts created this week and flags likely duplicates by email, then stops, because merging is a person’s job done in the CRM itself. A weekly list of companies with no open opportunity.

The first write to allow is the smallest one: create a contact from an enquiry that arrived in the inbox. The request in Approvals carries the full properties, so the person approving it sees the email address and the name, not the sentence “create a contact”. After enough identical approvals you will know whether the connection has earned running without asking.

Three things to watch in the first week. Whether the agent ever asked for an operation it did not have, which means either the job needs one more tool or the role text is inviting it to wander. Whether every create it proposed was one you would have made yourself, checked against the payload rather than the summary. And whether anyone on the team has quietly redone the agent’s work in the CRM, because rework is the honest signal and an approve rate is not. If all three are clean for a fortnight, widen in one dimension, never three.

Where this does not reach

If those limits fit the job, the rest is configuration: one connector, one agent with three reads and at most one write, and a week of reading the thread. The demo workspace lasts exactly sixty minutes from creation; its agents have no connectors, so it shows the inbox, tasks and audit trail rather than a CRM call. Start a demo workspace.