Sales teams were among the first to hand AI agents real authority: agents now read the whole CRM, write records, research prospects and send email in a seller's name, often without anyone reading the message first. That combination of broad customer data, untrusted inbound content (web forms, emails, enrichment feeds) and an outbound channel is exactly the pattern that turns a prompt injection into a data leak, and it adds a second risk security teams rarely own: outreach law. This guide covers the cross-platform risks of CRM agents and AI sales development representatives (AI SDRs): whose permissions the agent runs with, record-level access, data leakage paths, outreach rules for email and calls, and how to monitor agents that act for sellers. Platforms are listed alphabetically (HubSpot, Microsoft Dynamics 365, Salesforce); order is never a ranking. It is written for CRM administrators, security architects and revenue operations leaders. Single-platform depth is in each platform's own guide, linked below.
Key takeaways
- Know whose identity the agent uses. Assistants inside the CRM generally act with the signed-in user's access, while autonomous and customer-facing agents run under a dedicated agent identity whose permissions you must design.
- The CRM sharing model becomes the agent's blast radius. Loose org-wide defaults, broad roles and shared inboxes that people never noticed become instantly searchable by an agent.
- Inbound records are untrusted input. Web-to-lead forms, inbound email and enrichment data can carry instructions; the SalesBleed research showed a public form hijacking a CRM agent with no login and no click.
- Auto-send moves legal liability to the agent's settings. An AI SDR sending without review must still meet CAN-SPAM, PECR and TCPA rules, and both the brand and the sender can be liable.
- Govern agents like integration users. Inventory them, scope them, log every action and review them on the same cycle as connected apps and OAuth grants.
Three kinds of sales agent and why identity differs
Most confusion about CRM agent risk comes from treating three different things as one.
| Agent type | Typical tasks | Whose permissions | Main risk |
|---|---|---|---|
| Embedded assistant (copilot) | Summarise records and emails, draft replies, answer questions about accounts | The signed-in user | Oversharing: surfaces everything the user could technically open |
| Autonomous prospecting agent (AI SDR) | Research accounts, pick contacts, write and send sequences | Configured sender plus agent settings; acts in a seller's name | Outreach law breaches, data leakage in generated email, reputational harm |
| Customer-facing agent | Answer prospects and customers on web chat or messaging, qualify leads, book meetings | A dedicated agent user, or the authenticated customer | Cross-customer data exposure, prompt injection from the public |
The difference matters because controls differ: an embedded assistant is limited by fixing the user's access; a dedicated agent identity is a non-human identity you must provision, scope and review like any integration user. See the Securing Salesforce Agentforce Guide and the Securing Microsoft Copilot Studio Agents Guide for platform-specific agent identity detail.
How each platform scopes agent data access
What each vendor documents about permissions, data use and admin controls, as checked on 8 November 2026.
| Area | HubSpot | Microsoft Dynamics 365 | Salesforce |
|---|---|---|---|
| Permission model for AI | Super Admin permissions required to manage AI settings; prospecting agent rights split into admin, assignment and access permissions (the AI settings article does not describe per-user data scoping for Breeze Assistant) | Copilot "can only get information from records and files that the signed-in user has access to" | Grounding retrieved "based on the permissions of the user executing the prompt"; role-based controls and field-level security preserved |
| Autonomous agent identity | Prospecting agent sends as the contact owner, company owner or a chosen user, with a fallback sender | Sales agent in Microsoft Copilot is documented as the evolution of the Copilot experience for sellers; the overview does not say whether it runs under a separate identity, so confirm before deployment | Agents without an end-user record run as a dedicated agent user (EinsteinServiceAgent User) created with minimal access |
| Admin data switches | Super Admins control "Give users access to generative AI tools and features", "CRM data", "Customer conversation data", "Files data" and "Give users access to Breeze Assistant" | Per-feature controls listed in the Copilot data security FAQ with how to turn each feature off | Agent object access managed in the agent's permission sets (Agentforce Service Agent Secure Base and [Agent_Name]_Permissions) |
| Model training | "AI Model Training" setting, default on; accounts with Sensitive Data on are opted out and cannot opt in | Customer data not used to train Copilot without consent; prompts and responses not used to train third-party models | Third-party LLMs do not retain data (zero data retention) |
| Data boundary | AI features can use CRM records, files and customer conversation data, each controlled by its own setting | Runs within Azure; data stays in the Microsoft Cloud trust boundary except Bing-powered features and third-party plug-ins; some features need data movement across geographies allowed | Sensitive data masked before the prompt reaches the LLM |
| Audit | AI model training toggle changes logged for audit | Feature controls documented per product; use platform auditing for record activity | Prompts, responses and trust signals logged in Data 360 |
Availability: each vendor ties agent features to specific editions and consumption models. HubSpot's prospecting agent needs a Starter, Professional or Enterprise hub (or Smart CRM Professional or Enterprise) and consumes HubSpot Credits; Microsoft points to the Dynamics 365 licensing guide for Copilot entitlements; Salesforce agent features depend on Agentforce entitlements in the org. Check current terms before planning.
For each platform's wider hardening, see the HubSpot Security Guide, the Microsoft Dynamics 365 and Power Platform Security Guide and the Salesforce Security Guide.
Record-level access: fix the sharing model before the agent arrives
Microsoft and Salesforce document that their assistants honour existing permissions, and the same should be confirmed for HubSpot in its current documentation. That is the problem as well as the protection: the agent inherits every access mistake already in the CRM, and makes it searchable in plain language.
- Review baseline sharing: find objects with public read or read/write defaults, broad roles and sharing rules that open records to everyone. Salesforce notes that when an agent runs as the agent user, org-wide sharing defaults for internal users apply, so a public default reaches the agent too.
- Restrict sensitive fields: deal value, margin, personal contact details, health or financial notes and free-text fields often hold more than intended. Use field-level security or equivalent property permissions so agents (and the users they act for) cannot read what they do not need.
- Scope customer-facing agents to the verified customer: Salesforce recommends filtering flows and Apex by the verified customer ID (for example WHERE ContactId = VerifiedCustomerId) and adding filters to actions. The same principle applies on any platform: every query a public agent runs must be bound to the authenticated customer, never to free text from the conversation.
- Limit data sources: turn off sources the use case does not need. HubSpot's "Files data" is off by default and "Customer conversation data" is on by default; decide each deliberately. In Dynamics 365, check which Copilot features rely on SharePoint documents and email.
- Separate agent identities: one agent identity per agent and purpose, with its own permission set, so access can be reviewed and revoked without breaking others. See the Agent Identity and Access Guide.
Data leakage paths in sales agents
| Path | Example | Control |
|---|---|---|
| Oversharing in answers | A seller asks for "all open deals over 100k" and receives records from another region they could technically open | Fix sharing defaults; field-level security on financial fields |
| Generated outreach | An AI SDR email quotes another prospect's details, internal notes or pricing | Review mode for new plays; exclude internal note fields from generation sources; content checks before send |
| Prompt injection from inbound records | Instructions hidden in a web form or inbound email make the agent query accounts and send data out | Treat inbound records as untrusted; restrict tools on sessions that read them; approval for outbound actions |
| Outbound channels | Link unfurling, image rendering, DNS lookups or messaging actions carry encoded data out | Close unneeded rendering and egress; test URL allowlists for parsing gaps |
| Public sharing of outputs | An assistant output saved as an artifact and shared publicly | Policy and settings for public sharing; audit sharing events |
| Model training and retention | Customer data used to improve vendor models | Set training options deliberately (HubSpot "AI Model Training" defaults to on); record the decision |
| Cross-geography processing | A Copilot feature requires data to move across Azure geographies | Approve data movement settings with privacy and legal; document in the transfer assessment |
See the Prompt Injection Guide for the attack class and the Enterprise AI Copilot Security Guide for oversharing in general.
Outreach rules for AI SDRs
An agent sending email or making calls is still sending marketing, and the rules do not soften because a model wrote the message. The CAN-SPAM and TCPA Guide covers the US laws in depth; these are the points that change agent design.
- CAN-SPAM (US email): the FTC lists requirements including no false headers or deceptive subject lines, identifying the message as an advertisement, a valid postal address, a clear opt-out honoured within 10 business days, and staying responsible for email sent on your behalf. Each violating email can draw penalties of up to $53,088, and the FTC says both the company whose product is promoted and the sender can be held responsible. An agent that writes a misleading subject line or ignores an opt-out creates that exposure at scale.
- TCPA (US calls): the FCC has adopted a declaratory ruling recognising AI-generated voices as "artificial" under the TCPA, so voice agents calling consumers fall under the artificial or prerecorded voice rules.
- PECR (UK email): the ICO says you must not send marketing email to individuals without specific consent, subject to the soft opt-in for existing customers, and that sole traders and some partnerships count as individuals. Corporate subscribers can be emailed without consent, but the ICO advises keeping a do-not-email list. The ICO notes this guidance is under review following the Data (Use and Access) Act 2025.
- Design consequences: suppression lists the agent cannot bypass, opt-out handling outside the model, sender identity that is truthful, region-aware rules that classify a contact as individual or corporate before outreach, and frequency caps. HubSpot exposes "Maximum emails the agent will send" and "Minimum days to wait before sending an email" for adaptive outreach; whatever the platform, set caps explicitly.
- Review before autonomy: HubSpot's prospecting agent offers "Review emails" or "Send without review". Start every new play in review mode, sample output, then decide.
Monitoring and governance
- Inventory agents: list every sales agent, its type, identity, data sources, tools and outbound channels, and its business owner.
- Assign permissions deliberately: who may create, configure and enrol contacts in agents. HubSpot separates "Prospecting agent admin", "Prospecting agent assignment" and "Access prospecting agent"; map equivalent rights on every platform and keep them to a small group.
- Log agent actions: collect prompts, responses and tool actions where the platform records them (Salesforce stores them in Data 360) plus record changes and emails sent, and forward to the SIEM. See the Salesforce Event Monitoring Guide for one platform's telemetry.
- Alert on agent anomalies: bulk record reads, queries outside the agent's normal objects, sends to new domains, opt-out complaints and spikes in bounces.
- Review quarterly: agent permissions, data source switches, training and data movement settings, and connected apps used by agents, on the same cycle as integration users.
- Rehearse a kill switch: know how to disable an agent, pause sending and revoke its identity in minutes on each platform you run.
Metrics
- Agent identities with documented owner and permission review in the last quarter: target 100%.
- Agent-sent emails in review mode for new plays: 100% for the first cycle of each play.
- Opt-outs honoured within the legal window: 100%, measured from the request, not from the agent's next run.
- Objects with public read or read/write defaults reachable by agents: trending to zero.
- Agent actions forwarded to the SIEM: 100% of available event types.
Decision guidance: how much autonomy to allow
| Situation | Recommended mode | Why |
|---|---|---|
| Assistant summarising records for sellers | Enable after a sharing review | Risk is oversharing, fixed by the permission model rather than the agent |
| AI SDR writing to corporate contacts in one jurisdiction | Review mode first, then send without review for proven plays with caps | Output quality and opt-out handling can be verified before autonomy |
| AI SDR writing to individuals or across several jurisdictions | Keep review mode or tightly scoped segments | Consent rules differ by region and subscriber type; errors multiply at scale |
| Customer-facing agent on a public channel | Dedicated minimal agent identity, verified-customer filters, no outbound tools on unauthenticated sessions | Every visitor can attempt injection |
| Agent that reads inbound forms or email and can also send | Split into two agents or require approval for outbound actions | Removes one of the three ingredients that turn injection into exfiltration |
Small organisations: one CRM, few admins and no SIEM. Lean on the platform's own settings: keep review mode, restrict agent admin rights to one or two people and review settings monthly. Large organisations: several CRMs and regions. Standardise an agent intake process (owner, identity, data sources, outbound channels, legal basis for outreach), centralise logs and include sales agents in quarterly access recertification.
Common failure patterns
- Turning agents on before fixing sharing: years of loose defaults become a natural-language search over every deal and contact. This applies on every platform that honours existing permissions.
- Accepting default data and training settings: for example HubSpot's AI Model Training defaulting to on, Dynamics 365 features that need cross-geography data movement, or Salesforce agent users given broad sharing to "make the agent work". Each is a decision, not a default.
- Sending without review from day one: an AI SDR writing to thousands of contacts with no sampling, no suppression check and no frequency cap.
- Trusting inbound records: letting an agent read public form submissions and inbound email in the same session as it holds data and outbound tools.
- Shared or overpowered agent identities: one identity for every agent, or an agent user granted a near-admin profile.
- No owner for outreach compliance: security owns the agent, marketing owns the law, and nobody owns the settings where the two meet.
Lessons from incidents
The SalesBleed research, disclosed in September 2026 and fixed before disclosure with no exploitation reported, showed an outside attacker planting instructions in a public web-to-lead form. When an employee later asked a CRM agent about new leads, the agent read the poisoned record, queried account data and encoded it into outbound lookups, while a messaging action could post without user confirmation. The lesson is not platform-specific: any sales agent that reads untrusted input, can reach sensitive records and can send output outward has the same three ingredients. Remove one: restrict tools when untrusted records are in context, close unneeded outbound channels and require approval for outbound actions. For credential-driven CRM theft, see the Sales Engagement OAuth Integration Security Guide.
Practitioner checklist
- Classify every sales agent as embedded assistant, autonomous SDR or customer-facing, and record its identity model.
- Review org-wide sharing defaults, roles and sharing rules before enabling any agent, and fix public defaults on sensitive objects.
- Apply field-level security to financial, personal and free-text fields agents do not need.
- Bind every customer-facing agent query to the authenticated or verified customer.
- Set data source, model training and data movement options deliberately and record the decision.
- Start every outreach play in review mode, with suppression lists, frequency caps and opt-out handling outside the model.
- Classify contacts by region and subscriber type before outreach to apply CAN-SPAM, PECR and TCPA rules correctly.
- Restrict who can create, configure and enrol contacts in agents.
- Forward agent prompts, actions and sends to the SIEM and alert on bulk reads and new-domain sends.
- Test and document a kill switch for each platform's agents.
Standards and references
- HubSpot: Manage your AI settings
- HubSpot: Use the prospecting agent
- Microsoft Learn: FAQ for Copilot data security and privacy in Dynamics 365 and Power Platform
- Microsoft Learn: Copilot in Dynamics 365 Sales overview
- Salesforce Help: Agent user and agent data access
- Salesforce Help: Einstein Trust Layer
- FTC: CAN-SPAM Act Compliance Guide for Business
- ICO: Electronic mail marketing
Related NHI Mgmt Group resources: Securing Salesforce Agentforce Guide · Securing Microsoft Copilot Studio Agents Guide · HubSpot Security Guide · CAN-SPAM and TCPA Guide · AI Agent Honeytokens and Canaries