The Short Answer
The shared responsibility model isn't just a formal document—it's the line that determines who's at fault when something goes wrong. The simple rule: the platform is responsible for securing the service itself, while the organization is responsible for every decision regarding what an agent sees, what they are allowed to do, and who they respond to.
The major risk isn't a platform breach. It's an over-privileged agent disclosing information to the wrong party or performing an action they shouldn't have—both failures stemming entirely from the organization's side.
Practical Division of Responsibilities
| Area | Platform's Responsibility | Organization's Responsibility |
|---|---|---|
| Infrastructure | Encryption, isolation, availability, vulnerability management | Choosing environment and approved network configuration |
| Data | Storage and processing according to agreement | What gets indexed and what's classified as sensitive |
| Identity & Permissions | Platform's authorization mechanisms | Defining who is allowed to see and do what |
| Agent Behavior | Model capabilities and control tools | Instructions, boundaries, approval points |
| Actions | Execution infrastructure | Authorization for each Action and validation within it |
| Monitoring & Auditing | Platform logs | Business audit trail, sampling, and review |
New Risks Not Present in Regular CRM
The first is exposure through retrieval. In a regular system, the user sees what the screen displays; with an Agent, free text can cause a snippet from an unauthorized document to be retrieved. Therefore, retrieval must run within the user's permission context, not within a broad integration account context.
The second is Prompt Injection. Content the Agent reads—a customer email, description field, attached document—might contain instructions attempting to alter its behavior. This cannot be defended against by phrasing alone; the defense is architectural.
The third is internal content leaking to an external channel. An article written for representatives with discount margins or objection handling scripts should not reach the customer, and separation must be based on a whitelist, not a blocklist.
The fourth is silent privilege escalation: adding an Action or permission to solve a specific problem, without going through the approval process.
Five Controls That Bear the Most Weight
Retrieval in the user's context. This is the only control that, if broken, renders all others useless.
Separate authorization for each Action, following the principle of least privilege. An Agent granted a single broad profile prevents all future control.
Validation within the action, not in instructions. An instruction is guidance; validation is a control. An action that performs a credit must verify amount, eligibility, and authorization in its code, even if instructions tell the Agent not to trigger it in certain cases.
Human approval for irreversible actions. This control converts a potential failure into an event stopped in time.
Audit trail linking user, action, source, and approver. Without it, there's no answer to the audit question, "On what basis did the Agent do that?"
General Salesforce permission model principles are detailed in Salesforce Permission Model.
What to Check Before Go Live
Persona Tests: The same ten to twenty questions are run under different identities—representative, manager, restricted user, external customer—and answers are compared. Any discrepancy not explained by permissions is a finding.
Content Red Teaming: Deliberate attempts to extract unauthorized information, trigger prohibited actions, and bypass escalation. Scenarios are written once and saved for re-running with each version.
Action Path Testing: For each Action, verify that validation works even when triggered directly, not just through the Agent.
Data Retention Testing: What data is stored, for how long, and who can access logs containing conversation content with customer data.
How these tests integrate into a broader testing framework is explained in Agentforce Testing Scorers.
Scenario: Finding Caught in Persona Testing
A healthcare company developed an internal Agent to answer procedural questions. During Persona Testing before go-live, it was discovered that an administrative user received an answer based on a procedure classified for medical staff only.
The reason wasn't an Agent bug. The index was built by an integration account with broad access, and retrieval did not restrict by user permissions. The same exposure was potentially present in any question touching that area.
The fix involved two things: moving retrieval to the user context and explicitly marking classified documents so they wouldn't enter the general index. The test was added as a permanent scenario run before every version release.
Risks and Preventive Actions
| Risk | How it's Detected | Preventive Action |
|---|---|---|
| Retrieval with broad permissions | Exposure of a classified document in an innocent answer | Retrieval in user context and Persona Tests |
| Prompt Injection | Action triggered by external content | Narrow permissions, in-action validation, human approval |
| Mixing internal and external content | Internal phrasing reaching customer | Whitelist on external channel |
| Silent privilege escalation | Agent doing more than authorized | Tagging significant changes and re-approving |
| No Audit trail | No answer for audit | Logging user, action, source, and approver |
Security Metrics
| Metric | What it Reveals | Frequency |
|---|---|---|
| Persona findings | Permission gaps in retrieval | With each version |
| Red Teaming results | Resilience against bypass attempts | With each version |
| Sensitive actions without approval | Gaps in control path | Monthly |
| Changes that bypassed approval | Change process discipline | Quarterly |
| Audit trail coverage | Percentage of fully documented sensitive actions | Quarterly |
The approval framework within which controls are enforced is detailed in AI Governance for Agentforce.
When guidance is needed in defining the responsibility model and pre-go-live testing, Agentforce and AI Service is the practical next step.
Pre-Go Live Security Checklist
- ☐ Shared responsibility document written and approved
- ☐ Data usage terms with the model documented in writing
- ☐ Retrieval runs within the user's permission context
- ☐ Persona tests conducted for all permission levels
- ☐ Each Action has separate permission and internal validation
- ☐ Irreversible actions require human approval
- ☐ External channel operates a content whitelist
- ☐ Content Red Teaming scenarios written and executed
- ☐ Audit trail links user, action, source, and approver
- ☐ Log and conversation content retention policy approved