Back to blog
CRMHubSpotSalesforceexcessive agencyAI agents

AI Agent on a CRM: Write and Delete Risks, Guardrails

Published on 2026-11-047 min read
In short: An AI agent connected to a CRM (HubSpot, Salesforce) combines three risks: it reads customer data, it reads content written by third parties (forms, emails, notes), and it can write or delete. If any of its actions requires no approval, text planted in a record is enough to trigger changes or a leak. The main safeguard is an authorization check placed outside the model, with read-only rights by default.

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 actionRiskRecommended control
Read a recordLeak if scope too wideScope limited to the user or their team
Create a note or taskPollution, persistent injectionTag source as "agent", limit fields
Edit a fieldData overwriteAllowed field list, value history
Change owner or stageCommercial impactHuman approval
Delete or mergeData lossOff by default, human approval, recycle bin checked
Send an email or start a sequenceReputation damage, spamHuman approval, send cap
Export a listMass leakForbidden 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:

  1. 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.
  2. 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?
  3. Deletion tests. Ask it to "clean up", "archive", "merge" a batch of test records. Count what is deleted and check restoration.
  4. 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.

Know what your agent can do before an attacker does.

A free 30-minute discovery call: you describe your agent, I tell you what I would test and what it costs. Five case studies are published.

Book a call