Your AI Agent Is Read-Only But Your CRM Changed Anyway

An engineer ran a small experiment and published it on Habr: an AI model with no permission to write to a CRM still ended up changing a CRM record. Not because the model broke out of its limits, but because the component sitting behind it had the keys. If you are about to let an AI agent near your customer database, this is the distinction that matters more than any vendor promise.

What actually happened in the test

The setup was a workflow built on n8n, with DeepSeek as the model and HubSpot as the CRM. The model itself had no HubSpot credentials. It could not call the CRM directly. That part of the restriction was real.

The next step in the workflow, however, did have write credentials. Its job was to take the model's structured proposal and execute it. In the control scenario, the human-readable request referred to one synthetic test deal, while the structured target pointed to a different one. The workflow went ahead, issued the update, and the wrong deal changed. A separate read afterwards confirmed it: the second deal had been modified, the first was untouched.

The author then added one thing — a separate deterministic check between the model's proposal and the actual CRM call. That check looked at a short list of parameters: which system was being touched, which object ID, what state the record was expected to be in, and which transition was allowed. Credentials did not go anywhere; the workflow could still write. But now writing depended on passing that check first. The normal scenario passed and completed. The mismatched one was denied, and the record stayed as it was.

The conclusion the author draws is short: what the model is allowed to do is not the same as what the system is allowed to do. In classic security terms this is close to the confused deputy problem — an old idea showing up in a new place.

Why this matters for a small business

The sentence "the agent is read-only" is convenient. It goes into an architecture note, a security questionnaire, a client answer, or a decision to go live. If that sentence is based only on which credentials the model holds, it describes part of the chain, not the whole of it.

For a business, the practical risk is not a dramatic one. It is quiet and boring: the wrong deal gets updated, the wrong order gets marked paid, the wrong customer gets a status change. Nobody notices for a week. Then someone tries to reconcile numbers and cannot explain them. The audit trail, if it exists, shows a successful API call — technically correct, factually wrong.

This applies to any business letting automation touch operational data: a CRM, an order system, a ticketing tool, inventory. The more ordinary the automation feels, the less likely anyone is checking the boundary where the actual change happens.

What to check before an agent touches customer data

The article ends with six questions worth asking before production or before widening an agent's permissions. Turned into a checklist you can run this month:

• Find where the write credentials physically live. Not where the model is, but which component makes the external call. That component defines your real exposure.
• List what gets verified immediately before the call. Target system, object ID, expected current state, allowed transition. If nothing is verified at that moment, the check does not exist in any useful sense.
• Ask whether the target can shift between the request and the write. The lab case was exactly this: request named one record, structured proposal named another. Nothing malicious, just a mismatch that nothing caught.
• Put an independent gate between proposal and consequence. In the test, the gate was deterministic code, not another model deciding whether the first model was right.
• Confirm the resulting state after the action, not just that the call succeeded. A separate read is what proved the outcome in both directions of the experiment.
• Keep a reconstructable chain. What was proposed, who could execute it, what was checked, what was actually called, what state came out of it. Without that, you have a claim about control rather than evidence of it.

The takeaway

This was a lab test with synthetic records, and the author says so plainly. But the principle transfers. Removing credentials from the model is a genuine control — it just limits the model, not the system around it. Before you sign off on an agent, trace the permission all the way down to the component that can cause a real-world change, and put your check there. That is the only place it does anything.