The security architecture that makes Agentforce enterprise-ready
"How do we know the AI won't leak customer data?"
That is the right question to ask before enabling Agentforce or another supported Salesforce generative AI feature. The Einstein Trust Layer provides important safeguards, but an administrator still has to verify permissions, data pathways, masking behavior, audit collection, testing, and human review.
For the architecture-level explanation, start with What Is the Salesforce Einstein Trust Layer?. This page is the implementation checklist: what an administrator should confirm before approving a Salesforce AI use case for production.
Administrator Checklist: What to Verify Before Enabling Salesforce AI
1. Verify the Permission Context
Secure data retrieval grounds supported prompts with Salesforce data that the executing user or running context can access. The Trust Layer does not repair an unsafe sharing model, excessive Permission Sets, or overly broad field access.
Before testing:
- Identify the user, integration, or agent context that executes each feature.
- Review object permissions, field-level security, record access, and Data 360 permissions used by the feature.
- Test with a least-privileged user and with a deliberately restricted user.
- Confirm that restricted records and fields do not appear in generated responses or agent actions.
2. Map the Data Path Before Relying on Masking
Document where the prompt template is invoked, what data is added, which model processes it, and whether the model is inside or outside the Salesforce trust boundary.
For supported direct generative AI flows, the Trust Layer can mask sensitive information according to the configured pattern-based and field-based masking rules.
Important Agentforce limitation: Salesforce states that pattern-based and field-based LLM data masking is disabled when a prompt template is invoked through an agent action. When the same prompt template is used directly, masking can apply according to the Trust Layer configuration. Do not approve an Agentforce use case on the assumption that prompt-template masking will protect agent inputs.
3. Confirm External-Model Handling
Salesforce's external model-provider agreements include zero-data-retention commitments. Data sent to those providers is not retained, viewed, or used for model training after the response is returned.
Grounding and zero data retention are different controls:
- Grounding supplies relevant business context to the prompt.
- Permission-aware retrieval limits which Salesforce data can be used for that grounding.
- Zero data retention governs what an external model provider may do with data sent outside the Salesforce trust boundary.
Record the selected model, provider, trust boundary, and applicable contractual terms for each production use case.
4. Test Prompt Defense and Toxicity Controls
Prompt defense adds system policies intended to reduce jailbreaking, prompt injection, and unintended outputs. Salesforce notes that these policies can vary by generative AI feature and use case. Toxicity scoring provides another safety signal for supported responses.
Your test plan should include:
- Benign prompts that represent normal user work.
- Prompts that request data the test user cannot access.
- Prompt-injection attempts that try to override instructions.
- Inputs containing sensitive or toxic content.
- Expected escalation or refusal behavior.
- Confirmation that relevant safety signals appear in the configured audit data.
These controls reduce risk; they do not replace least-privilege access, scoped agent actions, monitoring, or human review.
5. Configure Audit and Feedback Collection
Do not assume every interaction is automatically or permanently available for review. Salesforce requires audit and feedback collection and storage to be configured.
Current Salesforce setup path:
- Provision Data 360 and enable Einstein for the applicable feature.
- In Setup Quick Find, enter Einstein Audit.
- Select Einstein Audit, Analytics, and Monitoring Setup.
- Turn on Audit and Feedback.
- Choose the appropriate Data 360 data space.
- Restrict access to the resulting audit and feedback data.
- Verify that the reports, dashboards, and data streams are available.
Salesforce states that collected data can take up to 24 hours to appear in Data 360 and then refreshes hourly. Assign an owner for reviewing masking signals, toxicity scores, prompts, responses, user feedback, and anomalies.
6. Limit Agent Actions and Define Human Review
The Trust Layer does not decide which actions an agent should be allowed to take. Administrators and business owners must define that boundary.
For each agent action:
- Grant only the permissions and actions required for the use case.
- Separate read-only, draft, approval-required, and autonomous actions.
- Require human approval for high-impact or irreversible outcomes.
- Define escalation paths for sensitive, ambiguous, or failed requests.
- Test rollback, deactivation, and incident-response steps before production.
- Document who owns ongoing monitoring and who can suspend the feature.
How to Test the Trust Layer Configuration
Run the same test cases across users with different permissions and compare the results.
| Test area | Evidence to capture | Pass condition |
|---|---|---|
| Record access | User, record, prompt, and response | Restricted records do not surface |
| Field access | Field permissions and returned content | Restricted fields do not surface |
| Direct prompt masking | Prompt-template pathway and audit signal | Configured sensitive data is masked |
| Agent prompt-template pathway | Agent action, prompt data, and model path | Team does not rely on unavailable masking |
| Prompt defense | Injection test and resulting behavior | Unsupported instructions are rejected or safely handled |
| Toxicity | Test input, response, and score | Signal is captured and reviewed as designed |
| Agent actions | Requested action and resulting changes | Only approved actions execute |
| Audit and feedback | Data 360 record, report, or dashboard | Required evidence is available to authorized reviewers |
A control is not verified because a setup toggle is on. It is verified when the expected behavior is demonstrated with the intended user, data, prompt, model, and action pathway.
What Administrators Should Document
Keep one implementation record for each production AI use case:
- Business purpose and accountable owner
- Feature, prompt template, agent, and action versions
- Executing user or agent permission context
- Salesforce and external data sources
- Model provider and trust-boundary decision
- Sensitive-data inventory
- Masking behavior for the actual invocation pathway
- Prompt-defense and toxicity test results
- Audit and feedback configuration
- Human-review and escalation rules
- Rollback or deactivation procedure
- Review cadence and evidence owner
Common Trust Layer Questions for Administrators
Does data masking protect a prompt template invoked through Agentforce?
No. Salesforce states that pattern-based and field-based LLM data masking is disabled when a prompt template is invoked through an agent action. The same template used directly can apply masking according to its Trust Layer configuration.
Does the Trust Layer override Salesforce permissions?
No. Permission-aware retrieval uses the executing context's existing access. Excessive permissions remain excessive, so object, field, record, and Data 360 access must be reviewed before production.
Are all AI interactions automatically stored for audit?
No. Audit and feedback collection and storage must be enabled and supported by the required Data 360 configuration. Administrators must also restrict access to the collected data and establish a review process.
What do prompt-defense guardrails protect against?
Prompt defense adds system policies intended to reduce jailbreaking, prompt injection, and unintended or harmful outputs. The policies vary by feature and use case and must be tested with the actual production pathway.
Does the Trust Layer automatically govern third-party AI tools?
Not necessarily. A third-party tool can have its own data path, model provider, storage terms, and security controls. Verify whether the tool uses supported Salesforce Trust Layer architecture before applying Salesforce's claims to it.
Production Approval Checklist
Before enabling a use case, confirm:
Access and data
- Executing permission context identified
- Object, field, record, and Data 360 access tested
- Sensitive-data inventory completed
- External data pathways reviewed
Model and masking
- Model provider and trust boundary documented
- Direct prompt-template masking tested where applicable
- Agentforce masking limitation explicitly documented
- Zero-data-retention terms reviewed for external models
Safety and actions
- Prompt-injection tests completed
- Toxicity behavior reviewed
- Agent actions limited to approved scope
- Human approval and escalation rules documented
Monitoring and recovery
- Audit and feedback collection configured
- Authorized reviewer and cadence assigned
- Rollback or deactivation procedure tested
- Production approval recorded
Official Salesforce References
- Einstein Trust Layer overview
- Data masking limitations in Agentforce
- Set up Einstein generative AI audit and feedback
- Einstein audit and feedback data
- Audit Trail
Next Step
Use this checklist alongside the primary Trust Layer explainer to evaluate the real configuration and invocation pathway—not the demo. If you need a structured review of Salesforce data, access, automation, documentation, and AI controls, request a Salesforce AI Data Readiness Assessment.
Jeremy Carmona is a 13x certified Salesforce Architect who has written about AI governance for Salesforce Ben. He helps organizations implement AI features with appropriate security controls.
