Salesforce AI Security Checklist for Admins and CIOs
Most Salesforce AI security checklists grade the platform, which is the part you did not build and cannot change.
ConvoPro Team
Salesforce Advisors
Featured
Salesforce AI Security Checklist for Admins and CIOs
A Salesforce AI security checklist is only useful if it grades a workflow rather than a platform.
That is the distinction most checklists miss. The typical list runs through trust layers, encryption, masking and certifications, all of which describe what your vendors built. None of it tells you whether the thing you are about to switch on next Tuesday is safe to switch on. The platform questions have vendor answers. The workflow questions have your answers, and those are the ones that determine whether an AI action in your org creates a record it should not have created, reads a field it should not have read, or does either one without leaving a trace.
So the checklist below is a record you fill in once per workflow. Nine control lines, an owner, and a review date. It takes about an hour for a workflow you already understand, and the hour is the point: if you cannot fill in all nine lines, you have found the gap before it found you.
Start with the threat model, not the control list
Before any of the nine lines, answer three questions about the specific workflow.
What is the worst thing this can do in one run? Not in aggregate, not in theory. One run. An AI step that drafts a case summary and writes it to a field can, at worst, put wrong text on a record a human will read. An AI step that updates opportunity amounts, sends external email or closes cases can, at worst, corrupt reporting, contact a customer incorrectly, or hide work that still needs doing. These are different risk classes and they deserve different controls.
Who can trigger it, and are they authenticated? A workflow that only a licensed internal user can run from a record page has a small, known blast radius. A workflow that accepts input from an unauthenticated external submitter has a much larger one, because the input itself becomes an attack surface. Salesforce draws exactly this line in its own guidance, separating public actions that can be performed on behalf of anyone without authentication from private actions that involve sensitive tasks such as updating account details, which should confirm the user's identity before proceeding. Salesforce
What does the AI see that it does not need? This is the quietest risk and the most common. Data minimization means providing only the data the agent truly needs and avoiding nice-to-have datasets that increase risk without adding core value. Salesforce
Answer those three and the rest of the checklist mostly writes itself.
Where Salesforce's responsibility ends and yours begins
The single most expensive misunderstanding in this space is assuming the platform's security posture is your security posture. It is not, and Salesforce does not claim it is.
Layer | Who owns it | What that means in practice |
|---|---|---|
Model hosting, trust layer, provider agreements | Salesforce | Controls like the Einstein Trust Layer apply across agent interactions without you configuring them per workflow |
Platform security model | Salesforce builds, you configure | Profiles, permission sets and sharing rules exist; whether they are scoped correctly for an AI actor is your call |
What the workflow can read | You | Object, field and record access follow the permissions you granted the running identity |
What the workflow can do | You | Which actions are exposed, and whether they are scoped to the job |
Whether a human reviews before a write | You | Nothing enforces this unless you design it in |
Whether anyone would notice a failure | You | Logging, monitoring and the habit of actually reading the logs |
Salesforce's own framing of secure agent implementation is built around five foundational attributes: role, data, actions, guardrails and channel. Every one of those five is a configuration decision. Practitioners make the same point more bluntly. Salesforce Ben's guidance on securing Agentforce notes that even with robust built-in guardrails and failsafe mechanisms in place, securing the org remains the responsibility of individual admins, developers and architects, and that over-permissioned agents or actions can become a major vulnerability if a user account is compromised or an agent is misused. SalesforceSalesforce Ben
The practical translation is short. Buying a well-secured AI platform does not give you a well-secured AI workflow. It gives you the raw material for one.
The nine control lines
Each line below is one row you fill in for the workflow you are assessing.
Data access
Write down every object and field the workflow can read, and every source outside Salesforce it can reach. Then remove what is not required for the output you actually want. A support agent trained on CRM case histories should not access financial records, and unintended exposure of this kind can lead to compliance violations or user mistrust. Salesforce
Pay particular attention to attachments and long text fields, because that is where sensitive content hides from field-level security thinking. A file attached to a case can contain anything, and a workflow that reads attachments inherits whatever was in them.
Identity
Decide what identity the workflow runs as and record why. There are three common patterns and they carry different risk.
Running in the session of the logged-in user is the safest default, because access is bounded by permissions that already exist and have already been reviewed. Running as a dedicated integration identity is appropriate for unattended or external-intake work, but it creates a permission set that exists only to serve automation, which means nobody's quarterly access review naturally covers it unless you add it. Running as a broadly permissioned admin account is never appropriate and is the most common shortcut in pilots that were never meant to reach production.
Whichever pattern you choose, the identity should hold the minimum permissions required and no more. Agents should only have the permissions they absolutely need to perform their intended tasks. Least privilege is not a philosophy here; it is the difference between an incident and a footnote. Salesforce Ben
Model and provider
Record which model handles the workflow, who hosts it, and what the contractual position is on retention and training. If the AI runs through Salesforce, the platform's provider agreements apply. The Einstein Trust Layer enforces measures including Secure Data Retriever, zero data retention agreements with model providers, toxicity filtering and access restrictions across agent interactions. If it runs through a third-party tool, connector or your own API keys, those terms do not automatically follow, and you need the answer in writing from that vendor rather than from a marketing page. Salesforce
Record the fallback behaviour too. If the model is unavailable or returns something malformed, what happens? A workflow with no defined failure path will improvise one, and the improvisation is rarely what you would have chosen.
Actions
List every action the workflow can take, and for each one, mark whether it changes data, sends something external, or only reads. Then check each action against the role you defined at the top. Salesforce warns that poorly scoped or overly permissive actions can bypass protections established at the data or channel level, which is the security equivalent of a strong front door next to an open window. Salesforce
Two questions catch most problems. Can this workflow do anything a person in that role could not do manually? Can it do anything to records outside its intended scope, such as a different record type, a different business unit, or a closed record?
Approvals
Decide where a human sits between the proposal and the commit, and write down the rule. The most durable version separates reading from preparing from writing: retrieval is a permissions question, a structured draft that sits somewhere reviewable is not yet a risk, and only the write needs a gate. Our guide to Salesforce AI approval workflows covers the risk tiers and where each pattern belongs.
The rule needs an exception path as well as a happy path. What does a reviewer do when the proposal is wrong? If the answer is "edit it in a different system and re-run," reviewers will start approving instead of correcting, which is worse than having no review at all.
Logging and monitoring
Record what is captured for each run and where it lands. At minimum you want the input, the proposal, the reviewer decision, the resulting change, and a timestamped identity for each. Salesforce provides real building blocks here. Setup Audit Trail tracks recent setup changes, listing the date of the change, who made it and what the change was. Event Monitoring includes an Invocable Action Event that provides metrics on actions invoked during Agentforce flows and indicates which agents are used and when, plus an Insufficient Access Event that lets project teams troubleshoot and resolve access issues proactively. SalesforceSalesforce
The second half of this line is the one teams skip. Name the person who reads the logs and the cadence on which they read them. Logs nobody reads are a compliance artefact, not a control.
Retention and subprocessors
Write down where workflow content lives outside Salesforce, for how long, and who else touches it. Prompts, attachments, drafts and intermediate outputs often sit in a vendor's systems even when the final record lives in your org. Ask each vendor for the retention window, the deletion mechanism, and the list of subprocessors, and keep the answers with the workflow record rather than in an email thread.
Testing
Test the workflow against a fixed set of cases before launch, and again on a schedule. Include the ordinary cases, the ambiguous ones, and the deliberately hostile ones, because a workflow that accepts external text is a workflow that will eventually receive text designed to manipulate it.
Re-testing matters more with AI than with deterministic automation. Salesforce Ben's guidance notes that models evolve through updates and retraining, which can cause drift and make agents misbehave even when you have not changed topics, instructions or actions, and recommends running a standard set of batch tests regularly against a baseline to detect major variations. Salesforce Ben
Incident response and rollback
Finish with the least fun question. If this workflow does the wrong thing two hundred times before anyone notices, how do you find the affected records and how do you undo it?
You want three things written down in advance: a way to identify records touched by the workflow, a way to stop it immediately without a deployment, and a named owner who has the authority to pull that switch. A stamped field or a consistent flag on affected records makes the first one trivial and its absence makes it forensic.
The checklist
Copy this table into your workflow documentation and fill in one column per workflow.
Line | Question to answer | What a complete answer looks like |
|---|---|---|
Data access | What can it read, and what did we remove? | Named objects and fields, plus a note on attachments and external sources |
Identity | What does it run as, and why? | Running user, dedicated integration identity, or documented exception, with the permission set named |
Model and provider | Which model, whose agreement, what fallback? | Model, hosting path, retention position, and defined behaviour on failure |
Actions | What can it change or send? | Every action listed and classified as read, write or external |
Approvals | Where does a human sit? | The gate condition, the reviewer role, and the correction path |
Logging | What is captured and who reads it? | Fields captured per run, storage location, named reviewer, cadence |
Retention | What sits outside Salesforce, for how long? | Retention window, deletion mechanism, subprocessor list |
Testing | What did we test and when do we retest? | Fixed case set including hostile inputs, plus a recurring test date |
Incident response | How do we find it and stop it? | Record identification method, kill switch, named owner |
Owner | Who is accountable for this workflow? | A person, not a team |
Review date | When do we do this again? | A date, typically quarterly for writing workflows |
Two of these rows carry more weight than the others. If identity and approvals are both weak, no amount of logging will save you, because you will have a fast, well-documented record of damage. If identity and approvals are both strong, most of the remaining risk becomes recoverable.
Questions to ask any AI vendor before it touches your org
Vendor security pages are written to reassure. These questions are written to find out.
Area | Ask this | What a weak answer sounds like |
|---|---|---|
Permissions | Does the product enforce my Salesforce permissions at query time, or does it hold its own copy of access rules? | "It respects your permissions" with no explanation of how |
Identity | What identity writes to my org, and can I scope it per workflow? | A single integration user with broad access and no per-workflow scoping |
Review | Can I require human approval on specific actions, and is that enforced server-side? | Review exists as a UI convention that a user can skip |
Logging | What exactly is logged per action, can I export it, and how long do you keep it? | "Full audit logs" with no field list and no export path |
Model handling | Which providers see my data, and what are the retention and training terms? | Assurances without named providers or contract language |
Certification | What is your current certification status, and can I see the report under NDA? | Claims of alignment rather than a status and a date |
Incident process | How and when do you notify me, and what is the contractual window? | Best-efforts language with no window |
The certification row deserves a note. Terms like alignment, readiness and mapped-to are not the same as a completed audit, and a vendor that is genuinely certified will say so plainly and hand you the report. Treat anything softer as a not-yet and price the risk accordingly.
How to run this in practice
The sequence matters more than the thoroughness on any single pass.
Pick the one workflow closest to production, not the whole AI programme.
Fill in the nine lines with whoever built it, in one sitting.
Mark every line you cannot answer as a gap and assign it an owner and a date.
Fix identity and approvals first, regardless of what else is open.
Launch to a limited group with logging on and the incident owner named.
Read the logs weekly for the first month, then move to the review cadence you wrote down.
Repeat the record for the next workflow, reusing the vendor answers you already collected.
For broader org-level context, the NIST AI Risk Management Framework is a reasonable structure to map this to when your CIO or auditor wants the workflow record to sit inside something recognisable.
Where ConvoPro fits
ConvoPro is a practical AI workflow layer for Salesforce, and it is relevant to this checklist in a specific way rather than a general one. It fits the case where repeated work starts outside Salesforce as email, files, notes or forms and has to end as clean Salesforce data, which is exactly the category where the identity, approvals and logging lines are hardest to satisfy with a general-purpose AI tool.
The design follows the pattern this article argues for. Access is permission-aware, admins control which connectors, tools and actions are available, sensitive work can require review before a record is created or updated, and actions are logged. ConvoPro's site describes access and actions being controlled through Salesforce permissions, connector controls, tool-level permissions, SSO, MFA and audit logs. Salesforce remains the system of record throughout.
The honest caveat is the same one this article applies to every vendor. These controls are configuration-dependent, which means the answer to "is this secure in our org" depends on how it is set up in your org, against your requirements. The security and governance page documents the control points relevant to an admin or security review, and the product page covers how the workspace, admin console and review controls work together. If you are running a formal review, request the security overview and put ConvoPro through the vendor question table above rather than taking a page at its word.
Teams that want to test the shape of a governed workflow before a full security review can get started against a demo org rather than production data.
Frequently asked questions
Does Agentforce security cover our AI security requirements?
It covers the platform layer. Salesforce provides the trust layer, guardrail mechanisms and a structured framework built around role, data, actions, guardrails and channel. What it does not cover is whether you scoped those five things correctly for your workflow, which is the part that produces most incidents.
Do AI agents bypass Salesforce permissions?
No. Agents operate within the platform's existing security model of profiles, permission sets and sharing rules. The risk is not bypass, it is inheritance: an agent running as an over-permissioned identity does everything that identity is allowed to do, quickly and without hesitating.
What is the biggest Salesforce generative AI security mistake?
Granting an integration identity broad access during a pilot and never tightening it before production. It is invisible in testing, because everything works, and it is the single largest amplifier of every other weakness in the list.
How do we handle AI data privacy in Salesforce?
Start with data minimization at the workflow level, since the strongest privacy control is not sending the data at all. Then document what leaves the org, which provider processes it, how long it is retained and who the subprocessors are. Attachments and long text fields deserve specific attention because they carry content that field-level thinking misses.
What should a Salesforce AI governance checklist include that a security checklist does not?
Ownership and cadence. Security asks whether the controls are correct today. Governance asks who is accountable when they drift, when the review happens, and what triggers an off-switch. The owner and review date rows in the table above are the governance part.
How often should we re-test an AI workflow?
Quarterly for anything that writes to records, and immediately after any change to the model, the prompt, the permissions or the connected systems. Model behaviour can shift without any change on your side, which is why a fixed baseline test set is worth building once.
Do we need Shield or Event Monitoring to do this properly?
Not to start. Setup Audit Trail is available in standard editions and covers configuration changes. Event Monitoring adds run-level visibility including agent-relevant events, and it becomes worth the cost once you have workflows writing to records at volume rather than at pilot scale.
If you are working through this for a specific workflow and want a second pair of eyes on the identity and approval design, get in touch.
