The Salesforce shared responsibility model divides security work between Salesforce and the customer. Salesforce protects the platform and the infrastructure it runs on. You, the admin, own how your org is configured: who can log in, what each person can see and change, which security settings are on, which apps and tools are connected, and how you recover data when something goes wrong. Salesforce gives each side a named layer, and a third layer covers paid add-ons that you choose whether to buy.
This guide sets out what sits in each layer, a table for assigning an owner to common admin tasks, the places where responsibility is easy to miss, and a review you can work through in one sitting. It is written for admins who handle security without a dedicated security team. The Cirra AI page for Salesforce admins describes how admins hand routine configuration work to an AI client while they keep the judgment calls, and that split of duties matters here, because every connected tool becomes part of what you own. Closing the admin security skills gap starts with knowing which Salesforce security responsibilities are yours.
The facts below come from Salesforce's security blog, Salesforce developer documentation and the third-party sources linked in each section, checked on October 27, 2026. Salesforce changes its products every release, so confirm each setting in your own org before you act on it.
What the Salesforce shared responsibility model says
Salesforce explains the model in a security blog post published January 22, 2026, and its compliance portal carries a document titled "Security Perspective on the Shared Responsibility Model" that frames it as the partnership between Salesforce and its customers on security and compliance roles. The blog post splits responsibility into three layers.
Foundationals: Salesforce's responsibility
Salesforce describes the Foundationals as "protections that are built into our infrastructure and our platform, and are always working in the background." Salesforce manages them, so there is nothing for you to switch on. The post does not list the individual protections, so treat this layer as the platform itself: the infrastructure and the services that run your org.
Configurables: your responsibility
The Configurables are security features built into Salesforce that each customer enables. Salesforce's post names multi-factor authentication and single sign-on, the principle of least privilege (fewer admin users, plus permission sets that give people only the access their jobs require), Login History reports that show who logs in and from where, login IP restrictions on profiles that challenge users on an untrusted IP address, and Security Health Check. Salesforce describes Health Check as a dashboard of session settings, password policies and identity settings that is available out of the box at no cost.
Salesforce Ben's explainer for admins adds session timeouts, role hierarchies and sharing rules to the list. It also points out that flows, Apex and third-party integrations are your build, so you maintain them and secure them as you would any other change to the org.
Enhanceables: your choice, then your configuration
Salesforce calls the Enhanceables advanced security add-ons and lists Shield, Security Center, Privacy Center, Data Mask and Seed, Archive, and Backup and Recover. Buying one does not finish the job, because someone still has to set it up. The Transaction Security Policy Accelerator is a good example: according to its install guide, every policy deploys as Inactive and the org needs Event Monitoring or Shield licensed before the install works. Our guide to the Transaction Security Policy Accelerators covers the rollout order.
Who owns what: a working table
The table turns the three layers into the tasks admins handle every week. The left column names the area, the middle column says what Salesforce provides, and the right column says what you decide or do. Copy it into your change record and put a name next to each row.
| Area | What Salesforce provides | What you own |
|---|---|---|
| Infrastructure and platform protections | Builds, runs and maintains them (Foundationals) | Nothing to switch on |
| Login security | Multi-factor authentication, single sign-on support and login IP restrictions. Salesforce has required MFA for all users who log in to the Salesforce UI since February 1, 2022. | Enroll users, connect your identity provider if you use single sign-on, set login IP restrictions on profiles |
| Access to data and features | Profiles, permission sets, field-level security and sharing rules | Decide who gets what, keep the number of admins low, review assignments on a schedule |
| Settings baseline | Security Health Check at no cost | Run it and act on the settings it flags |
| Record of setup changes | Setup Audit Trail | Read it and download it, because it covers a limited window |
| Backup and recovery | Sells Backup and Recover as an add-on | Choose a backup approach, run it and test a restore |
| Flows, Apex and custom code | The platform they run on | Build them securely, test them and maintain them |
| Connected apps and AI clients | OAuth, and user permissions that apply to every connection | Approve what connects, limit what it can reach, review its activity |
| Paid add-ons | Sells and supports them (Enhanceables) | Decide whether your risk justifies them, then configure them |
Where responsibility is easy to miss
Four areas stand out, because each one looks like something the platform should handle.
Backups
Salesforce retired its Data Recovery Service on July 31, 2020. TechTarget's coverage describes it as a last-resort, manual service that did not guarantee full recovery. Salesforce now lists Backup and Recover among its add-on products, and third-party backup tools exist as well. Whichever route you choose, a backup you have never restored from is a guess. Put a restore test on the calendar and write down who runs it.
Setup change history
The Setup Audit Trail records configuration changes, which makes it the first place to look when a field, flow or permission changed and nobody remembers why. Gearset's guide reports that the trail keeps about 180 days of entries, shows only the 20 most recent entries in the Setup page, and lets you download the rest as a CSV file. Older entries are gone, so download the file on a schedule if you need a longer record.
Flows and Apex
A flow that runs in system context, or an Apex class that skips sharing rules, can expose data to people who could not see it through the normal UI. The design decision belongs to whoever builds the automation. Review who can edit flows, and read each new flow with the same questions you would ask of a permission change.
Connected apps and AI clients
Tools that connect on a user's behalf through OAuth act with the permissions of that user. Salesforce's security best practices for its hosted MCP servers state the pattern clearly. Every MCP tool call runs with the same permissions as the user who authorized the connection, and field-level security and sharing rules still apply. If the user cannot do something in the Lightning UI or the REST API, the connection cannot do it either. The same guidance puts the setup work on admins: they enable the servers, which are disabled by default, they create and configure External Client Apps, and they can link those apps to profiles and permission sets to control which users reach which clients. Salesforce advises starting with the most restrictive configuration that meets the use case and expanding access only as needed.
That guidance covers Salesforce's own servers, and the ownership pattern carries over to any AI client you connect, including Cirra AI. Cirra AI connects through OAuth, works as the connected user and cannot go beyond that user's permissions. It adds per-org access rules across four categories of data (Metadata, User Data, Personal Setup Data and Business Data), and each category can be set to None, Read Only or Read and Write. Cirra AI logs every action in an exportable audit trail. Several decisions stay with you:
- Which person authorizes the connection, since that person's permission sets set the ceiling for everything the AI client can do.
- Which org you connect first. Cirra AI recommends making metadata changes in a sandbox or scratch org and deploying through your standard process.
- Which data categories to leave on None or Read Only in each org.
- Who reads the audit trail, and how often.
Our checklist on whether AI can change your Salesforce org walks through those decisions in more detail.
A review you can run in one sitting
This review checks each row of the ownership table in a sandbox or a production org you administer. Work through the steps in order, and write down an owner and a date next to anything you find.
- Run Security Health Check. In Setup, enter Health Check in the Quick Find box and select Health Check. Salesforce compares your settings with its security baseline, so note every setting that falls short and decide which ones you will fix first.
- List who holds broad access. This query shows active users who hold the Modify All Data permission through a profile or a permission set. Run it in a sandbox first and compare the output with your own org's setup, because object and field availability can differ between orgs. Then decide whether each person needs the permission.
SELECT Assignee.Name, Assignee.Username, PermissionSet.Label, PermissionSet.Profile.Name FROM PermissionSetAssignment WHERE PermissionSet.PermissionsModifyAllData = true AND Assignee.IsActive = true ORDER BY Assignee.Name
- Read Login History. In Setup, enter Login History in the Quick Find box. Look for failed logins, unfamiliar locations and accounts that should be dormant.
- Check login controls. Confirm that your users are enrolled in multi-factor authentication, and review the login IP restrictions on your profiles.
- Read the Setup Audit Trail. In Setup, enter View Setup Audit Trail in the Quick Find box, scan for changes nobody planned and download the file for your records.
- Review connected apps and OAuth usage. Revoke the tokens of tools nobody uses anymore, and confirm that each active connection belongs to a user whose permissions you are comfortable with. Salesforce's developer guidance on securing hosted MCP servers recommends revoking tokens through OAuth Usage when needed.
- Settle backups. Name the tool, the owner and the date of your next restore test.
If you want a wider checklist, our list of signs your Salesforce org needs a health check covers the symptoms that usually come before a review like this one.
Where Cirra AI fits
The decisions in this guide belong to you. Cirra AI helps with the legwork around them. Cirra AI is a hosted Salesforce Admin MCP Server: you authenticate a Salesforce org through OAuth, connect the AI client you already use, such as Claude, ChatGPT or Cursor, and describe what you need. For a review like the one above, that means asking your AI client to run the permission query, to list who holds a given permission set, or to answer a question such as who can see a particular field. Cirra AI runs as the connected user, within that user's permissions, so connect a sandbox first and read the results before you act on them in production.
Cirra AI supports Salesforce Enterprise Edition and up, and the Free plan includes 100 credits per month with no credit card required. Ready to try it on a sandbox? Start Free Trial, or Learn More about the product.
Frequently asked questions
What is the Salesforce shared responsibility model?
The Salesforce shared responsibility model is the division of security work between Salesforce and its customers. Salesforce protects the platform and infrastructure, while customers configure access, authentication, settings and the apps they connect. Salesforce describes three layers: Foundationals, Configurables and Enhanceables.
What does Salesforce secure, and what do admins secure?
Salesforce secures the infrastructure and platform protections it calls Foundationals. Admins secure the Configurables, such as multi-factor authentication, least-privilege access, login IP restrictions and Security Health Check, and they decide whether to add the paid Enhanceables.
Does Salesforce back up my data for me?
Plan on running your own backup. Salesforce retired its Data Recovery Service on July 31, 2020, and it lists Backup and Recover as an add-on product. Third-party backup tools are also available, and you should test a restore whichever one you use.
Is Security Health Check free?
Yes. Salesforce describes Security Health Check as available out of the box at no cost. In Setup, enter Health Check in the Quick Find box to open it.
Is multi-factor authentication required in Salesforce?
Yes for the Salesforce UI. Salesforce's documentation says that as of February 1, 2022, Salesforce requires MFA for all users who log in to the Salesforce UI. Admins still have to enroll users and confirm that every user can complete the check.
Who is responsible when I connect an AI client to Salesforce?
You are, as the admin who approves the connection. Salesforce's guidance for its hosted MCP servers says connections run with the permissions of the user who authorized them. With Cirra AI, the connected user's permissions set the ceiling, and you can narrow access further per org across four data categories.
