AI Agent on a CRM: Write and Delete Risks, Guardrails
What risks does an AI agent connected to a CRM create?
A CRM concentrates personal data, amounts, exchange histories and sales pipelines, and it accepts content from outside. An agent using it therefore links an untrusted source (web form, incoming email) to write tools. That is the combination Greshake and his co-authors describe as indirect prompt injection: the model reads content written by a third party and treats it as an instruction.
The risks fall into five families:
- Unintended writes: updating the wrong record, overwriting fields, changing the owner or pipeline stage.
- Deletion: contacts, companies, deals or notes deleted on the strength of a misunderstood or injected instruction.
- Leaks: list exports, account summaries sent outside.
- Writes with outside effect: emails or sequences triggered from the CRM under the company's name.
- Data pollution: false information inserted into records, later read as true by salespeople and other agents.
OWASP groups these cases under LLM06:2025, Excessive Agency, and gives three causes: too much functionality, too many permissions, too much autonomy.
Adding write access changes the nature of the project. A read-only assistant that summarizes accounts can leak, but it cannot corrupt your pipeline. An agent that updates stages, merges duplicates and sends follow-ups can do damage that nobody notices until a salesperson opens the wrong record weeks later. That delay is what makes silent writes expensive: by the time someone spots the error, the original value is gone and the cause is buried in logs.
Is there a real case on a CRM?
Yes: ForcedLeak, discovered by Noma Security in Salesforce Agentforce. The flaw was rated CVSS 9.4. The attacker placed hidden instructions in the Description field of a Web-to-Lead form, which accepts up to 42,000 characters. When an employee asked the AI about that lead, the agent could execute the instructions without telling them apart from legitimate ones. The data was then sent through an image URL to a domain on Salesforce's allowlist whose registration had expired and could be bought for a few dollars.
Salesforce acknowledged the report on July 31, 2025, deployed Trusted URL enforcement on September 8, 2025, and the flaw was made public on September 25, 2025. The case shows two things worth testing: a public form feeds the agent's context directly, and exfiltration can travel through a simple image.
How does a deletion happen without approval?
It happens when the tool exposed to the agent is a generic delete or update API call, reachable with the token of an app that has broad rights. The agent does not need to be "malicious": an ambiguous instruction ("clean up duplicates"), a matching error or an injection is enough.
Take HubSpot's delete-contact API: the documentation says the deleted contact goes to the recycling bin, from where it can be restored in HubSpot. That is a safety net, but it does not cover everything: the documentation page we read does not state retention periods or what happens to associated data. Check with your vendor what is recoverable, for how long and by whom, before giving an agent the right to delete.
| Agent action | Risk | Recommended control |
|---|---|---|
| Read a record | Leak if scope too wide | Scope limited to the user or their team |
| Create a note or task | Pollution, persistent injection | Tag source as "agent", limit fields |
| Edit a field | Data overwrite | Allowed field list, value history |
| Change owner or stage | Commercial impact | Human approval |
| Delete or merge | Data loss | Off by default, human approval, recycle bin checked |
| Send an email or start a sequence | Reputation damage, spam | Human approval, send cap |
| Export a list | Mass leak | Forbidden or capped, audit log |
How do you test an agent connected to a CRM?
You test on a sandbox account or a development instance, with fictional data. The method has four parts:
- Inventory tools and rights. Which app or token does the agent use? Which scopes? Can it delete, merge, export, send? A gap between what is needed and what is granted is already a finding.
- Write tests without approval. Ask for changes in ambiguous natural language ("update customer Martin") with several similar records: does the agent choose without confirming? Is there a summary before the write?
- Deletion tests. Ask it to "clean up", "archive", "merge" a batch of test records. Count what is deleted and check restoration.
- Injection through free-text fields. Place in a test form, note or incoming email an instruction aimed at the agent (for example asking it to add a marker to another record). If the marker appears, the agent obeys untrusted content. Then move to a controlled exfiltration test: does the agent add a URL or an image carrying data to its reply?
Each finding is documented with the request, the tool call and its result. Tests stop at proof: we never delete real data and never send a message to real contacts.
Which guardrails should you add before going live?
These guardrails are enforced outside the model, by the code that calls the CRM:
- Least privilege: a read-only token by default, write scopes limited to the objects and fields needed, and no delete right for the agent.
- User context: the agent acts with the rights of the person using it, which rules out a shared admin account.
- Human approval for irreversible or externally visible actions (delete, merge, send, export), with a summary of what will change. Our article on human-in-the-loop details the forms of approval.
- Caps: number of records modified or sent per run, with automatic stop.
- Incoming content treated as data: form fields, notes and emails reach the model as content to analyze, never as instructions, and are stripped of active elements (URLs, remote images).
- Strict outbound allowlist: the agent can only display or call verified domains. ForcedLeak shows that an allowlist containing an expired domain becomes an exit door.
- Audit log: who asked what, which tool was called, with which parameters.
What support exists for testing your CRM agent?
The Agent Red Team Express (€1,900, 5 days, start within 48 hours after the quote and authorization are signed) can test an agent of this kind: rights, writes, deletion, injection through free-text fields, with a report and evidence. When the agent touches several tools (CRM, mail, calendar), the Custom Red Team is quoted individually. Tests run on a development or staging environment by default; production is targeted only at written request. First step: a free 30-minute discovery call.
Further reading
Does your product ship an AI agent? CleanIssue tests what a stranger can make it do with the Agent Red Team Express (5 days, €1,900), or a custom red team for several agents and MCP servers. First step: a free 30-minute discovery call.
Related articles
Three adjacent analyses to keep exploring the same attack surface.
Excessive Agency (LLM06): limit what an AI agent can do
Excessive Agency (OWASP LLM06:2025): reduce an AI agent's functions, permissions and autonomy, with a concrete test plan you can run today.
Node2Shell: CVE-2026-111497, Brotli RCE in Node.js
Node2Shell (CVE-2026-111497): out-of-bounds write in the Brotli decoder bundled with Node.js, now in CISA KEV. Versions, detection, fix and AI agent risks.
Meta: AI Agent Posts Bad Advice, Sev 1 Incident
In mid-March 2026 a Meta internal agent posted wrong advice without approval; data was exposed for about two hours. Verified facts and controls.
Sources
Related services
If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.