Secure AI for Salesforce

Security is the most consistent concern organizations raise when evaluating AI for Salesforce. CRM data is not generic information: it includes customer relationships, deal terms, internal communications, and financial data that organizations have clear obligations to protect. This article covers what a secure AI implementation looks like in practice and how AI Engine approaches data governance.

The Real Risk: Uncontrolled External AI Use

The security conversation around AI and Salesforce often focuses on the wrong risk. Organizations worry about whether a Salesforce-native AI tool is safe, while overlooking the more immediate problem: without a governed option, users will use ungoverned alternatives.

When there is no sanctioned way to use AI with Salesforce data, sales reps and service agents find their own. They copy account details, deal terms, and customer emails into external AI chatbots. This creates exactly the risk organizations are trying to avoid: CRM data being shared externally with no visibility, no auditability, and no control over how it is retained.

A Salesforce-native AI integration with clear admin controls is a security improvement over the status quo, not a security risk.

Admin-Controlled Object and Field Access

The foundation of a secure Salesforce AI integration is admin control over what data the AI can access. AI Engine implements this in its Agent Objects settings, where admins select:

• Which Salesforce objects are available to the AI (Leads, Accounts, Opportunities, Cases, custom objects)
• Which fields within those objects the AI is told about and receives as record context
• Which of those fields hold personal data and are masked before anything is sent

This means fields containing sensitive financial terms, personal data governed by privacy regulations, or internal notes that should not leave the organization can be left out of the record context and out of the field list the AI works from. The selection is made by the admin, not the user, and it never widens anyone's access: the AI reads data with each user's own permissions, so field-level security and sharing apply on top. Two settings reach further and deserve care: a chat query on an enabled object can also read other fields of that object that the user can see, and objects added to Meeting Prep include every field the user can read. See What is sent to the AI provider.

PII Masking Before Data Reaches the AI

Excluding a field is one option. But many teams still want the AI to reason over a record that happens to contain personal data, without exposing that data to an external provider. AI Engine handles this with built-in PII masking.

When masking is enabled, AI Engine replaces personal data with neutral tokens before any record context is sent to the AI provider. It works in two layers:

• By field type: email, phone and address fields are recognised and masked automatically, regardless of country format.
• By pattern in free text: email addresses, US Social Security numbers, IBANs and payment-card numbers (validated with the Luhn check) are detected and masked inside any text field.

Admins can also flag any field, on parent records and on child objects, as PII, so org-specific sensitive fields are masked too. The AI model works on the tokens instead of those values. When the response comes back, the tokens are converted back to the real values automatically, so the user always sees the real data while the masked values never leave Salesforce in readable form. Other data in the enabled fields, such as people's names and job titles, is sent as it is. Masking is on by default and can only be turned off intentionally by an admin. More in PII masking for Salesforce AI.

Prompt Templates and Consistent Governance

Allowing users to write free-form AI prompts introduces governance risks. If a user could instruct the AI to read anything, the field-level restrictions would become less meaningful.

AI Engine offers admin-defined prompt templates for repeatable actions. Users run them from the Actions menu, and the template defines what the AI is instructed to do, what data it receives, and how the output is formatted. Users can also ask their own questions in the chat, but those stay within the same limits: the chat can only query objects the admin enabled, runs with the user's own permissions, and its queries can only read data.

This creates consistent, auditable AI behavior across the team, within boundaries the admin sets.

Named Credential Security for API Keys

API keys for OpenAI, Claude, or Azure OpenAI are managed through Salesforce Named Credentials, Salesforce's built-in mechanism for storing and managing external service credentials securely. This means:

• API keys are not visible to AI Engine users
• Keys are rotated in Salesforce Setup, on the External Credential, without changing AI Engine's configuration
• Which users can call the provider through the credential is controlled by a Salesforce permission set

Permission Set Controls

AI Engine uses Salesforce Permission Sets to control who can use it: AI Engine User for everyone who uses the AI features, and AI Engine Admin for the people who configure it. Admins can assign them to specific teams or individual users, directly or through permission set groups, keeping AI access aligned with the organization's existing user management practices rather than introducing a separate permission system.

Data Residency and Provider Choice

Some organizations have data residency requirements that affect which AI provider they can use. For organizations subject to European data protection regulations or sector-specific compliance frameworks, Azure OpenAI provides an alternative to the standard OpenAI API: requests go to a resource in your own Azure subscription, in the region you choose, under your Microsoft agreement. One exception: on Azure OpenAI, web-search features call OpenAI instead, through a separate Named Credential. See Choosing a provider for compliance.

AI Engine supports OpenAI, Anthropic Claude, and Azure OpenAI. The provider is configured by the admin using a Named Credential, and the prompt templates work consistently across providers. Organizations can migrate between providers without rebuilding their AI action configurations.

What AI Engine Does Not Do

To be specific about the security architecture: AI Engine does not store Salesforce field data externally, does not maintain a separate database of CRM records, and does not call the AI provider on its own. Each AI action is a point-in-time API call using the data configured for that feature, triggered by a user, or, if an admin turns them on, by automatic or scheduled AI Scoring. The output is returned to Salesforce and displayed to the user; scores are written to the score fields on the record.

For compliance and legal teams: AI Engine is a Salesforce managed package. All configuration, user access control, and credential management happens inside your Salesforce environment. AI Engine adds no Cloud Connected server to the data path: requests go from your org to the AI provider account you configured, and that provider is the external party to assess, under your agreement with it.

Frequently Asked Questions