Giving an agent write access to your CRM
An agent that only reads produces a wrong answer someone notices. An agent that writes produces a wrong record everything downstream inherits. Four controls decide which of the two you are building.
Contents
- Key takeaways
- A write path is not a read path with extra steps
- The threat you design against is injection, not error
- Scope the credential before writing any code
- Make every write idempotent
- Dry-run first, and keep it forever
- Decide which actions a human has to approve
- The audit log is the deliverable
- FAQ
An LLM agent can write to a CRM safely when four controls exist. Scope the credential to specific objects and fields, key every write for idempotency, show the diff in dry-run before applying it, and put a human gate on anything irreversible. Every write lands in an audit log.
Key takeaways
- Prompt injection has no reliable fix today. Assume the agent will eventually read hostile instructions from the data it processes.
- OWASP files the underlying risk as excessive agency: too much functionality, too many permissions, too much autonomy. All three are configuration decisions.
- Idempotency keys stop a retried request from creating a second opportunity for the same deal. An IETF draft defines the
Idempotency-Keyheader for this. - CVE-2025-32711, published on 11 June 2025, records a zero-click prompt-injection disclosure in a production assistant. The attack class is documented, not hypothetical.
- Dry-run mode and an append-only audit log cost a few days of work and decide whether an incident is explainable.
A write path is not a read path with extra steps
A read-only agent that gets something wrong produces a wrong answer. Someone notices, and the record is unchanged. A write-enabled agent produces a wrong record, and routing, forecast, commission and the next email inherit it quietly.
That failure is also harder to see, because nobody reviews 400 field updates. The design question is not whether the model is accurate enough. It is whether the system around it limits a bad write to something you can find and undo.
The threat you design against is injection, not error
Prompt injection sits at the top of the OWASP Top 10 for LLM Applications. Its indirect form—instructions hidden inside content the model retrieves—has been documented since 2023, and the mitigations are still partial.
Greshake and colleagues described indirect prompt injection in February 2023. An attacker plants instructions in data the model will later retrieve, so no direct access to the application is needed. Their tests showed arbitrary code execution against systems already in production (arXiv:2302.12173).
A CRM is made of retrieved data. Email bodies, web-form free text, meeting notes and support tickets all reach the context window. Simon Willison's triage makes the exposure visible: risk concentrates where a system holds private data, reads untrusted content and can communicate externally. A CRM agent usually has all three.
Scope the credential before writing any code
Most CRM platforms issue tokens per integration with per-object and per-field permissions. The agent does not need account deletion or the user object, and rarely needs more than a handful of fields on leads, contacts and tasks.
Run the integration as its own identity, never as an admin user. Then give it narrow tools instead of a generic API client. A tool called update_lead_stage(lead_id, stage) can be reasoned about and rate-limited. A tool called call_api(method, path, body) cannot.
Make every write idempotent
Networks time out, queues redeliver, and models retry. Without idempotency, a retry becomes a duplicate contact or a second task someone closes by hand.
The IETF HTTP API working group draft for theIdempotency-Keyheader, revision 07 of 15 October 2025, defines a client-generated key. It lets a server recognize a retry it already processed, so methods such asPOSTtolerate failure (IETF Datatracker).
Derive the key from the operation, not the attempt: record identifier, intended change, time bucket. If the platform ignores the header, keep your own table of applied keys.
Dry-run first, and keep it forever
The agent produces the exact set of writes it intends to make, the system renders them as a diff, and nothing is applied. Two weeks of that against live data reveals more than any benchmark about where the agent is confidently wrong.
Keep the mode after launch. It doubles as the regression test for prompt changes and the way to onboard a skeptical sales team.
Decide which actions a human has to approve
The useful split is reversibility. An appended note, a logged activity or a suggested tag can pass straight through. Stage changes, owner reassignment, merges, deletions and anything that triggers an outbound message need approval.
OWASP's guidance on excessive agency points the same way: minimize functionality, minimize permissions, require approval before consequential actions. Approval also needs a real interface. A queue inside the CRM works; a Slack message nobody owns is a version of the handoff gap that kills good leads between marketing and sales.
The audit log is the deliverable
Log the trigger, the retrieved context, the model output, the tool call, the idempotency key and the human decision. The store is append-only and the agent cannot reach it with its own credential.
That log answers the only question that matters after an incident: what changed, when, and on what input. It is also the evidence base for the record-keeping duties arriving with the EU AI Act timeline. NIST's 2025 taxonomy is blunt about the limit here: mitigations for these attack classes remain empirical and may fail against new techniques. Reversibility is not prevention, but it is what you have.
FAQ
Can prompt injection be fully prevented?
No. NIST's AI 100-2e2025 taxonomy, published in March 2025, notes that mitigations against adversarial machine learning attacks are largely empirical and can fail against new techniques. Treat injection as a permanent design constraint and limit what a compromised agent is able to do.
What is the minimum viable safe setup?
A dedicated integration credential limited to four or five fields, three or four narrow tools, idempotency keys on every write, dry-run by default, and human approval on irreversible actions. Everything else, including the model choice, matters less than these five.
Should the agent write directly or propose changes?
Propose first. Run in dry-run for several weeks, measure how often a person accepts the proposal without editing it, and promote only the action types that cross a threshold set in advance. Promotion is per action type, never for the agent as a whole.
Which model should we use?
The one that is cheapest to evaluate against your own task set. Model choice affects how often the agent proposes something useful. It does not affect what a compromised agent can do, as with any question about retrieval, evaluation and cost in production.
Build in this order: credential scope, idempotency, dry-run, approval gates, log. Inverting it produces a demo that cannot be audited later. That is the trap in judging CRM AI features by the demo, and the reason the build, buy or wrap decision comes first. In six months there will be enough data to know which actions earned autonomy. Until then, a person presses the button on anything irreversible.
