Integrating AI agents into your CRM: what they can read, what they can write and how to undo their changes

Most conversations about integrating AI agents into a CRM start with what the agent will do: sort contacts, summarise conversations, suggest the next step, move a deal forward. They rarely start with the question that prevents the most trouble: which parts of the CRM should it be able to touch, and what happens when it gets something wrong?

An agent with admin rights can do in one afternoon what takes your team weeks to clean up: overwrite phone numbers, merge contacts that were never the same person, move deals to the wrong stage or send customer data somewhere it shouldn't go. This article walks through how to design those permissions before you connect anything, whether your business is in Mallorca, Ibiza, Menorca or elsewhere in the Balearic Islands.

Permissions matter more than the model

It's tempting to spend your time choosing the AI model or polishing the prompt. In a CRM, though, most serious failures don't come from the agent "thinking badly". They come from the agent being allowed to do more than it should:

• It writes to a field another process relies on for invoicing.
• It updates records in bulk when it should only have touched one.
• It reads internal notes or personal data it never needed.
• It changes something, and nobody can later tell who changed it or what the old value was.

With tight access, an agent mistake is a nuisance you fix in minutes. Without it, it's a data problem, a customer problem and, where personal data is involved, a data protection problem.

Step 1: treat reading and writing separately

Make two lists. One for what the agent needs to read to do its job, and one for what it needs to write. The second list is almost always much shorter than it first looks.

For every item on the read list, ask:

• Does this task actually need it, or is it "just in case"?
• Does it include sensitive personal data, such as health details, bank details or ID documents?
• Would a partial version do, like the town instead of the full address?

Anything that fails those questions comes off the list. Less data read means less risk, and usually sharper answers too.

Step 2: put every writable field into one of three levels

A simple yes or no isn't enough for the write list. We suggest three levels.

Level A: the agent writes directly

Low-risk fields that are easy to check: a summary of the latest conversation, a language tag, a note on where the lead came from. If the agent is wrong, nothing breaks.

Level B: the agent proposes, a person confirms

Fields that drive decisions or other processes: deal stage, assigned owner, follow-up date. The agent leaves a suggestion, in a separate field or as a task, and someone on the team accepts or corrects it.

Level C: never

Billing data, agreed terms, marketing consent, unsubscribes, contact merges and any deletion. The agent can flag things ("these two contacts look like duplicates"), but it doesn't act.

Put this in a plain three-column table: field, level and reason. That table becomes the reference for setting up the integration and for settling arguments later on.

Step 3: give the agent its own user

A common mistake is connecting the agent through an admin account or a shared API key. A much better setup:

• A dedicated user or credential for the agent, clearly named, for example "AI Agent".
• A role limited to the permissions in your table, configured in the CRM itself if it supports it, or in the integration layer if it doesn't.
• Access only to the records it handles: if it only deals with website leads, it shouldn't see the rest.

That way every change the agent makes shows up under its own name in the CRM history, and if you ever need to cut it off, you disable one user without affecting anyone else.

Step 4: log every change with its previous value

You can only undo what you can see. Each write by the agent should be recorded with:

• Which record and which field changed.
• The old value and the new value.
• When and why, meaning the conversation or data point behind it.

Many CRMs already keep field-level history. Check that it's switched on and that it covers changes made through integrations. If your CRM doesn't do this well, the integration layer can keep its own log. The goal is being able to answer "what did the agent touch this week?" in under a minute.

Step 5: build the undo button before you need it

With that log in place, undoing becomes possible. Decide upfront how you'll:

• Undo one change: restore a field's previous value on a single record.
• Undo a batch: roll back everything the agent changed in a given period, for instance since a new instruction went live.
• Pause the agent: one clear switch that stops its writes without stopping the rest of the CRM.

Test it in a sandbox or on a handful of records before opening it up to real volume. An undo you've never tested isn't a plan.

Step 6: cap the volume

Even if every single change is correct, a confused agent can chain hundreds of them in no time. Set limits on:

• How many records it can change per hour or per day.
• Bulk updates, which should always need approval.
• Alerts, so a person hears about it when the agent is about to hit a limit.

Seasonal businesses, which are everywhere in the Balearics, can see contact volume jump within a few weeks. Review these limits before peak season, not halfway through it.

A hypothetical example: a boat charter company in Port d'Andratx

Picture a skippered boat charter company in Port d'Andratx that gets enquiries through its website and by email in Spanish, English and German. It wants an AI agent to keep those enquiries organised in its CRM.

Using the method above, its table might look like this:

• Read: name, language, requested dates, group size, previous enquiries. No access to internal payment notes or customer documents.
• Level A: enquiry summary, detected language, type of trip requested.
• Level B: deal stage and follow-up date, proposed by the agent and confirmed by the bookings person each morning.
• Level C: agreed price, deposit paid, consent to receive offers and any contact merges.

The agent runs under its own user, only sees contacts that come in through the website and email, and can't change more than an agreed number of records per day. If one week the bookings person spots odd summaries, they check the log, roll back those days and adjust the instructions before switching the agent back on.

Are you ready? A quick checklist

Before connecting an agent to your live CRM, you should be able to say yes to all of these:

1. Is it written down, field by field, what the agent reads and writes?
2. Does the agent have its own user with limited permissions?
3. Is every change logged with the previous value?
4. Have you tested undoing a single change and a whole batch?
5. Is there a volume cap, and does someone get the alert?
6. Does your team know how to pause the agent without calling anyone?

A "no" doesn't mean you can't move forward. It just tells you what to sort out before giving the agent more autonomy.

How we can help

At Derek Solutions we design and build AI agent integrations for CRMs for businesses in Mallorca and across the Balearic Islands, starting with permissions, change logging and a tested rollback plan. See how we work on our AI and automation in Mallorca page, and if your CRM needs its own control layer for all this, we also build custom software in Palma de Mallorca.

Want to work out what an agent should and shouldn't be able to touch in your CRM? Email derek@dereksolutions.com or call +34 680 283 973 and we'll go through it with you.